From stpeter@stpeter.im Wed Jan 11 14:13:56 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6484611E808C for ; Wed, 11 Jan 2012 14:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.83 X-Spam-Level: X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw3jIVdiqFHO for ; Wed, 11 Jan 2012 14:13:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D5ABB11E8071 for ; Wed, 11 Jan 2012 14:13:55 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3264140058 for ; Wed, 11 Jan 2012 15:22:57 -0700 (MST) Message-ID: <4F0E09A2.1080407@stpeter.im> Date: Wed, 11 Jan 2012 15:13:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: paws@ietf.org X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [paws] WG activity X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 22:13:56 -0000 It's been almost two months since the last message was posted to this list. Has interest waned? Are there open issues with the use cases and requirements? If not, is it time to start working on the protocol? Please note that the deadline for requesting a WG session at IETF 83 in Paris is January 30. It would be good to get a sense of agenda topics before then, so discussion is very much encouraged. Thanks! Peter -- Peter Saint-Andre http://stpeter.im/ From Gabor.Bajko@nokia.com Wed Jan 11 16:47:12 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F7721F8795 for ; Wed, 11 Jan 2012 16:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVJ37jFPmg1N for ; Wed, 11 Jan 2012 16:47:12 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5721F8794 for ; Wed, 11 Jan 2012 16:47:11 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0C0l7Kw030120; Thu, 12 Jan 2012 02:47:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 02:47:07 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.241]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Thu, 12 Jan 2012 01:47:06 +0100 From: To: , Thread-Topic: [paws] WG activity Thread-Index: AQHM0K6eGCrJOqIB7ESBmv5OR9bzrpYH5QoQ Date: Thu, 12 Jan 2012 00:47:06 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA368F@008-AM1MPN1-006.mgdnok.nokia.com> References: <4F0E09A2.1080407@stpeter.im> In-Reply-To: <4F0E09A2.1080407@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.66.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jan 2012 00:47:07.0388 (UTC) FILETIME=[B5C7EBC0:01CCD0C3] X-Nokia-AV: Clean Subject: Re: [paws] WG activity X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 00:47:12 -0000 I wanted to give folks some time to prepare what they committed for in the = last f2f, but maybe this is a little too much time as it is perceived as in= activity. Anyway, I'll send a reminder of what we need to do tomorrow, then we take i= t from there. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Peter Saint-Andre Sent: Wednesday, January 11, 2012 2:14 PM To: paws@ietf.org Subject: [paws] WG activity It's been almost two months since the last message was posted to this list.= Has interest waned? Are there open issues with the use cases and requireme= nts? If not, is it time to start working on the protocol? Please note that the deadline for requesting a WG session at IETF 83 in Par= is is January 30. It would be good to get a sense of agenda topics before t= hen, so discussion is very much encouraged. Thanks! Peter -- Peter Saint-Andre http://stpeter.im/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Jan 12 17:26:56 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E8121F854A for ; Thu, 12 Jan 2012 17:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuESbx8bNPIk for ; Thu, 12 Jan 2012 17:26:56 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id D545D21F8542 for ; Thu, 12 Jan 2012 17:26:55 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0D1Qrtm017249 for ; Fri, 13 Jan 2012 03:26:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jan 2012 03:26:53 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.241]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Fri, 13 Jan 2012 02:26:52 +0100 From: To: Thread-Topic: next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSA== Date: Fri, 13 Jan 2012 01:26:52 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.144] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jan 2012 01:26:53.0788 (UTC) FILETIME=[6E9969C0:01CCD192] X-Nokia-AV: Clean Subject: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 01:26:56 -0000 As the AD noted, the list has been inactive for the last few weeks. In this email I am trying to summarize where we are and what we need to do = next in the WG: 1. use cases: We had a long discussion about the use cases in the last f2f,= and it seems that the only use case requiring a re-write is the m2m one. J= uan-Carlos promised to revise the use case based on the comments received a= nd post the revised version to the list asap. Brian promised to contribute a use case on mesh-networking, as that seems t= o be different from the m2m one. With the revision of the m2m and addition of the mesh-networking one, the u= se case part should be complete. 2. requirements. In the last f2f=20 we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with = D.6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdf and slide 9 of http://www.ietf.org/p= roceedings/82/slides/paws-1.pdf=20 We seem to have agreed with the reformulation suggested to D.3 in slide 12 = of http://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agr= ee on the format the location would be represented in. The data format part= is still open, but as this piece does not really belong to requirements bu= t rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf=20 D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete P.2 currently says: The protocol MUST support regulatory domain discovery. We need to discuss this further on the list, to come up with a better formu= lated requirement. The minutes captured: Implies transmitter first queries the DB to find out the regulatory domain = before it queries for the available channel list need to spend time figuring out an implementable requirement. Related to s= ending "rules" for a domain put it as a suggestion rather than requirement. Current regulations envisi= on tight coupling between certified devices and owners. need to document the coupling between regulatory domain, database, requirem= ents. Suggestions for P.2 expected to the list. P.3 currently says: The protocol between the master device and the WS Data= base MUST support pushing updates in channel availability changes to subj= ects. There were comments that this requirement involves a mechanism, we should r= eformulate to be mechanism agnostic. There was a suggestion to "make the requirement "quick way to change availa= bility" rather than imply a mechanism.". The use case is that if the channel availability changes in the DB, the cli= ent has to be able to detect it and get the new availability list within a = time period set by the regulator. Can someone send suggested text on how to reformulate this requirement? We had no time to go through these requirements, so I am asking here on the= list to please comment on them: P.4: The protocol between the master device and the WS Database MUST support mutual authentication and authorization. P.5: The protocol between the master device and the WS Database MUST support integrity and confidentiality protection. P.6: The protocol MUST support both username/password and digital certificates based authentication. P.12: A master device MUST be capable of validating the digital certificate of the WS Database. P.13: A master device MUST be capable of checking the validity of the WS Database certificate and whether it has been revoked or not. Note, P.13 requires support for OCSP (RFC2560) in the client, I am not sure= if that is needed, please send your opinions. The wording of P.11 has to be enhanced to match the description of the revi= sed D.1 We did not have any discussion on P.9, so I'd like to get comments on the l= ist about this: P.9: A master device MUST be able to query the whitespace database for channel availability information for a specific expected coverage area around its current location. Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. I ask the editor to implement the changes above and post a revised version = asap, so we can have further reviews on it. We also have a protocol framework document available at http://www.ietf.org= /id/draft-das-paws-protocol-00.txt We did have a brief discussion on it, the author promised to update it to c= apture the received comments and post a new version in the next few weeks. = If you have additional comments, please send those to the list, so the auth= or can address them. We also have a proposal available on the data model structure, available at= http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt It was presented in the last f2f, but there was no time for comments. Pleas= e send your comments on this document to the list too. - Gabor From eng_rashid@hotmail.com Thu Jan 12 22:59:25 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEF921F8615 for ; Thu, 12 Jan 2012 22:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.337 X-Spam-Level: X-Spam-Status: No, score=-97.337 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_BIZOP=0.7, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcP0tS5ksfqf for ; Thu, 12 Jan 2012 22:59:21 -0800 (PST) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4421F84E6 for ; Thu, 12 Jan 2012 22:59:20 -0800 (PST) Received: from BLU155-W32 ([65.55.116.74]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 22:59:20 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_5ef36ea1-b19f-4dc8-9481-640f3b440406_" X-Originating-IP: [41.95.76.203] From: "Dr. Rashid Saeed" Sender: To: Date: Fri, 13 Jan 2012 06:59:19 +0000 Importance: Normal In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jan 2012 06:59:20.0399 (UTC) FILETIME=[DFB4B5F0:01CCD1C0] Subject: [paws] New TVWS Book X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:59:25 -0000 --_5ef36ea1-b19f-4dc8-9481-640f3b440406_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New TVWS book=2C FYI... =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Stay Up to Date on Information & Communications Technology Standards =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 TV White Space Spectrum Technologies: Regulations=2C Standards and Applicati= ons explains how to use white space technology to enable the additional spect= rum access that is so badly needed around the world. In this forward-thinking book=2C prominent industry players=2C researchers=2C and standards develo= pers: Examine IEEE and FCC standards and regulationsHighlight potential business opportunities=2C including broadband Internet applicationsAddress de= ployment problems likely to ariseDiscuss system requirements=2C spectrum sharing=2C privacy=2C and security Learn how to use these technologies in practice = --_5ef36ea1-b19f-4dc8-9481-640f3b440406_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

New TVWS book=2C FYI...


=3D"http://66.232.39.132/images/White_Spacer_600x20px.jpg"

 =3B

3D"CRCPress.com"

 =3B

Stay Up to Date on Information &= =3B Communications Technology Standards

 =3B

3D"http://66.232.39.132/image=

 =3B


= --_5ef36ea1-b19f-4dc8-9481-640f3b440406_-- From stpeter@stpeter.im Tue Jan 17 09:56:57 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64C11E8088 for ; Tue, 17 Jan 2012 09:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+91myAKDSgi for ; Tue, 17 Jan 2012 09:56:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF3311E8072 for ; Tue, 17 Jan 2012 09:56:56 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2538840058; Tue, 17 Jan 2012 11:06:16 -0700 (MST) Message-ID: <4F15B666.2050004@stpeter.im> Date: Tue, 17 Jan 2012 10:56:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:56:57 -0000 Gabor, thank you for the very comprehensive summary! I'm looking forward to discussion by WG participants and work by the document editors to address and incorporate these issues. On 1/12/12 6:26 PM, Gabor.Bajko@nokia.com wrote: > As the AD noted, the list has been inactive for the last few weeks. > > In this email I am trying to summarize where we are and what we need to do next in the WG: > > 1. use cases: We had a long discussion about the use cases in the last f2f, and it seems that the only use case requiring a re-write is the m2m one. Juan-Carlos promised to revise the use case based on the comments received and post the revised version to the list asap. > Brian promised to contribute a use case on mesh-networking, as that seems to be different from the m2m one. > With the revision of the m2m and addition of the mesh-networking one, the use case part should be complete. > > 2. requirements. In the last f2f > we agreed to modify requirement D.1 to include the suggestions from slide 7-10 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9 > slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also contain suggestions on how to revise this requirement. > Agreed to revise requirement D.2 as suggested in slide 11 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf > We seem to have agreed with the reformulation suggested to D.3 in slide 12 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. The data format part is still open, but as this piece does not really belong to requirements but rather the data model spec, we are not in a hurry to decide it. > Delete d.4 > D.5: augment with lower/upper frequencies and time of availability, as suggested on slide 10 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf > D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf. > D.7: change to single and multiple locations. Clarify that in case of multiple locations the channel availability for each location should be sent by the db. > D.8: delete > > P.2 currently says: The protocol MUST support regulatory domain discovery. > We need to discuss this further on the list, to come up with a better formulated requirement. > The minutes captured: > Implies transmitter first queries the DB to find out the regulatory domain before it queries for the available channel list > need to spend time figuring out an implementable requirement. Related to sending "rules" for a domain > put it as a suggestion rather than requirement. Current regulations envision tight coupling between certified devices and owners. > need to document the coupling between regulatory domain, database, requirements. > Suggestions for P.2 expected to the list. > > P.3 currently says: The protocol between the master device and the WS Database MUST support pushing updates in channel availability changes to subjects. > There were comments that this requirement involves a mechanism, we should reformulate to be mechanism agnostic. > There was a suggestion to "make the requirement "quick way to change availability" rather than imply a mechanism.". > The use case is that if the channel availability changes in the DB, the client has to be able to detect it and get the new availability list within a time period set by the regulator. > Can someone send suggested text on how to reformulate this requirement? > > We had no time to go through these requirements, so I am asking here on the list to please comment on them: > > P.4: The protocol between the master device and the WS Database > MUST support mutual authentication and authorization. > > P.5: The protocol between the master device and the WS Database > MUST support integrity and confidentiality protection. > > P.6: The protocol MUST support both username/password and > digital certificates based authentication. > > P.12: A master device MUST be capable of validating the digital > certificate of the WS Database. > > P.13: A master device MUST be capable of checking the validity of > the WS Database certificate and whether it has been revoked > or not. > > Note, P.13 requires support for OCSP (RFC2560) in the client, I am not sure if that is needed, please send your opinions. > > The wording of P.11 has to be enhanced to match the description of the revised D.1 > > > We did not have any discussion on P.9, so I'd like to get comments on the list about this: > P.9: A master device MUST be able to query the whitespace > database for channel availability information for a > specific expected coverage area around its current > location. > > Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them. > > I ask the editor to implement the changes above and post a revised version asap, so we can have further reviews on it. > > > We also have a protocol framework document available at http://www.ietf.org/id/draft-das-paws-protocol-00.txt > We did have a brief discussion on it, the author promised to update it to capture the received comments and post a new version in the next few weeks. If you have additional comments, please send those to the list, so the author can address them. > > We also have a proposal available on the data model structure, available at http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt > It was presented in the last f2f, but there was no time for comments. Please send your comments on this document to the list too. > > - Gabor > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From stpeter@stpeter.im Tue Jan 17 09:58:12 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1877011E808D for ; Tue, 17 Jan 2012 09:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.664 X-Spam-Level: X-Spam-Status: No, score=-102.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHXQrZ3mMWw3 for ; Tue, 17 Jan 2012 09:58:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF0E11E8072 for ; Tue, 17 Jan 2012 09:58:11 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 872CC40058; Tue, 17 Jan 2012 11:07:31 -0700 (MST) Message-ID: <4F15B6B2.1070000@stpeter.im> Date: Tue, 17 Jan 2012 10:58:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> <4F15B666.2050004@stpeter.im> In-Reply-To: <4F15B666.2050004@stpeter.im> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 17:58:12 -0000 Oh, and please note that WG sessions for IETF 83 need to be scheduled less than 2 weeks from now: http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 On 1/17/12 10:56 AM, Peter Saint-Andre wrote: > Gabor, thank you for the very comprehensive summary! I'm looking forward > to discussion by WG participants and work by the document editors to > address and incorporate these issues. > > On 1/12/12 6:26 PM, Gabor.Bajko@nokia.com wrote: >> As the AD noted, the list has been inactive for the last few weeks. >> >> In this email I am trying to summarize where we are and what we need to do next in the WG: From Basavaraj.Patil@nokia.com Tue Jan 17 15:08:54 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45F21F847F for ; Tue, 17 Jan 2012 15:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpUM71IgE6Ph for ; Tue, 17 Jan 2012 15:08:53 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 95F9E21F8445 for ; Tue, 17 Jan 2012 15:08:53 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0HN8mXW021189 for ; Wed, 18 Jan 2012 01:08:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 01:08:48 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 00:08:41 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYA Date: Tue, 17 Jan 2012 23:08:40 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B32A07FD1862E4398C1E33689A02AF2@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 23:08:48.0526 (UTC) FILETIME=[F84382E0:01CCD56C] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:08:54 -0000 Hi Gabor, On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" wrote: >P.3 currently says: The protocol between the master device and the WS >Database MUST support pushing updates in channel availability changes >to subjects. >There were comments that this requirement involves a mechanism, we should >reformulate to be mechanism agnostic. >There was a suggestion to "make the requirement "quick way to change >availability" rather than imply a mechanism.". >The use case is that if the channel availability changes in the DB, the >client has to be able to detect it and get the new availability list >within a time period set by the regulator. >Can someone send suggested text on how to reformulate this requirement? The requirement to enable Push notifications to be sent to a white space device which has registered with a database is important especially in the context of Ofcom requirements (I believe). The reasons for such push notifications could be for purposes that go beyond just channel availability updates. A proposal for the requirement is as follows: Requirement: A white space database should be able to send unsolicited messages to a master device which has registered with it. The protocol between the WS database and master device MUST allow for push notifications to be sent from the database to the master device. -Raj From Basavaraj.Patil@nokia.com Tue Jan 17 15:11:58 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8172A21F85DB for ; Tue, 17 Jan 2012 15:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94iVyK8Py-dy for ; Tue, 17 Jan 2012 15:11:58 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id CF13A21F85DA for ; Tue, 17 Jan 2012 15:11:57 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0HNBtbv016726 for ; Wed, 18 Jan 2012 01:11:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 01:11:55 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 00:11:54 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrGwSA Date: Tue, 17 Jan 2012 23:11:54 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <2E2C97B4CDB46D44A77D28150332E85A@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 23:11:55.0594 (UTC) FILETIME=[67C3D2A0:01CCD56D] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:11:58 -0000 Hi Gabor, On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" wrote: >P.6: The protocol MUST support both username/password and > digital certificates based authentication. > The requirement for the protocol is to allow mutual authentication/authorization between the white space database and master device. I do not see the need for an explicit requirement as stated above w.r.t the authentication mechanism itself. Hence I would propose deleting this requirement.=20 -Raj From Basavaraj.Patil@nokia.com Tue Jan 17 15:14:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A597121F85E0 for ; Tue, 17 Jan 2012 15:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJhotPY-5S9Z for ; Tue, 17 Jan 2012 15:14:36 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E4E6821F8535 for ; Tue, 17 Jan 2012 15:14:35 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0HNEYUL013143 for ; Wed, 18 Jan 2012 01:14:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 01:14:33 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 00:14:32 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrMfeA Date: Tue, 17 Jan 2012 23:14:32 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <7CAE3D62F6673645995E4C0D3173310B@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 23:14:33.0647 (UTC) FILETIME=[C5F8CBF0:01CCD56D] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:14:36 -0000 Gabor, On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" wrote: >P.13: A master device MUST be capable of checking the validity of > the WS Database certificate and whether it has been revoked > or not. > >Note, P.13 requires support for OCSP (RFC2560) in the client, I am not >sure if that is needed, please send your opinions. > If certificate based authentication is used by the protocol, then there would be a need to mandate the above requirement. But at this time we have no visibility about the authentication protocol to be used between the master device and the WS database. So it is premature to specify the above requirement. Hence I would favor dropping this requirement. -Raj From Basavaraj.Patil@nokia.com Tue Jan 17 15:18:03 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24A021F859E for ; Tue, 17 Jan 2012 15:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcQDkF7KaMaX for ; Tue, 17 Jan 2012 15:18:03 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE0C21F8517 for ; Tue, 17 Jan 2012 15:18:02 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0HNHuIZ021522 for ; Wed, 18 Jan 2012 01:18:01 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 01:17:56 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 00:17:50 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrT+sA Date: Tue, 17 Jan 2012 23:17:50 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA4F71@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <30E0A79CE7D7F14B8CEF881FE340AF0F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 23:17:56.0792 (UTC) FILETIME=[3F0E4380:01CCD56E] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:18:03 -0000 Hi Gabor, On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" wrote: >We did not have any discussion on P.9, so I'd like to get comments on the >list about this: > P.9: A master device MUST be able to query the whitespace > database for channel availability information for a > specific expected coverage area around its current > location. This requirement addresses the need associated with a white space master device which is mobile. The master device may query channel availability for a specific contour or a set of locations on a certain path for example. Hence this requirement is primarily about allowing the query to contain information that goes beyond just a specific lat/long co-ordinate. -Raj From peter@spectrumbridge.com Tue Jan 17 15:25:57 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C5F21F86A3 for ; Tue, 17 Jan 2012 15:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWWVWb3ADCFj for ; Tue, 17 Jan 2012 15:25:56 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id B88A821F86A8 for ; Tue, 17 Jan 2012 15:25:56 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 17 Jan 2012 18:26:17 -0500 From: Peter Stanforth To: "Basavaraj.Patil@nokia.com" , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Tue, 17 Jan 2012 18:25:53 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczVb2iKsGd6mjSVTxWkWVKieN2tGA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:25:57 -0000 I would like to see this be described in a more generic way. I agree with Raj that this is all about providing information for more than a point on a map but there are several possible scenarios for which a query for a "polygon" could be requested. It could be a very long thin polygon if the request is related to a road or railroad or a fairly square polygon if the request is for a venue or even a field. While the use case may be a mobile master it could also be for a master that is supporting devices that either roam within the polygon or cannot accurately locate themselves within the polygon. On TueJan/17/12 Tue Jan 17, 6:17 PM, "Basavaraj.Patil@nokia.com" wrote: > >Hi Gabor, > >On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >wrote: > >>We did not have any discussion on P.9, so I'd like to get comments on the >>list about this: >> P.9: A master device MUST be able to query the whitespace >> database for channel availability information for a >> specific expected coverage area around its current >> location. > >This requirement addresses the need associated with a white space master >device which is mobile. >The master device may query channel availability for a specific contour or >a set of locations on a certain path for example. >Hence this requirement is primarily about allowing the query to contain >information that goes beyond just a specific lat/long co-ordinate. > >-Raj > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Tue Jan 17 15:32:41 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD2021F862B for ; Tue, 17 Jan 2012 15:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4uMlNGeaqqF for ; Tue, 17 Jan 2012 15:32:41 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id DE27121F853B for ; Tue, 17 Jan 2012 15:32:40 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0HNWdvI029059; Wed, 18 Jan 2012 01:32:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 01:32:38 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 00:32:38 +0100 From: To: , , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrT+sAAAzYPYD//51gAA== Date: Tue, 17 Jan 2012 23:32:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <3757A1D0F8823E4CA9CDA74B1D90C16F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jan 2012 23:32:38.0791 (UTC) FILETIME=[4CC4A170:01CCD570] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:32:42 -0000 Hi Peter, I concur with your comment. Just a quick clarification question about the scenario wherein the mobile master is supporting devices that either roam within a polygon or cannot accurately locate themselves.. First of all I am not sure I understand what these other devices are that are relying on the master. Maybe a more complete use case description would help. We do not have such a scenario in the current document and could consider it. -Raj On 1/17/12 5:25 PM, "ext Peter Stanforth" wrote: >I would like to see this be described in a more generic way. I agree with >Raj that this is all about providing information for more than a point on >a map but there are several possible scenarios for which a query for a >"polygon" could be requested. It could be a very long thin polygon if the >request is related to a road or railroad or a fairly square polygon if the >request is for a venue or even a field. While the use case may be a >mobile master it could also be for a master that is supporting devices >that either roam within the polygon or cannot accurately locate themselves >within the polygon. > >On TueJan/17/12 Tue Jan 17, 6:17 PM, "Basavaraj.Patil@nokia.com" > wrote: > >> >>Hi Gabor, >> >>On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>wrote: >> >>>We did not have any discussion on P.9, so I'd like to get comments on >>>the >>>list about this: >>> P.9: A master device MUST be able to query the whitespace >>> database for channel availability information for a >>> specific expected coverage area around its current >>> location. >> >>This requirement addresses the need associated with a white space master >>device which is mobile. >>The master device may query channel availability for a specific contour >>or >>a set of locations on a certain path for example. >>Hence this requirement is primarily about allowing the query to contain >>information that goes beyond just a specific lat/long co-ordinate. >> >>-Raj >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > From peter@spectrumbridge.com Tue Jan 17 15:41:05 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F511F0C52 for ; Tue, 17 Jan 2012 15:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czeCscR0OEWn for ; Tue, 17 Jan 2012 15:41:05 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6581F0C4B for ; Tue, 17 Jan 2012 15:41:04 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 17 Jan 2012 18:41:26 -0500 From: Peter Stanforth To: "Basavaraj.Patil@nokia.com" , "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Tue, 17 Jan 2012 18:41:03 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczVcYcW9fs7fzsBR5yydb7ltjbdDg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 23:41:05 -0000 This comment is a compound response to the "Security between the database and the white space radio". I have always believed that there is little reason to need to trust the radio - after all if it was going to do something malicious or illegal why would it even contact the database and request a channel list. In addition the impact of a single rouge radio is fairly limited. However the implications of a spoofed database that provides "all channels available everywhere" in response to channel queries could be catastrophic. I am finding it hard to evaluate this requirement, and the previous requirements in isolation. I think it would be better to consider the various threat levels and then decide how to provide reasonable protection against them in a comprehensive way. On TueJan/17/12 Tue Jan 17, 6:14 PM, "Basavaraj.Patil@nokia.com" wrote: > >Gabor, > >On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >wrote: > >>P.13: A master device MUST be capable of checking the validity of >> the WS Database certificate and whether it has been revoked >> or not. >> >>Note, P.13 requires support for OCSP (RFC2560) in the client, I am not >>sure if that is needed, please send your opinions. >> > > >If certificate based authentication is used by the protocol, then there >would be a need to mandate the above requirement. But at this time we have >no visibility about the authentication protocol to be used between the >master device and the WS database. So it is premature to specify the above >requirement. Hence I would favor dropping this requirement. > >-Raj > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Tue Jan 17 16:08:50 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800B121F84FA for ; Tue, 17 Jan 2012 16:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a15XAq-6sVqz for ; Tue, 17 Jan 2012 16:08:49 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9E21F849C for ; Tue, 17 Jan 2012 16:08:49 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0I08hCj012855; Wed, 18 Jan 2012 02:08:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 02:08:43 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 01:08:42 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrT+sAAAzYPYD//51gAIAAaHKA//+hogA= Date: Wed, 18 Jan 2012 00:08:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <640812DF4978F040BDFB89565F6C5C2A@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 00:08:43.0157 (UTC) FILETIME=[56D4AC50:01CCD575] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 00:08:50 -0000 Thanks.=20 I think the use-case would be useful to document in the I-D. It provides the proxy model use case for consideration. Rgds, -Raj On 1/17/12 5:46 PM, "ext Peter Stanforth" wrote: >Raj >I will look at the existing use cases again and either propose an update >or a new one. Two specific use cases. >One is an "AP" on a train or ferry serving white Space clients with a non >white space backhaul. This I believe is your mobile master. >The simplest scenario I can give is for a multi master solution - say a >collection of construction or farm equipment In the US today these would >all be classified as High Power and would have to individually request >channels however this is very inefficient and allowing some master to >proxy within a predefined area would be preferable. >Regards, >Peter S. > >On TueJan/17/12 Tue Jan 17, 6:32 PM, "Basavaraj.Patil@nokia.com" > wrote: > >> >>Hi Peter, >> >>I concur with your comment. Just a quick clarification question about the >>scenario wherein the mobile master is supporting devices that either roam >>within a polygon or cannot accurately locate themselves.. >>First of all I am not sure I understand what these other devices are that >>are relying on the master. Maybe a more complete use case description >>would help. >>We do not have such a scenario in the current document and could consider >>it. >> >>-Raj >> >>On 1/17/12 5:25 PM, "ext Peter Stanforth" >>wrote: >> >>>I would like to see this be described in a more generic way. I agree >>>with >>>Raj that this is all about providing information for more than a point >>>on >>>a map but there are several possible scenarios for which a query for a >>>"polygon" could be requested. It could be a very long thin polygon if >>>the >>>request is related to a road or railroad or a fairly square polygon if >>>the >>>request is for a venue or even a field. While the use case may be a >>>mobile master it could also be for a master that is supporting devices >>>that either roam within the polygon or cannot accurately locate >>>themselves >>>within the polygon. >>> >>>On TueJan/17/12 Tue Jan 17, 6:17 PM, "Basavaraj.Patil@nokia.com" >>> wrote: >>> >>>> >>>>Hi Gabor, >>>> >>>>On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>>>wrote: >>>> >>>>>We did not have any discussion on P.9, so I'd like to get comments on >>>>>the >>>>>list about this: >>>>> P.9: A master device MUST be able to query the whitespace >>>>> database for channel availability information for a >>>>> specific expected coverage area around its current >>>>> location. >>>> >>>>This requirement addresses the need associated with a white space >>>>master >>>>device which is mobile. >>>>The master device may query channel availability for a specific contour >>>>or >>>>a set of locations on a certain path for example. >>>>Hence this requirement is primarily about allowing the query to contain >>>>information that goes beyond just a specific lat/long co-ordinate. >>>> >>>>-Raj >>>> >>>>_______________________________________________ >>>>paws mailing list >>>>paws@ietf.org >>>>https://www.ietf.org/mailman/listinfo/paws >>> >> > From jmh@joelhalpern.com Tue Jan 17 18:03:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188FB1F0C40 for ; Tue, 17 Jan 2012 18:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynOloBeQKOex for ; Tue, 17 Jan 2012 18:03:08 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id AEB4E1F0C3F for ; Tue, 17 Jan 2012 18:03:08 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id A0E9CCD082 for ; Tue, 17 Jan 2012 18:03:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 83EAC2A0938; Tue, 17 Jan 2012 18:03:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 603FE2A0937; Tue, 17 Jan 2012 18:03:08 -0800 (PST) Message-ID: <4F16285A.4070900@joelhalpern.com> Date: Tue, 17 Jan 2012 21:03:06 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 02:03:09 -0000 While responses have time windows, as far as I know, requests do not specify when the response will be acted upon, if ever, or for how long. As such, this seems to imply either that we add significantly more information to requests, or that any change in anything that has ever been asked for gets pushed? That does not sound like a good design. Yours, Joel On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: > > Hi Gabor, > > On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" > wrote: > >> P.3 currently says: The protocol between the master device and the WS >> Database MUST support pushing updates in channel availability changes >> to subjects. >> There were comments that this requirement involves a mechanism, we should >> reformulate to be mechanism agnostic. >> There was a suggestion to "make the requirement "quick way to change >> availability" rather than imply a mechanism.". >> The use case is that if the channel availability changes in the DB, the >> client has to be able to detect it and get the new availability list >> within a time period set by the regulator. >> Can someone send suggested text on how to reformulate this requirement? > > The requirement to enable Push notifications to be sent to a white space > device which has registered with a database is important especially in the > context of Ofcom requirements (I believe). The reasons for such push > notifications could be for purposes that go beyond just channel > availability updates. A proposal for the requirement is as follows: > > Requirement: A white space database should be able to send unsolicited > messages to a master device which has registered with it. The protocol > between the WS database and master device MUST allow for push > notifications to be sent from the database to the master device. > > -Raj > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From Basavaraj.Patil@nokia.com Wed Jan 18 08:38:11 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7A21F87DE for ; Wed, 18 Jan 2012 08:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0165qxmjna8G for ; Wed, 18 Jan 2012 08:38:10 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88821F87F4 for ; Wed, 18 Jan 2012 08:38:10 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0IGc2it028233; Wed, 18 Jan 2012 18:38:06 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 18:38:03 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 17:38:02 +0100 From: To: Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAA== Date: Wed, 18 Jan 2012 16:38:01 +0000 Message-ID: In-Reply-To: <4F16285A.4070900@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <7724E9846FBA184D8430A02A5DB3E944@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 16:38:03.0404 (UTC) FILETIME=[8C4B8CC0:01CCD5FF] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:38:11 -0000 Hi Joel, The proposal to include unsolicited Push notifications from the white space database to a master device is different from the Request/Response mechanism itself. A master device making a request for available channels expects a response in some time window. Not proposing we change that. However the white space database knows of devices which have registered with it. And hence can send push notifications at will without necessarily having to react to a request. -Raj On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >While responses have time windows, as far as I know, requests do not >specify when the response will be acted upon, if ever, or for how long. > >As such, this seems to imply either that we add significantly more >information to requests, or that any change in anything that has ever >been asked for gets pushed? >That does not sound like a good design. > >Yours, >Joel > >On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >> >> Hi Gabor, >> >> On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >> wrote: >> >>> P.3 currently says: The protocol between the master device and the WS >>> Database MUST support pushing updates in channel availability changes >>> to subjects. >>> There were comments that this requirement involves a mechanism, we >>>should >>> reformulate to be mechanism agnostic. >>> There was a suggestion to "make the requirement "quick way to change >>> availability" rather than imply a mechanism.". >>> The use case is that if the channel availability changes in the DB, the >>> client has to be able to detect it and get the new availability list >>> within a time period set by the regulator. >>> Can someone send suggested text on how to reformulate this requirement? >> >> The requirement to enable Push notifications to be sent to a white space >> device which has registered with a database is important especially in >>the >> context of Ofcom requirements (I believe). The reasons for such push >> notifications could be for purposes that go beyond just channel >> availability updates. A proposal for the requirement is as follows: >> >> Requirement: A white space database should be able to send unsolicited >> messages to a master device which has registered with it. The protocol >> between the WS database and master device MUST allow for push >> notifications to be sent from the database to the master device. >> >> -Raj >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From jmh@joelhalpern.com Wed Jan 18 08:43:49 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5837621F875D for ; Wed, 18 Jan 2012 08:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 552j1A3hCAer for ; Wed, 18 Jan 2012 08:43:48 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id E0ACA21F8713 for ; Wed, 18 Jan 2012 08:43:48 -0800 (PST) Received: from mailb1.tigertech.net (mailb1.tigertech.net [208.80.4.153]) by morbo.tigertech.net (Postfix) with ESMTP id AB1E4CD04A for ; Wed, 18 Jan 2012 08:43:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb1.tigertech.net (Postfix) with ESMTP id BC28DD4083E; Wed, 18 Jan 2012 08:43:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at mailb1.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb1.tigertech.net (Postfix) with ESMTPSA id 81FB1D40839; Wed, 18 Jan 2012 08:43:46 -0800 (PST) Message-ID: <4F16F6C0.9060203@joelhalpern.com> Date: Wed, 18 Jan 2012 11:43:44 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:43:49 -0000 Sorry to be slow. How does the database know which changes are of interest to any particular registered client? I would hope that it does not push all changes to all clients. But i not, it needs to somehow guess which changes matter. Would it keep track of what answers it has sent to each such registered clients, and try to track which changes may affect actions of that client? Yours, Joel On 1/18/2012 11:38 AM, Basavaraj.Patil@nokia.com wrote: > > Hi Joel, > > The proposal to include unsolicited Push notifications from the white > space database to a master device is different from the Request/Response > mechanism itself. > A master device making a request for available channels expects a response > in some time window. Not proposing we change that. > However the white space database knows of devices which have registered > with it. And hence can send push notifications at will without necessarily > having to react to a request. > > -Raj > > On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: > >> While responses have time windows, as far as I know, requests do not >> specify when the response will be acted upon, if ever, or for how long. >> >> As such, this seems to imply either that we add significantly more >> information to requests, or that any change in anything that has ever >> been asked for gets pushed? >> That does not sound like a good design. >> >> Yours, >> Joel >> >> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> Hi Gabor, >>> >>> On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>> wrote: >>> >>>> P.3 currently says: The protocol between the master device and the WS >>>> Database MUST support pushing updates in channel availability changes >>>> to subjects. >>>> There were comments that this requirement involves a mechanism, we >>>> should >>>> reformulate to be mechanism agnostic. >>>> There was a suggestion to "make the requirement "quick way to change >>>> availability" rather than imply a mechanism.". >>>> The use case is that if the channel availability changes in the DB, the >>>> client has to be able to detect it and get the new availability list >>>> within a time period set by the regulator. >>>> Can someone send suggested text on how to reformulate this requirement? >>> >>> The requirement to enable Push notifications to be sent to a white space >>> device which has registered with a database is important especially in >>> the >>> context of Ofcom requirements (I believe). The reasons for such push >>> notifications could be for purposes that go beyond just channel >>> availability updates. A proposal for the requirement is as follows: >>> >>> Requirement: A white space database should be able to send unsolicited >>> messages to a master device which has registered with it. The protocol >>> between the WS database and master device MUST allow for push >>> notifications to be sent from the database to the master device. >>> >>> -Raj >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> > > From Basavaraj.Patil@nokia.com Wed Jan 18 08:51:04 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1BB21F87FE for ; Wed, 18 Jan 2012 08:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSAeNgZwGcE7 for ; Wed, 18 Jan 2012 08:51:04 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1A18F21F87F9 for ; Wed, 18 Jan 2012 08:51:00 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0IGoxIl015210; Wed, 18 Jan 2012 18:51:00 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 18:50:58 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 17:50:58 +0100 From: To: Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAAMw4cA//+dhoA= Date: Wed, 18 Jan 2012 16:50:57 +0000 Message-ID: In-Reply-To: <4F16F6C0.9060203@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <0654CCFEEF1A9D4A9FC1F194F9CBCC52@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 16:50:58.0722 (UTC) FILETIME=[5A6BB020:01CCD601] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:51:05 -0000 An example: A white space database may decide to withdraw channels that were previously indicated as being available for use to a set of master devices (reason being a need for those channels by some emergency service). Devices register with the database as part of the initial authentication/authorization process and hence the database would have the capability of sending such messages only to the relevant devices and not to all devices. It does result in state being maintained at the database. The requirement for such capability is needed by Ofcom (AFAIK) and hence the proposal. Solutions will need to consider how to deal with this optimally. -Raj On 1/18/12 10:43 AM, "ext Joel M. Halpern" wrote: >Sorry to be slow. >How does the database know which changes are of interest to any >particular registered client? I would hope that it does not push all >changes to all clients. But i not, it needs to somehow guess which >changes matter. Would it keep track of what answers it has sent to each >such registered clients, and try to track which changes may affect >actions of that client? > >Yours, >Joel > >On 1/18/2012 11:38 AM, Basavaraj.Patil@nokia.com wrote: >> >> Hi Joel, >> >> The proposal to include unsolicited Push notifications from the white >> space database to a master device is different from the Request/Response >> mechanism itself. >> A master device making a request for available channels expects a >>response >> in some time window. Not proposing we change that. >> However the white space database knows of devices which have registered >> with it. And hence can send push notifications at will without >>necessarily >> having to react to a request. >> >> -Raj >> >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >> >>> While responses have time windows, as far as I know, requests do not >>> specify when the response will be acted upon, if ever, or for how long. >>> >>> As such, this seems to imply either that we add significantly more >>> information to requests, or that any change in anything that has ever >>> been asked for gets pushed? >>> That does not sound like a good design. >>> >>> Yours, >>> Joel >>> >>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> Hi Gabor, >>>> >>>> On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>>> wrote: >>>> >>>>> P.3 currently says: The protocol between the master device and the >>>>>WS >>>>> Database MUST support pushing updates in channel availability >>>>>changes >>>>> to subjects. >>>>> There were comments that this requirement involves a mechanism, we >>>>> should >>>>> reformulate to be mechanism agnostic. >>>>> There was a suggestion to "make the requirement "quick way to change >>>>> availability" rather than imply a mechanism.". >>>>> The use case is that if the channel availability changes in the DB, >>>>>the >>>>> client has to be able to detect it and get the new availability list >>>>> within a time period set by the regulator. >>>>> Can someone send suggested text on how to reformulate this >>>>>requirement? >>>> >>>> The requirement to enable Push notifications to be sent to a white >>>>space >>>> device which has registered with a database is important especially in >>>> the >>>> context of Ofcom requirements (I believe). The reasons for such push >>>> notifications could be for purposes that go beyond just channel >>>> availability updates. A proposal for the requirement is as follows: >>>> >>>> Requirement: A white space database should be able to send unsolicited >>>> messages to a master device which has registered with it. The protocol >>>> between the WS database and master device MUST allow for push >>>> notifications to be sent from the database to the master device. >>>> >>>> -Raj >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >> >> From andy.sago@bt.com Wed Jan 18 09:22:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1593521F8555 for ; Wed, 18 Jan 2012 09:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6N9j6rZQDCK for ; Wed, 18 Jan 2012 09:22:20 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2421F84C3 for ; Wed, 18 Jan 2012 09:22:19 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Jan 2012 17:22:17 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.215]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 18 Jan 2012 17:22:17 +0000 From: To: , Date: Wed, 18 Jan 2012 17:22:15 +0000 Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAAMw4cA//+dhoD//4a1AA== Message-ID: <619CDADDCCD2B44380834BE8BF6F7141405FFC0552@EMV62-UKRD.domain1.systemhost.net> References: <4F16F6C0.9060203@joelhalpern.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 17:22:21 -0000 A clarification with regard to the need for push notifications. I am not aw= are that this is an Ofcom requirement. In their last consultation Ofcom's d= escription of a master device says that it must "cease transmission immedia= tely where the time validity expires or where it moves outside of the geogr= aphic area of validity". The master polls every x hours (e.g. every two hou= rs), using a periodicity set by regulation, in order to maintain validity f= or the TVWS channel it is using, and does not need to be able to receive pu= shed information. This works because any changes to channel availability (d= ue to a local news event requiring wireless microphones for example) have a= lead time, which give the opportunity for the channel to be cleared. Micro= phones needing to be operational more quickly than x hours could be operate= d in other spectrum (for example). The same process would enable a network = to be turned off within x hours if Ofcom so desired. Having said that, I am in favour of there being a push capability from the = database to masters. I just think it would not be implemented by all master= s if not required the regulator, so would be optional. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bas= avaraj.Patil@nokia.com Sent: 18 January 2012 16:51 To: jmh@joelhalpern.com Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg An example: A white space database may decide to withdraw channels that were previously= indicated as being available for use to a set of master devices (reason be= ing a need for those channels by some emergency service). Devices register with the database as part of the initial authentication/au= thorization process and hence the database would have the capability of sen= ding such messages only to the relevant devices and not to all devices. It does result in state being maintained at the database. The requirement for such capability is needed by Ofcom (AFAIK) and hence th= e proposal. Solutions will need to consider how to deal with this optimally. -Raj On 1/18/12 10:43 AM, "ext Joel M. Halpern" wrote: >Sorry to be slow. >How does the database know which changes are of interest to any=20 >particular registered client? I would hope that it does not push all=20 >changes to all clients. But i not, it needs to somehow guess which=20 >changes matter. Would it keep track of what answers it has sent to=20 >each such registered clients, and try to track which changes may affect=20 >actions of that client? > >Yours, >Joel > >On 1/18/2012 11:38 AM, Basavaraj.Patil@nokia.com wrote: >> >> Hi Joel, >> >> The proposal to include unsolicited Push notifications from the white =20 >>space database to a master device is different from the=20 >>Request/Response mechanism itself. >> A master device making a request for available channels expects a=20 >>response in some time window. Not proposing we change that. >> However the white space database knows of devices which have=20 >>registered with it. And hence can send push notifications at will=20 >>without necessarily having to react to a request. >> >> -Raj >> >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >> >>> While responses have time windows, as far as I know, requests do not=20 >>> specify when the response will be acted upon, if ever, or for how long. >>> >>> As such, this seems to imply either that we add significantly more=20 >>> information to requests, or that any change in anything that has=20 >>> ever been asked for gets pushed? >>> That does not sound like a good design. >>> >>> Yours, >>> Joel >>> >>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> Hi Gabor, >>>> >>>> On 1/12/12 8:26 PM, "ext=20 >>>> Gabor.Bajko@nokia.com" >>>> wrote: >>>> >>>>> P.3 currently says: The protocol between the master device and=20 >>>>>the WS Database MUST support pushing updates in channel=20 >>>>>availability changes to subjects. >>>>> There were comments that this requirement involves a mechanism, we =20 >>>>>should reformulate to be mechanism agnostic. >>>>> There was a suggestion to "make the requirement "quick way to=20 >>>>>change availability" rather than imply a mechanism.". >>>>> The use case is that if the channel availability changes in the=20 >>>>>DB, the client has to be able to detect it and get the new=20 >>>>>availability list within a time period set by the regulator. >>>>> Can someone send suggested text on how to reformulate this=20 >>>>>requirement? >>>> >>>> The requirement to enable Push notifications to be sent to a white=20 >>>>space device which has registered with a database is important=20 >>>>especially in the context of Ofcom requirements (I believe). The=20 >>>>reasons for such push notifications could be for purposes that go=20 >>>>beyond just channel availability updates. A proposal for the=20 >>>>requirement is as follows: >>>> >>>> Requirement: A white space database should be able to send=20 >>>> unsolicited messages to a master device which has registered with=20 >>>> it. The protocol between the WS database and master device MUST=20 >>>> allow for push notifications to be sent from the database to the maste= r device. >>>> >>>> -Raj >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >> >> _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Jan 18 09:28:55 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7E21F8636 for ; Wed, 18 Jan 2012 09:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH2JF1Z3zMF2 for ; Wed, 18 Jan 2012 09:28:54 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2685721F8631 for ; Wed, 18 Jan 2012 09:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1326907730; x=1642263144; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=f/grqUkv7BbJrK4SIU181 a/7mBpYU9ozzjoJAqqQFgk=; b=h5vXO9mORX5N3m5JeqlzRUTMd6SWoq92Fcgnm LbJ1ytn4W1tGf7ZYuoFL58oBHhbFGvYaFdwbR/AWsGvKv0ZbQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.3727371; Wed, 18 Jan 2012 12:28:49 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 18 Jan 2012 12:28:47 -0500 From: "Rosen, Brian" To: "" Date: Wed, 18 Jan 2012 12:28:45 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczWBqJQW4lOzeaMQOasuFRNUCJ1IA== Message-ID: <6855DB93-3541-47FE-BC64-9BCA98921AFD@neustar.biz> References: <4F16F6C0.9060203@joelhalpern.com> <619CDADDCCD2B44380834BE8BF6F7141405FFC0552@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141405FFC0552@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: SN0VVvSvFSqDmtYaxRlA/Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 17:28:55 -0000 I also think it's a valuable capability. =20 Brian On Jan 18, 2012, at 12:22 PM, wrote: > A clarification with regard to the need for push notifications. I am not = aware that this is an Ofcom requirement. In their last consultation Ofcom's= description of a master device says that it must "cease transmission immed= iately where the time validity expires or where it moves outside of the geo= graphic area of validity". The master polls every x hours (e.g. every two h= ours), using a periodicity set by regulation, in order to maintain validity= for the TVWS channel it is using, and does not need to be able to receive = pushed information. This works because any changes to channel availability = (due to a local news event requiring wireless microphones for example) have= a lead time, which give the opportunity for the channel to be cleared. Mic= rophones needing to be operational more quickly than x hours could be opera= ted in other spectrum (for example). The same process would enable a networ= k to be turned off within x hours if Ofcom so desired. >=20 > Having said that, I am in favour of there being a push capability from th= e database to masters. I just think it would not be implemented by all mast= ers if not required the regulator, so would be optional. >=20 > Regards >=20 > Andy >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of B= asavaraj.Patil@nokia.com > Sent: 18 January 2012 16:51 > To: jmh@joelhalpern.com > Cc: paws@ietf.org > Subject: Re: [paws] next steps for the wg >=20 >=20 > An example: > A white space database may decide to withdraw channels that were previous= ly indicated as being available for use to a set of master devices (reason = being a need for those channels by some emergency service). > Devices register with the database as part of the initial authentication/= authorization process and hence the database would have the capability of s= ending such messages only to the relevant devices and not to all devices. > It does result in state being maintained at the database. >=20 > The requirement for such capability is needed by Ofcom (AFAIK) and hence = the proposal. >=20 > Solutions will need to consider how to deal with this optimally. >=20 > -Raj >=20 > On 1/18/12 10:43 AM, "ext Joel M. Halpern" wrote: >=20 >> Sorry to be slow. >> How does the database know which changes are of interest to any=20 >> particular registered client? I would hope that it does not push all=20 >> changes to all clients. But i not, it needs to somehow guess which=20 >> changes matter. Would it keep track of what answers it has sent to=20 >> each such registered clients, and try to track which changes may affect= =20 >> actions of that client? >>=20 >> Yours, >> Joel >>=20 >> On 1/18/2012 11:38 AM, Basavaraj.Patil@nokia.com wrote: >>>=20 >>> Hi Joel, >>>=20 >>> The proposal to include unsolicited Push notifications from the white = =20 >>> space database to a master device is different from the=20 >>> Request/Response mechanism itself. >>> A master device making a request for available channels expects a=20 >>> response in some time window. Not proposing we change that. >>> However the white space database knows of devices which have=20 >>> registered with it. And hence can send push notifications at will=20 >>> without necessarily having to react to a request. >>>=20 >>> -Raj >>>=20 >>> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >>>=20 >>>> While responses have time windows, as far as I know, requests do not=20 >>>> specify when the response will be acted upon, if ever, or for how long= . >>>>=20 >>>> As such, this seems to imply either that we add significantly more=20 >>>> information to requests, or that any change in anything that has=20 >>>> ever been asked for gets pushed? >>>> That does not sound like a good design. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>>>=20 >>>>> Hi Gabor, >>>>>=20 >>>>> On 1/12/12 8:26 PM, "ext=20 >>>>> Gabor.Bajko@nokia.com" >>>>> wrote: >>>>>=20 >>>>>> P.3 currently says: The protocol between the master device and=20 >>>>>> the WS Database MUST support pushing updates in channel=20 >>>>>> availability changes to subjects. >>>>>> There were comments that this requirement involves a mechanism, we = =20 >>>>>> should reformulate to be mechanism agnostic. >>>>>> There was a suggestion to "make the requirement "quick way to=20 >>>>>> change availability" rather than imply a mechanism.". >>>>>> The use case is that if the channel availability changes in the=20 >>>>>> DB, the client has to be able to detect it and get the new=20 >>>>>> availability list within a time period set by the regulator. >>>>>> Can someone send suggested text on how to reformulate this=20 >>>>>> requirement? >>>>>=20 >>>>> The requirement to enable Push notifications to be sent to a white=20 >>>>> space device which has registered with a database is important=20 >>>>> especially in the context of Ofcom requirements (I believe). The=20 >>>>> reasons for such push notifications could be for purposes that go=20 >>>>> beyond just channel availability updates. A proposal for the=20 >>>>> requirement is as follows: >>>>>=20 >>>>> Requirement: A white space database should be able to send=20 >>>>> unsolicited messages to a master device which has registered with=20 >>>>> it. The protocol between the WS database and master device MUST=20 >>>>> allow for push notifications to be sent from the database to the mast= er device. >>>>>=20 >>>>> -Raj >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Wed Jan 18 09:30:42 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29511E80B2 for ; Wed, 18 Jan 2012 09:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmqJXQtYVmGq for ; Wed, 18 Jan 2012 09:30:41 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0769D11E80AE for ; Wed, 18 Jan 2012 09:30:40 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0IHUcUD009309; Wed, 18 Jan 2012 19:30:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 19:30:38 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Wed, 18 Jan 2012 18:30:37 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAAMw4cA//+dhoD//4a1AIAAhF6A Date: Wed, 18 Jan 2012 17:30:36 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141405FFC0552@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <971A4595B6881643956DC8FF1DCCAE41@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jan 2012 17:30:38.0241 (UTC) FILETIME=[E4B97910:01CCD606] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 17:30:42 -0000 Thanks for the clarification Andy. I agree that the feature could be optional. -Raj On 1/18/12 11:22 AM, "ext andy.sago@bt.com" wrote: >A clarification with regard to the need for push notifications. I am not >aware that this is an Ofcom requirement. In their last consultation >Ofcom's description of a master device says that it must "cease >transmission immediately where the time validity expires or where it >moves outside of the geographic area of validity". The master polls every >x hours (e.g. every two hours), using a periodicity set by regulation, in >order to maintain validity for the TVWS channel it is using, and does not >need to be able to receive pushed information. This works because any >changes to channel availability (due to a local news event requiring >wireless microphones for example) have a lead time, which give the >opportunity for the channel to be cleared. Microphones needing to be >operational more quickly than x hours could be operated in other spectrum >(for example). The same process would enable a network to be turned off >within x hours if Ofcom so desired. > >Having said that, I am in favour of there being a push capability from >the database to masters. I just think it would not be implemented by all >masters if not required the regulator, so would be optional. > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Basavaraj.Patil@nokia.com >Sent: 18 January 2012 16:51 >To: jmh@joelhalpern.com >Cc: paws@ietf.org >Subject: Re: [paws] next steps for the wg > > >An example: >A white space database may decide to withdraw channels that were >previously indicated as being available for use to a set of master >devices (reason being a need for those channels by some emergency >service). >Devices register with the database as part of the initial >authentication/authorization process and hence the database would have >the capability of sending such messages only to the relevant devices and >not to all devices. >It does result in state being maintained at the database. > >The requirement for such capability is needed by Ofcom (AFAIK) and hence >the proposal. > >Solutions will need to consider how to deal with this optimally. > >-Raj > >On 1/18/12 10:43 AM, "ext Joel M. Halpern" wrote: > >>Sorry to be slow. >>How does the database know which changes are of interest to any >>particular registered client? I would hope that it does not push all >>changes to all clients. But i not, it needs to somehow guess which >>changes matter. Would it keep track of what answers it has sent to >>each such registered clients, and try to track which changes may affect >>actions of that client? >> >>Yours, >>Joel >> >>On 1/18/2012 11:38 AM, Basavaraj.Patil@nokia.com wrote: >>> >>> Hi Joel, >>> >>> The proposal to include unsolicited Push notifications from the white >>>space database to a master device is different from the >>>Request/Response mechanism itself. >>> A master device making a request for available channels expects a >>>response in some time window. Not proposing we change that. >>> However the white space database knows of devices which have >>>registered with it. And hence can send push notifications at will >>>without necessarily having to react to a request. >>> >>> -Raj >>> >>> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >>> >>>> While responses have time windows, as far as I know, requests do not >>>> specify when the response will be acted upon, if ever, or for how >>>>long. >>>> >>>> As such, this seems to imply either that we add significantly more >>>> information to requests, or that any change in anything that has >>>> ever been asked for gets pushed? >>>> That does not sound like a good design. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> Hi Gabor, >>>>> >>>>> On 1/12/12 8:26 PM, "ext >>>>> Gabor.Bajko@nokia.com" >>>>> wrote: >>>>> >>>>>> P.3 currently says: The protocol between the master device and >>>>>>the WS Database MUST support pushing updates in channel >>>>>>availability changes to subjects. >>>>>> There were comments that this requirement involves a mechanism, we >>>>>>should reformulate to be mechanism agnostic. >>>>>> There was a suggestion to "make the requirement "quick way to >>>>>>change availability" rather than imply a mechanism.". >>>>>> The use case is that if the channel availability changes in the >>>>>>DB, the client has to be able to detect it and get the new >>>>>>availability list within a time period set by the regulator. >>>>>> Can someone send suggested text on how to reformulate this >>>>>>requirement? >>>>> >>>>> The requirement to enable Push notifications to be sent to a white >>>>>space device which has registered with a database is important >>>>>especially in the context of Ofcom requirements (I believe). The >>>>>reasons for such push notifications could be for purposes that go >>>>>beyond just channel availability updates. A proposal for the >>>>>requirement is as follows: >>>>> >>>>> Requirement: A white space database should be able to send >>>>> unsolicited messages to a master device which has registered with >>>>> it. The protocol between the WS database and master device MUST >>>>> allow for push notifications to be sent from the database to the >>>>>master device. >>>>> >>>>> -Raj >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>> >>> > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Wed Jan 18 09:45:04 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770A911E8085 for ; Wed, 18 Jan 2012 09:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za4pB3KbubbM for ; Wed, 18 Jan 2012 09:45:03 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD521F857D for ; Wed, 18 Jan 2012 09:45:03 -0800 (PST) Received: from EVMHT69-UKRD.domain1.systemhost.net (10.36.3.129) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Jan 2012 17:45:02 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.215]) by EVMHT69-UKRD.domain1.systemhost.net ([10.36.3.129]) with mapi; Wed, 18 Jan 2012 17:45:02 +0000 From: To: , , Date: Wed, 18 Jan 2012 17:45:01 +0000 Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrT+sAAAzYPYD//51gAIAAaHKA//+hogD//mVE4A== Message-ID: <619CDADDCCD2B44380834BE8BF6F7141405FFC0584@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 17:45:04 -0000 I agree the proxy master concept should be documented. Mike Fitch, Juan Car= los Zuniga and I are drafting an expansion of the M2M use case (as requeste= d at the last F2F) which already alludes to the proxy concept. Including it= in the M2M use case may be sufficient to draw out the requirements. We wil= l post the use case update this week on the reflector. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bas= avaraj.Patil@nokia.com Sent: 18 January 2012 00:09 To: peter@spectrumbridge.com; paws@ietf.org Subject: Re: [paws] next steps for the wg Thanks.=20 I think the use-case would be useful to document in the I-D. It provides th= e proxy model use case for consideration. Rgds, -Raj On 1/17/12 5:46 PM, "ext Peter Stanforth" wrote: >Raj >I will look at the existing use cases again and either propose an=20 >update or a new one. Two specific use cases. >One is an "AP" on a train or ferry serving white Space clients with a=20 >non white space backhaul. This I believe is your mobile master. >The simplest scenario I can give is for a multi master solution - say a=20 >collection of construction or farm equipment In the US today these=20 >would all be classified as High Power and would have to individually=20 >request channels however this is very inefficient and allowing some=20 >master to proxy within a predefined area would be preferable. >Regards, >Peter S. > >On TueJan/17/12 Tue Jan 17, 6:32 PM, "Basavaraj.Patil@nokia.com" > wrote: > >> >>Hi Peter, >> >>I concur with your comment. Just a quick clarification question about=20 >>the scenario wherein the mobile master is supporting devices that=20 >>either roam within a polygon or cannot accurately locate themselves.. >>First of all I am not sure I understand what these other devices are=20 >>that are relying on the master. Maybe a more complete use case=20 >>description would help. >>We do not have such a scenario in the current document and could=20 >>consider it. >> >>-Raj >> >>On 1/17/12 5:25 PM, "ext Peter Stanforth" >>wrote: >> >>>I would like to see this be described in a more generic way. I agree=20 >>>with Raj that this is all about providing information for more than a=20 >>>point on a map but there are several possible scenarios for which a=20 >>>query for a "polygon" could be requested. It could be a very long=20 >>>thin polygon if the request is related to a road or railroad or a=20 >>>fairly square polygon if the request is for a venue or even a field. =20 >>>While the use case may be a mobile master it could also be for a=20 >>>master that is supporting devices that either roam within the polygon=20 >>>or cannot accurately locate themselves within the polygon. >>> >>>On TueJan/17/12 Tue Jan 17, 6:17 PM, "Basavaraj.Patil@nokia.com" >>> wrote: >>> >>>> >>>>Hi Gabor, >>>> >>>>On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com"=20 >>>> >>>>wrote: >>>> >>>>>We did not have any discussion on P.9, so I'd like to get comments=20 >>>>>on the list about this: >>>>> P.9: A master device MUST be able to query the whitespace >>>>> database for channel availability information for a >>>>> specific expected coverage area around its current >>>>> location. >>>> >>>>This requirement addresses the need associated with a white space=20 >>>>master device which is mobile. >>>>The master device may query channel availability for a specific=20 >>>>contour or a set of locations on a certain path for example. >>>>Hence this requirement is primarily about allowing the query to=20 >>>>contain information that goes beyond just a specific lat/long co-ordina= te. >>>> >>>>-Raj >>>> >>>>_______________________________________________ >>>>paws mailing list >>>>paws@ietf.org >>>>https://www.ietf.org/mailman/listinfo/paws >>> >> > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Thu Jan 19 05:40:38 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FD221F860B for ; Thu, 19 Jan 2012 05:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeVKb5nXa5Fu for ; Thu, 19 Jan 2012 05:40:38 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id C391721F8543 for ; Thu, 19 Jan 2012 05:40:37 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 19 Jan 2012 08:41:02 -0500 From: Peter Stanforth To: "Basavaraj.Patil@nokia.com" , "jmh@joelhalpern.com" Date: Thu, 19 Jan 2012 08:40:36 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczWr/r9sU5nGfP4SaKdqjUJK2Gciw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:40:38 -0000 I would like to suggest that we back up and ask the question. How do we pre-empt a device if the primary spectrum user needs it back? The use case I can think of is public safety, where they don't generally need the spectrum until there is an emergency. They do not know when or where that will happen so they would need a mechanism to clear the spectrum in a specific location quickly. A push mechanisms only one way to do this. Another, off the top of my head is to only give channel permissions for time durations less than the time they need to clear the channels. There may be other options and there are clearly advantages and disadvantages to all. Peter S. On WedJan/18/12 Wed Jan 18, 11:38 AM, "Basavaraj.Patil@nokia.com" wrote: > >Hi Joel, > >The proposal to include unsolicited Push notifications from the white >space database to a master device is different from the Request/Response >mechanism itself. >A master device making a request for available channels expects a response >in some time window. Not proposing we change that. >However the white space database knows of devices which have registered >with it. And hence can send push notifications at will without necessarily >having to react to a request. > >-Raj > >On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: > >>While responses have time windows, as far as I know, requests do not >>specify when the response will be acted upon, if ever, or for how long. >> >>As such, this seems to imply either that we add significantly more >>information to requests, or that any change in anything that has ever >>been asked for gets pushed? >>That does not sound like a good design. >> >>Yours, >>Joel >> >>On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> Hi Gabor, >>> >>> On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>> wrote: >>> >>>> P.3 currently says: The protocol between the master device and the WS >>>> Database MUST support pushing updates in channel availability >>>>changes >>>> to subjects. >>>> There were comments that this requirement involves a mechanism, we >>>>should >>>> reformulate to be mechanism agnostic. >>>> There was a suggestion to "make the requirement "quick way to change >>>> availability" rather than imply a mechanism.". >>>> The use case is that if the channel availability changes in the DB, >>>>the >>>> client has to be able to detect it and get the new availability list >>>> within a time period set by the regulator. >>>> Can someone send suggested text on how to reformulate this >>>>requirement? >>> >>> The requirement to enable Push notifications to be sent to a white >>>space >>> device which has registered with a database is important especially in >>>the >>> context of Ofcom requirements (I believe). The reasons for such push >>> notifications could be for purposes that go beyond just channel >>> availability updates. A proposal for the requirement is as follows: >>> >>> Requirement: A white space database should be able to send unsolicited >>> messages to a master device which has registered with it. The protocol >>> between the WS database and master device MUST allow for push >>> notifications to be sent from the database to the master device. >>> >>> -Raj >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Thu Jan 19 05:59:33 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C8221F852B for ; Thu, 19 Jan 2012 05:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm-qE2nS4uHf for ; Thu, 19 Jan 2012 05:59:32 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 766F821F8513 for ; Thu, 19 Jan 2012 05:59:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PWWOu3D23hZuDBlmCfyZs0RAxuVe79qpbpAyG4Dc3GKWGp4U1p19C0Yc0TzLfqhE; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RnsWI-0000jR-LK; Thu, 19 Jan 2012 08:59:14 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: Date: Thu, 19 Jan 2012 05:58:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Stanforth X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86b2b31b66ba1a25a0df3ed6670ac56873350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:59:33 -0000 Peter et all,=20 I agree. One thing that concerned me greatly was a statement made a = while ago that it would take five minutes to clear a frequency for an = emergency so I am glad to see some further discussion on how to do this. I can imagine that FIVE = minutes for someone having a heart attack, in a critical accident,=20 loosing blood quickly, or many other scenarios could potentially cause = deaths before first responders, EMT's, Ambulances or any other medical help arrived at the scene with a 5 minute lag time. This seems to be = something that can be done pre emptively and immediately and to me, = should be. My two cents.=20 SIncerely, Nancy Bravin On Jan 19, 2012, at 5:40 AM, Peter Stanforth wrote: > I would like to suggest that we back up and ask the question. How do = we > pre-empt a device if the primary spectrum user needs it back? The use = case > I can think of is public safety, where they don't generally need the > spectrum until there is an emergency. They do not know when or where = that > will happen so they would need a mechanism to clear the spectrum in a > specific location quickly. > A push mechanisms only one way to do this. Another, off the top of my = head > is to only give channel permissions for time durations less than the = time > they need to clear the channels. There may be other options and there = are > clearly advantages and disadvantages to all. > Peter S. >=20 > On WedJan/18/12 Wed Jan 18, 11:38 AM, "Basavaraj.Patil@nokia.com" > wrote: >=20 >>=20 >> Hi Joel, >>=20 >> The proposal to include unsolicited Push notifications from the white >> space database to a master device is different from the = Request/Response >> mechanism itself. >> A master device making a request for available channels expects a = response >> in some time window. Not proposing we change that. >> However the white space database knows of devices which have = registered >> with it. And hence can send push notifications at will without = necessarily >> having to react to a request. >>=20 >> -Raj >>=20 >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" = wrote: >>=20 >>> While responses have time windows, as far as I know, requests do not >>> specify when the response will be acted upon, if ever, or for how = long. >>>=20 >>> As such, this seems to imply either that we add significantly more >>> information to requests, or that any change in anything that has = ever >>> been asked for gets pushed? >>> That does not sound like a good design. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>>=20 >>>> Hi Gabor, >>>>=20 >>>> On 1/12/12 8:26 PM, "ext = Gabor.Bajko@nokia.com" >>>> wrote: >>>>=20 >>>>> P.3 currently says: The protocol between the master device and = the WS >>>>> Database MUST support pushing updates in channel availability >>>>> changes >>>>> to subjects. >>>>> There were comments that this requirement involves a mechanism, we >>>>> should >>>>> reformulate to be mechanism agnostic. >>>>> There was a suggestion to "make the requirement "quick way to = change >>>>> availability" rather than imply a mechanism.". >>>>> The use case is that if the channel availability changes in the = DB, >>>>> the >>>>> client has to be able to detect it and get the new availability = list >>>>> within a time period set by the regulator. >>>>> Can someone send suggested text on how to reformulate this >>>>> requirement? >>>>=20 >>>> The requirement to enable Push notifications to be sent to a white >>>> space >>>> device which has registered with a database is important especially = in >>>> the >>>> context of Ofcom requirements (I believe). The reasons for such = push >>>> notifications could be for purposes that go beyond just channel >>>> availability updates. A proposal for the requirement is as follows: >>>>=20 >>>> Requirement: A white space database should be able to send = unsolicited >>>> messages to a master device which has registered with it. The = protocol >>>> between the WS database and master device MUST allow for push >>>> notifications to be sent from the database to the master device. >>>>=20 >>>> -Raj >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Thu Jan 19 06:09:07 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154EE21F850F for ; Thu, 19 Jan 2012 06:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nFhEyKiwrp7 for ; Thu, 19 Jan 2012 06:09:06 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3889321F8510 for ; Thu, 19 Jan 2012 06:09:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1326982146; x=1642315347; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=2ZO5braDFO3sx9itXQdhz BDBlcW8HRt5TkQa8NrjZGc=; b=nVEAUJYVkwu9mc2kjeLsk683VAO9OA2IeNGiv TNrWrzZrKRITfmP6v556bbWYv5Aw4FOIG2YfSFrSzupXEFZvg== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.3755361; Thu, 19 Jan 2012 09:09:04 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 19 Jan 2012 09:09:02 -0500 From: "Rosen, Brian" To: Peter Stanforth Date: Thu, 19 Jan 2012 09:08:38 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczWs+UFfrPik+gOSwyNrOhLzZwBfA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: +DzZ94J55Rl0rTYDf0DUrA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 14:09:07 -0000 At this stage, we should say that we have a requirement to change availabil= ity of spectrum on a short notice, we need a use case that would motivate s= ome decision on what "short" means, and we should not worry about which mec= hanism we should choose to achieve it. Push, fast poll, and notice broadcast (i.e. a single bit sent to all client= s telling them to "phone home" soon) are all reasonable mechanisms to meet = the requirements. Brian On Jan 19, 2012, at 8:40 AM, Peter Stanforth wrote: > I would like to suggest that we back up and ask the question. How do we > pre-empt a device if the primary spectrum user needs it back? The use cas= e > I can think of is public safety, where they don't generally need the > spectrum until there is an emergency. They do not know when or where that > will happen so they would need a mechanism to clear the spectrum in a > specific location quickly. > A push mechanisms only one way to do this. Another, off the top of my hea= d > is to only give channel permissions for time durations less than the time > they need to clear the channels. There may be other options and there are > clearly advantages and disadvantages to all. > Peter S. >=20 > On WedJan/18/12 Wed Jan 18, 11:38 AM, "Basavaraj.Patil@nokia.com" > wrote: >=20 >>=20 >> Hi Joel, >>=20 >> The proposal to include unsolicited Push notifications from the white >> space database to a master device is different from the Request/Response >> mechanism itself. >> A master device making a request for available channels expects a respon= se >> in some time window. Not proposing we change that. >> However the white space database knows of devices which have registered >> with it. And hence can send push notifications at will without necessari= ly >> having to react to a request. >>=20 >> -Raj >>=20 >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >>=20 >>> While responses have time windows, as far as I know, requests do not >>> specify when the response will be acted upon, if ever, or for how long. >>>=20 >>> As such, this seems to imply either that we add significantly more >>> information to requests, or that any change in anything that has ever >>> been asked for gets pushed? >>> That does not sound like a good design. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>>=20 >>>> Hi Gabor, >>>>=20 >>>> On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>>> wrote: >>>>=20 >>>>> P.3 currently says: The protocol between the master device and the W= S >>>>> Database MUST support pushing updates in channel availability >>>>> changes >>>>> to subjects. >>>>> There were comments that this requirement involves a mechanism, we >>>>> should >>>>> reformulate to be mechanism agnostic. >>>>> There was a suggestion to "make the requirement "quick way to change >>>>> availability" rather than imply a mechanism.". >>>>> The use case is that if the channel availability changes in the DB, >>>>> the >>>>> client has to be able to detect it and get the new availability list >>>>> within a time period set by the regulator. >>>>> Can someone send suggested text on how to reformulate this >>>>> requirement? >>>>=20 >>>> The requirement to enable Push notifications to be sent to a white >>>> space >>>> device which has registered with a database is important especially in >>>> the >>>> context of Ofcom requirements (I believe). The reasons for such push >>>> notifications could be for purposes that go beyond just channel >>>> availability updates. A proposal for the requirement is as follows: >>>>=20 >>>> Requirement: A white space database should be able to send unsolicited >>>> messages to a master device which has registered with it. The protocol >>>> between the WS database and master device MUST allow for push >>>> notifications to be sent from the database to the master device. >>>>=20 >>>> -Raj >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Jan 19 06:25:41 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9384821F8591 for ; Thu, 19 Jan 2012 06:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kItz9PO7UuMh for ; Thu, 19 Jan 2012 06:25:40 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6860921F8576 for ; Thu, 19 Jan 2012 06:25:40 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0JEPS2P025635; Thu, 19 Jan 2012 16:25:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 16:25:28 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.241]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 19 Jan 2012 15:25:27 +0100 From: To: , Thread-Topic: P.3 Requirement (was: next steps for the wg) Thread-Index: AczWtf/JynFd5BmBSvqTYZnptu3MAQ== Date: Thu, 19 Jan 2012 14:25:26 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB433@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.52.73.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 14:25:28.0478 (UTC) FILETIME=[3133EBE0:01CCD6B6] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] P.3 Requirement (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 14:25:41 -0000 We have a related use case in the document: 4.7. Rapid deployed network for emergency scenario Organizations involved in handling emergency operations often have a fully owned and controlled infrastructure, with dedicated spectrum, for day to day operation. However, lessons learned from recent disasters show such infrastructures are often highly affected by the disaster itself. To set up a replacement quickly, there is a need for fast reallocation of spectrum, where in certain cases spectrum can be freed for disaster relief. To utilize free or freed spectrum quickly and reliable, automation of allocation, assignment and configuration is needed. A preferred option is make use of a robust protocol, already adopted by radio manufacturers. This approach does in no way imply such organizations for disaster relief must compete on spectrum allocation with other white spaces users, but they can. A typical network topology would include wireless access links to the public Internet or private network, wireless ad hoc network radios working independent of a fixed infrastructure and satellite links for backup where lack of coverage, overload or outage of wireless access links occur. So it seems we'll need a requirement to free spectrum on a short notice. Fr= om the above use case my reading is that 'short' is close to instantaneous. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Rosen, Brian Sent: Thursday, January 19, 2012 6:09 AM To: Peter Stanforth Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg At this stage, we should say that we have a requirement to change availabil= ity of spectrum on a short notice, we need a use case that would motivate s= ome decision on what "short" means, and we should not worry about which mec= hanism we should choose to achieve it. Push, fast poll, and notice broadcast (i.e. a single bit sent to all client= s telling them to "phone home" soon) are all reasonable mechanisms to meet = the requirements. Brian On Jan 19, 2012, at 8:40 AM, Peter Stanforth wrote: > I would like to suggest that we back up and ask the question. How do=20 > we pre-empt a device if the primary spectrum user needs it back? The=20 > use case I can think of is public safety, where they don't generally=20 > need the spectrum until there is an emergency. They do not know when=20 > or where that will happen so they would need a mechanism to clear the=20 > spectrum in a specific location quickly. > A push mechanisms only one way to do this. Another, off the top of my=20 > head is to only give channel permissions for time durations less than=20 > the time they need to clear the channels. There may be other options=20 > and there are clearly advantages and disadvantages to all. > Peter S. >=20 > On WedJan/18/12 Wed Jan 18, 11:38 AM, "Basavaraj.Patil@nokia.com" > wrote: >=20 >>=20 >> Hi Joel, >>=20 >> The proposal to include unsolicited Push notifications from the white=20 >> space database to a master device is different from the=20 >> Request/Response mechanism itself. >> A master device making a request for available channels expects a=20 >> response in some time window. Not proposing we change that. >> However the white space database knows of devices which have=20 >> registered with it. And hence can send push notifications at will=20 >> without necessarily having to react to a request. >>=20 >> -Raj >>=20 >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: >>=20 >>> While responses have time windows, as far as I know, requests do not=20 >>> specify when the response will be acted upon, if ever, or for how long. >>>=20 >>> As such, this seems to imply either that we add significantly more=20 >>> information to requests, or that any change in anything that has=20 >>> ever been asked for gets pushed? >>> That does not sound like a good design. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>>=20 >>>> Hi Gabor, >>>>=20 >>>> On 1/12/12 8:26 PM, "ext=20 >>>> Gabor.Bajko@nokia.com" >>>> wrote: >>>>=20 >>>>> P.3 currently says: The protocol between the master device and=20 >>>>> the WS Database MUST support pushing updates in channel=20 >>>>> availability changes to subjects. >>>>> There were comments that this requirement involves a mechanism, we=20 >>>>> should reformulate to be mechanism agnostic. >>>>> There was a suggestion to "make the requirement "quick way to=20 >>>>> change availability" rather than imply a mechanism.". >>>>> The use case is that if the channel availability changes in the=20 >>>>> DB, the client has to be able to detect it and get the new=20 >>>>> availability list within a time period set by the regulator. >>>>> Can someone send suggested text on how to reformulate this=20 >>>>> requirement? >>>>=20 >>>> The requirement to enable Push notifications to be sent to a white=20 >>>> space device which has registered with a database is important=20 >>>> especially in the context of Ofcom requirements (I believe). The=20 >>>> reasons for such push notifications could be for purposes that go=20 >>>> beyond just channel availability updates. A proposal for the=20 >>>> requirement is as follows: >>>>=20 >>>> Requirement: A white space database should be able to send=20 >>>> unsolicited messages to a master device which has registered with=20 >>>> it. The protocol between the WS database and master device MUST=20 >>>> allow for push notifications to be sent from the database to the maste= r device. >>>>=20 >>>> -Raj >>>>=20 >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Jan 19 06:54:25 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5586921F85BB for ; Thu, 19 Jan 2012 06:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVMyHF82XXds for ; Thu, 19 Jan 2012 06:54:24 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A2C1A21F85B7 for ; Thu, 19 Jan 2012 06:54:24 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0JEsJBv004016; Thu, 19 Jan 2012 16:54:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 16:54:21 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.241]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Thu, 19 Jan 2012 15:54:20 +0100 From: To: , , Thread-Topic: Security Requirements (was: next steps for the wg) Thread-Index: AczWtyJUaY6j1dEnR4yVw1+8Jqk/Dg== Date: Thu, 19 Jan 2012 14:54:20 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB481@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.52.73.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 14:54:21.0171 (UTC) FILETIME=[39F7E430:01CCD6BA] X-Nokia-AV: Clean Subject: Re: [paws] Security Requirements (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 14:54:25 -0000 In order to avoid contacting a spoofed database, a client has to check the = identity of it. Assuming we use certs, that means that the client has to be= able to authenticate the db based on its cert (this is currently requireme= nt P.6, P.12), but it may also need to check if that cert is valid, so OCSP= may also be needed (requirement P.13). It seems to me that you would require the above requirements to make sure y= ou avoid talking with a spoofed database, but you may not necessarily requi= re the message exchanges be encrypted; integrity protection may be necessa= ry though, as you want to make sure the answer from db is not modified by a= mitm. If that is the case, then we would keep requirements P.6, P.12, P.13 and re= move integrity protection from requirement P.5 Is my understanding correct? - Gabor -----Original Message----- From: ext Peter Stanforth [mailto:peter@spectrumbridge.com]=20 Sent: Tuesday, January 17, 2012 3:41 PM To: Patil Basavaraj (Nokia-CIC/Dallas); Bajko Gabor (Nokia-CIC/SiliconValle= y); paws@ietf.org Subject: Re: [paws] next steps for the wg This comment is a compound response to the "Security between the database a= nd the white space radio". I have always believed that there is little reason to need to trust the rad= io - after all if it was going to do something malicious or illegal why wou= ld it even contact the database and request a channel list. In addition the= impact of a single rouge radio is fairly limited. However the implications= of a spoofed database that provides "all channels available everywhere" in= response to channel queries could be catastrophic. I am finding it hard = to evaluate this requirement, and the previous requirements in isolation. I= think it would be better to consider the various threat levels and then de= cide how to provide reasonable protection against them in a comprehensive w= ay. On TueJan/17/12 Tue Jan 17, 6:14 PM, "Basavaraj.Patil@nokia.com" wrote: > >Gabor, > >On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >wrote: > >>P.13: A master device MUST be capable of checking the validity of >> the WS Database certificate and whether it has been revoked >> or not. >> >>Note, P.13 requires support for OCSP (RFC2560) in the client, I am not=20 >>sure if that is needed, please send your opinions. >> > > >If certificate based authentication is used by the protocol, then there=20 >would be a need to mandate the above requirement. But at this time we=20 >have no visibility about the authentication protocol to be used between=20 >the master device and the WS database. So it is premature to specify=20 >the above requirement. Hence I would favor dropping this requirement. > >-Raj > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Thu Jan 19 08:03:58 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA1421F8578 for ; Thu, 19 Jan 2012 08:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbO1e3zqJ8V6 for ; Thu, 19 Jan 2012 08:03:57 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA8221F8577 for ; Thu, 19 Jan 2012 08:03:56 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0JG3e1l023817; Thu, 19 Jan 2012 18:03:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 18:03:01 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Thu, 19 Jan 2012 17:03:00 +0100 From: To: , , Thread-Topic: Security Requirements (was: next steps for the wg) Thread-Index: AczWtyJUaY6j1dEnR4yVw1+8Jqk/Dv//pBcA Date: Thu, 19 Jan 2012 16:02:59 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB481@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <5E96E0038953DD44B164651961C9E732@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 16:03:01.0274 (UTC) FILETIME=[D1BDB7A0:01CCD6C3] X-Nokia-AV: Clean Subject: Re: [paws] Security Requirements (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:03:58 -0000 Hi Gabor, Peter's comment : "I think it would be better to consider the various threat levels and then decide how to provide reasonable protection against them in a comprehensive way." makes sense. It is unnecessary to specify requirements such as the need for OCSP in case certificate based authentication is used etc. Rather, lets specify a broader set of security requirements based on the threat model and let the solution(s) decide what would be the best approach for dealing with such security needs. -Raj On 1/19/12 8:54 AM, "Bajko Gabor (Nokia-CIC/SiliconValley)" wrote: >In order to avoid contacting a spoofed database, a client has to check >the identity of it. Assuming we use certs, that means that the client has >to be able to authenticate the db based on its cert (this is currently >requirement P.6, P.12), but it may also need to check if that cert is >valid, so OCSP may also be needed (requirement P.13). > >It seems to me that you would require the above requirements to make sure >you avoid talking with a spoofed database, but you may not necessarily >require the message exchanges be encrypted; integrity protection may be >necessary though, as you want to make sure the answer from db is not >modified by a mitm. > >If that is the case, then we would keep requirements P.6, P.12, P.13 and >remove integrity protection from requirement P.5 > >Is my understanding correct? > >- Gabor > > >-----Original Message----- >From: ext Peter Stanforth [mailto:peter@spectrumbridge.com] >Sent: Tuesday, January 17, 2012 3:41 PM >To: Patil Basavaraj (Nokia-CIC/Dallas); Bajko Gabor >(Nokia-CIC/SiliconValley); paws@ietf.org >Subject: Re: [paws] next steps for the wg > >This comment is a compound response to the "Security between the database >and the white space radio". >I have always believed that there is little reason to need to trust the >radio - after all if it was going to do something malicious or illegal >why would it even contact the database and request a channel list. In >addition the impact of a single rouge radio is fairly limited. However >the implications of a spoofed database that provides "all channels >available everywhere" in response to channel queries could be >catastrophic. I am finding it hard to evaluate this requirement, and >the previous requirements in isolation. I think it would be better to >consider the various threat levels and then decide how to provide >reasonable protection against them in a comprehensive way. > >On TueJan/17/12 Tue Jan 17, 6:14 PM, "Basavaraj.Patil@nokia.com" > wrote: > >> >>Gabor, >> >>On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com" >>wrote: >> >>>P.13: A master device MUST be capable of checking the validity of >>> the WS Database certificate and whether it has been revoked >>> or not. >>> >>>Note, P.13 requires support for OCSP (RFC2560) in the client, I am not >>>sure if that is needed, please send your opinions. >>> >> >> >>If certificate based authentication is used by the protocol, then there >>would be a need to mandate the above requirement. But at this time we >>have no visibility about the authentication protocol to be used between >>the master device and the WS database. So it is premature to specify >>the above requirement. Hence I would favor dropping this requirement. >> >>-Raj >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > From teco@inf-net.nl Thu Jan 19 08:10:51 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D2621F8691 for ; Thu, 19 Jan 2012 08:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-nyPXRoT5y8 for ; Thu, 19 Jan 2012 08:10:50 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 192E721F8675 for ; Thu, 19 Jan 2012 08:10:49 -0800 (PST) Received: by eaai13 with SMTP id i13so42721eaa.31 for ; Thu, 19 Jan 2012 08:10:46 -0800 (PST) Received: by 10.213.32.84 with SMTP id b20mr7160180ebd.139.1326989445879; Thu, 19 Jan 2012 08:10:45 -0800 (PST) Received: from [10.87.35.85] ([80.187.223.13]) by mx.google.com with ESMTPS id u53sm115015661eeu.6.2012.01.19.08.10.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Jan 2012 08:10:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB433@008-AM1MPN1-006.mgdnok.nokia.com> Date: Thu, 19 Jan 2012 17:10:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4106C7CF-4793-442C-907A-BF87696FBDB8@inf-net.nl> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB433@008-AM1MPN1-006.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] P.3 Requirement (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:10:51 -0000 Op 19 jan. 2012, om 15:25 heeft het volgende = geschreven: > We have a related use case in the document: >=20 > 4.7. Rapid deployed network for emergency scenario >=20 > Organizations involved in handling emergency operations often have a > fully owned and controlled infrastructure, with dedicated spectrum, > for day to day operation. However, lessons learned from recent > disasters show such infrastructures are often highly affected by the > disaster itself. To set up a replacement quickly, there is a need > for fast reallocation of spectrum, where in certain cases spectrum > can be freed for disaster relief. To utilize free or freed spectrum > quickly and reliable, automation of allocation, assignment and > configuration is needed. A preferred option is make use of a robust > protocol, already adopted by radio manufacturers. This approach = does > in no way imply such organizations for disaster relief must compete > on spectrum allocation with other white spaces users, but they can. > A typical network topology would include wireless access links to = the > public Internet or private network, wireless ad hoc network radios > working independent of a fixed infrastructure and satellite links = for > backup where lack of coverage, overload or outage of wireless access > links occur. >=20 > So it seems we'll need a requirement to free spectrum on a short = notice. =46rom the above use case my reading is that 'short' is close to = instantaneous. Related to timescales for current frequency allocation (in years), yes, = it is instantaneous. I recommend we leave out-of-scope how & why = spectrum is reallocated. A question is: if spectrum is freed, how to = inform PAWS master nodes, to get it. In this use case, there is a = dedicated channel and applications would make use of it to receive = triggers. Triggers could be SNMP. Maybe we work on MIBs some day, and = simply define a trigger.=20 Teco >=20 > - Gabor >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Rosen, Brian > Sent: Thursday, January 19, 2012 6:09 AM > To: Peter Stanforth > Cc: paws@ietf.org > Subject: Re: [paws] next steps for the wg >=20 > At this stage, we should say that we have a requirement to change = availability of spectrum on a short notice, we need a use case that = would motivate some decision on what "short" means, and we should not = worry about which mechanism we should choose to achieve it. >=20 > Push, fast poll, and notice broadcast (i.e. a single bit sent to all = clients telling them to "phone home" soon) are all reasonable mechanisms = to meet the requirements. >=20 > Brian >=20 > On Jan 19, 2012, at 8:40 AM, Peter Stanforth wrote: >=20 >> I would like to suggest that we back up and ask the question. How do=20= >> we pre-empt a device if the primary spectrum user needs it back? The=20= >> use case I can think of is public safety, where they don't generally=20= >> need the spectrum until there is an emergency. They do not know when=20= >> or where that will happen so they would need a mechanism to clear the=20= >> spectrum in a specific location quickly. >> A push mechanisms only one way to do this. Another, off the top of my=20= >> head is to only give channel permissions for time durations less than=20= >> the time they need to clear the channels. There may be other options=20= >> and there are clearly advantages and disadvantages to all. >> Peter S. >>=20 >> On WedJan/18/12 Wed Jan 18, 11:38 AM, "Basavaraj.Patil@nokia.com" >> wrote: >>=20 >>>=20 >>> Hi Joel, >>>=20 >>> The proposal to include unsolicited Push notifications from the = white=20 >>> space database to a master device is different from the=20 >>> Request/Response mechanism itself. >>> A master device making a request for available channels expects a=20 >>> response in some time window. Not proposing we change that. >>> However the white space database knows of devices which have=20 >>> registered with it. And hence can send push notifications at will=20 >>> without necessarily having to react to a request. >>>=20 >>> -Raj >>>=20 >>> On 1/17/12 8:03 PM, "ext Joel M. Halpern" = wrote: >>>=20 >>>> While responses have time windows, as far as I know, requests do = not=20 >>>> specify when the response will be acted upon, if ever, or for how = long. >>>>=20 >>>> As such, this seems to imply either that we add significantly more=20= >>>> information to requests, or that any change in anything that has=20 >>>> ever been asked for gets pushed? >>>> That does not sound like a good design. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: >>>>>=20 >>>>> Hi Gabor, >>>>>=20 >>>>> On 1/12/12 8:26 PM, "ext=20 >>>>> Gabor.Bajko@nokia.com" >>>>> wrote: >>>>>=20 >>>>>> P.3 currently says: The protocol between the master device and=20= >>>>>> the WS Database MUST support pushing updates in channel=20 >>>>>> availability changes to subjects. >>>>>> There were comments that this requirement involves a mechanism, = we=20 >>>>>> should reformulate to be mechanism agnostic. >>>>>> There was a suggestion to "make the requirement "quick way to=20 >>>>>> change availability" rather than imply a mechanism.". >>>>>> The use case is that if the channel availability changes in the=20= >>>>>> DB, the client has to be able to detect it and get the new=20 >>>>>> availability list within a time period set by the regulator. >>>>>> Can someone send suggested text on how to reformulate this=20 >>>>>> requirement? >>>>>=20 >>>>> The requirement to enable Push notifications to be sent to a white=20= >>>>> space device which has registered with a database is important=20 >>>>> especially in the context of Ofcom requirements (I believe). The=20= >>>>> reasons for such push notifications could be for purposes that go=20= >>>>> beyond just channel availability updates. A proposal for the=20 >>>>> requirement is as follows: >>>>>=20 >>>>> Requirement: A white space database should be able to send=20 >>>>> unsolicited messages to a master device which has registered with=20= >>>>> it. The protocol between the WS database and master device MUST=20 >>>>> allow for push notifications to be sent from the database to the = master device. >>>>>=20 >>>>> -Raj >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From jmh@joelhalpern.com Thu Jan 19 09:12:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596EF21F852B for ; Thu, 19 Jan 2012 09:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrUzAkd12hj8 for ; Thu, 19 Jan 2012 09:12:36 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id EE4F821F851C for ; Thu, 19 Jan 2012 09:12:35 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id A8517CD0E5 for ; Thu, 19 Jan 2012 09:12:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6C2B561D34; Thu, 19 Jan 2012 09:12:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.154.181.175] (unknown [129.192.185.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9E92D61C87; Thu, 19 Jan 2012 09:12:34 -0800 (PST) Message-ID: <4F184EFB.5080108@joelhalpern.com> Date: Thu, 19 Jan 2012 12:12:27 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:12:36 -0000 Thanks Brian. That works much better for me. Yours, Joel On 1/19/2012 9:08 AM, Rosen, Brian wrote: > At this stage, we should say that we have a requirement to change availability of spectrum on a short notice, we need a use case that would motivate some decision on what "short" means, and we should not worry about which mechanism we should choose to achieve it. > > Push, fast poll, and notice broadcast (i.e. a single bit sent to all clients telling them to "phone home" soon) are all reasonable mechanisms to meet the requirements. > > Brian > From budden@nps.edu Thu Jan 19 11:27:29 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6C521F85A3 for ; Thu, 19 Jan 2012 11:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQlAzPPia9Gy for ; Thu, 19 Jan 2012 11:27:28 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id C39C321F858E for ; Thu, 19 Jan 2012 11:27:28 -0800 (PST) X-ASG-Debug-ID: 1327001248-036c920f2071940001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id 4qbPiLtHT9GMY18X; Thu, 19 Jan 2012 11:27:28 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 19 Jan 2012 11:27:27 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] P.3 Requirement (was: next steps for the wg) To: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB433@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DAB433@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 19 Jan 2012 11:26:52 -0800 Message-ID: <1327001212.9169.1078.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1327001248 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.86359 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org Subject: Re: [paws] P.3 Requirement (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 19:27:30 -0000 I think you've disposed of the issue adequately. The use case covers. But ... the kind of disaster that requires emergency services to need more spectrum fall into two categories: - forecast events like heavy weather. We have hours-days of reaction time. - unforecastable events like earthquakes or airplanes flying into buildings. Here the reaction time window is in minutes. Out of PAWS-scope comments. Capacity is usually not the critical commodity for emergency services. The two most important issues are - availability and survivability. (Whether or not the comms is internet comms or not). If the comms is internet comms (labeled 'broadband' over in the emergency services discussions), then breakage of terrestrial-WAN trunks will force traffic into the radio-WANs. In unforecast events, this traffic shift will happen very quickly (routers responding to outages by pushing traffic to surviving, but higher-cost routes). - geographic coverage. Specific to the radio-WAN part of the problem ... and indirectly intersecting the PAWS issues. I don't believe many emergency services comms folks see this one coming, but most of the radio-WAN technologies and rulesets will result in smaller footprints (eleven high sites for all of Monterey County is an order of magnitude too few). This will meet the continued proliferation of the terrestrial internet (which at least in urban/suburban areas of US) has the necessary frequency of POPs. On Thu, 2012-01-19 at 14:25 +0000, Gabor.Bajko@nokia.com wrote: > We have a related use case in the document: > > 4.7. Rapid deployed network for emergency scenario > > Organizations involved in handling emergency operations often have a > fully owned and controlled infrastructure, with dedicated spectrum, > for day to day operation. However, lessons learned from recent > disasters show such infrastructures are often highly affected by the > disaster itself. To set up a replacement quickly, there is a need > for fast reallocation of spectrum, where in certain cases spectrum > can be freed for disaster relief. To utilize free or freed spectrum > quickly and reliable, automation of allocation, assignment and > configuration is needed. A preferred option is make use of a robust > protocol, already adopted by radio manufacturers. This approach does > in no way imply such organizations for disaster relief must compete > on spectrum allocation with other white spaces users, but they can. > A typical network topology would include wireless access links to the > public Internet or private network, wireless ad hoc network radios > working independent of a fixed infrastructure and satellite links for > backup where lack of coverage, overload or outage of wireless access > links occur. > > So it seems we'll need a requirement to free spectrum on a short notice. From the above use case my reading is that 'short' is close to instantaneous. > > - Gabor > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Rosen, Brian > Sent: Thursday, January 19, 2012 6:09 AM > To: Peter Stanforth > Cc: paws@ietf.org > Subject: Re: [paws] next steps for the wg > > At this stage, we should say that we have a requirement to change availability of spectrum on a short notice, we need a use case that would motivate some decision on what "short" means, and we should not worry about which mechanism we should choose to achieve it. > > Push, fast poll, and notice broadcast (i.e. a single bit sent to all clients telling them to "phone home" soon) are all reasonable mechanisms to meet the requirements. > > Brian > > On Jan 19, 2012, at 8:40 AM, Peter Stanforth wrote: > > > I would like to suggest that we back up and ask the question. How do > > we pre-empt a device if the primary spectrum user needs it back? The > > use case I can think of is public safety, where they don't generally > > need the spectrum until there is an emergency. They do not know when > > or where that will happen so they would need a mechanism to clear the > > spectrum in a specific location quickly. > > A push mechanisms only one way to do this. Another, off the top of my > > head is to only give channel permissions for time durations less than > > the time they need to clear the channels. There may be other options > > and there are clearly advantages and disadvantages to all. > > Peter S. > > > > On WedJan/18/12 Wed Jan 18, 11:38 AM, "Basavaraj.Patil@nokia.com" > > wrote: > > > >> > >> Hi Joel, > >> > >> The proposal to include unsolicited Push notifications from the white > >> space database to a master device is different from the > >> Request/Response mechanism itself. > >> A master device making a request for available channels expects a > >> response in some time window. Not proposing we change that. > >> However the white space database knows of devices which have > >> registered with it. And hence can send push notifications at will > >> without necessarily having to react to a request. > >> > >> -Raj > >> > >> On 1/17/12 8:03 PM, "ext Joel M. Halpern" wrote: > >> > >>> While responses have time windows, as far as I know, requests do not > >>> specify when the response will be acted upon, if ever, or for how long. > >>> > >>> As such, this seems to imply either that we add significantly more > >>> information to requests, or that any change in anything that has > >>> ever been asked for gets pushed? > >>> That does not sound like a good design. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 1/17/2012 6:08 PM, Basavaraj.Patil@nokia.com wrote: > >>>> > >>>> Hi Gabor, > >>>> > >>>> On 1/12/12 8:26 PM, "ext > >>>> Gabor.Bajko@nokia.com" > >>>> wrote: > >>>> > >>>>> P.3 currently says: The protocol between the master device and > >>>>> the WS Database MUST support pushing updates in channel > >>>>> availability changes to subjects. > >>>>> There were comments that this requirement involves a mechanism, we > >>>>> should reformulate to be mechanism agnostic. > >>>>> There was a suggestion to "make the requirement "quick way to > >>>>> change availability" rather than imply a mechanism.". > >>>>> The use case is that if the channel availability changes in the > >>>>> DB, the client has to be able to detect it and get the new > >>>>> availability list within a time period set by the regulator. > >>>>> Can someone send suggested text on how to reformulate this > >>>>> requirement? > >>>> > >>>> The requirement to enable Push notifications to be sent to a white > >>>> space device which has registered with a database is important > >>>> especially in the context of Ofcom requirements (I believe). The > >>>> reasons for such push notifications could be for purposes that go > >>>> beyond just channel availability updates. A proposal for the > >>>> requirement is as follows: > >>>> > >>>> Requirement: A white space database should be able to send > >>>> unsolicited messages to a master device which has registered with > >>>> it. The protocol between the WS database and master device MUST > >>>> allow for push notifications to be sent from the database to the master device. > >>>> > >>>> -Raj > >>>> > >>>> _______________________________________________ > >>>> paws mailing list > >>>> paws@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/paws > >>>> > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Thu Jan 19 11:42:06 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC821F85AC for ; Thu, 19 Jan 2012 11:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR5aiLePMVTX for ; Thu, 19 Jan 2012 11:42:05 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 33CA621F85A4 for ; Thu, 19 Jan 2012 11:41:57 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0JJfunK001252 for ; Thu, 19 Jan 2012 21:41:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 21:41:56 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.241]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Thu, 19 Jan 2012 20:41:56 +0100 From: To: Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAA4qMoAAAD6pAAABmtzgAAGf7GA Date: Thu, 19 Jan 2012 19:41:55 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B0FD6771A@008-AM1MPN1-025.mgdnok.nokia.com> References: <4F184EFB.5080108@joelhalpern.com> In-Reply-To: <4F184EFB.5080108@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ii5ixigbgnw/+pHiMK9XYPrp+wpI/Iyw63nXNMm+aPWNZ1voDlBNifqNDVBFLrrEcDDOLQ68t4Jm2RPnz+FKDjHrcAV0vQmofL8KJdd9pKTOhnHa7D3YSUGxBPmwqOhM/AXw8SOcKEaOU9uw1WZfwD3g9R+QXvaqbwpc8IgOelclbEzwXRXnsmXN3fXxZphhNHDXfnPJkqG8ONFEuR0btTQPu+ixxH2cR45LBhrg/feO x-headerinfofordlp: None x-originating-ip: [10.241.160.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 19:41:56.0715 (UTC) FILETIME=[6712F3B0:01CCD6E2] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 19:42:06 -0000 Hi All, I believe it is relevant to look at Ofcom's Implementing Geolocation Summar= y of consultation responses and next steps. Paragraph 3.42 states: > >Ofcom retains control over the performance of the algorithms used in the >databases and will update them if required to manage interference. A kill >switch is a useful reactive tool and we believe that it should form a core >part of the protocol which describes the information exchange between >WSDs and the database. > Following the notion that a kill switch should form a core part of the prot= ocol, this could be included in a very basic use case like "Hotspot: urban = internet connectivity service". I can volunteer to make this addition in th= e use case. Regarding the requirement we could say the database must be able to deliver= updated channel information to any registered master device. We have not s= pecified elsewhere any time constraints on message delivery, I wonder if th= is is needed in this case either. Kind Regards, Scott -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Joel M. Halpern Sent: Thursday, January 19, 2012 11:12 AM To: Rosen, Brian Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg Thanks Brian. That works much better for me. Yours, Joel On 1/19/2012 9:08 AM, Rosen, Brian wrote: > At this stage, we should say that we have a requirement to change availab= ility of spectrum on a short notice, we need a use case that would motivate= some decision on what "short" means, and we should not worry about which m= echanism we should choose to achieve it. > > Push, fast poll, and notice broadcast (i.e. a single bit sent to all clie= nts telling them to "phone home" soon) are all reasonable mechanisms to mee= t the requirements. > > Brian > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Thu Jan 19 13:57:29 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7F521F86C5 for ; Thu, 19 Jan 2012 13:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isgYabwuVZaC for ; Thu, 19 Jan 2012 13:57:29 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id AD96321F8619 for ; Thu, 19 Jan 2012 13:57:28 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0JLvOTJ027317; Thu, 19 Jan 2012 23:57:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 23:57:23 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.241]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 19 Jan 2012 22:57:23 +0100 From: To: , , , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADrT+sAAAzYPYD//51gAIAAaHKA//+hogD//mVE4P/68QDQ Date: Thu, 19 Jan 2012 21:57:22 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B0FD67931@008-AM1MPN1-025.mgdnok.nokia.com> References: <619CDADDCCD2B44380834BE8BF6F7141405FFC0584@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141405FFC0584@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7Ii5ixigbgnw/+pHiMK9XYPrp+wpI/Iyw63nXNMm+aPWNZ1voDlBNifqNDVBFLrrEcDDOLQ68t4Jm2RPnz+FKDjHrcAV0vQmofL8KJdd9pKTOhnHa7D3YSUGxBPmwqOhM/AXw8SOcKEaOU9uw1WZfwD3g9R+QXvaqbwpc8IgOelclbEzwXRXnsmXN3fXxZphhNHDXfnPJkqG8ONFEuR0btTQPu+ixxH2cR45LBhrg/feO x-headerinfofordlp: None x-originating-ip: [10.241.160.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 21:57:23.0992 (UTC) FILETIME=[534F0180:01CCD6F5] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 21:57:29 -0000 Hi, Section 4.7 Rapid deployed network for emergency scenario also includes the= proxy concept. Would be good if Andy, Mike & Juan Carlos could consider th= at one also. Section 4.8 Mobility is very similar to the train or ferry concepts. Perhap= s Peter could improve that use case. Kind Regards, Scott -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= andy.sago@bt.com Sent: Wednesday, January 18, 2012 11:45 AM To: Patil Basavaraj (Nokia-CIC/Dallas); peter@spectrumbridge.com; paws@ietf= .org Subject: Re: [paws] next steps for the wg I agree the proxy master concept should be documented. Mike Fitch, Juan Car= los Zuniga and I are drafting an expansion of the M2M use case (as requeste= d at the last F2F) which already alludes to the proxy concept. Including it= in the M2M use case may be sufficient to draw out the requirements. We wil= l post the use case update this week on the reflector. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bas= avaraj.Patil@nokia.com Sent: 18 January 2012 00:09 To: peter@spectrumbridge.com; paws@ietf.org Subject: Re: [paws] next steps for the wg Thanks.=20 I think the use-case would be useful to document in the I-D. It provides th= e proxy model use case for consideration. Rgds, -Raj On 1/17/12 5:46 PM, "ext Peter Stanforth" wrote: >Raj >I will look at the existing use cases again and either propose an=20 >update or a new one. Two specific use cases. >One is an "AP" on a train or ferry serving white Space clients with a=20 >non white space backhaul. This I believe is your mobile master. >The simplest scenario I can give is for a multi master solution - say a=20 >collection of construction or farm equipment In the US today these=20 >would all be classified as High Power and would have to individually=20 >request channels however this is very inefficient and allowing some=20 >master to proxy within a predefined area would be preferable. >Regards, >Peter S. > >On TueJan/17/12 Tue Jan 17, 6:32 PM, "Basavaraj.Patil@nokia.com" > wrote: > >> >>Hi Peter, >> >>I concur with your comment. Just a quick clarification question about=20 >>the scenario wherein the mobile master is supporting devices that=20 >>either roam within a polygon or cannot accurately locate themselves.. >>First of all I am not sure I understand what these other devices are=20 >>that are relying on the master. Maybe a more complete use case=20 >>description would help. >>We do not have such a scenario in the current document and could=20 >>consider it. >> >>-Raj >> >>On 1/17/12 5:25 PM, "ext Peter Stanforth" >>wrote: >> >>>I would like to see this be described in a more generic way. I agree=20 >>>with Raj that this is all about providing information for more than a=20 >>>point on a map but there are several possible scenarios for which a=20 >>>query for a "polygon" could be requested. It could be a very long=20 >>>thin polygon if the request is related to a road or railroad or a=20 >>>fairly square polygon if the request is for a venue or even a field. >>>While the use case may be a mobile master it could also be for a=20 >>>master that is supporting devices that either roam within the polygon=20 >>>or cannot accurately locate themselves within the polygon. >>> >>>On TueJan/17/12 Tue Jan 17, 6:17 PM, "Basavaraj.Patil@nokia.com" >>> wrote: >>> >>>> >>>>Hi Gabor, >>>> >>>>On 1/12/12 8:26 PM, "ext Gabor.Bajko@nokia.com"=20 >>>> >>>>wrote: >>>> >>>>>We did not have any discussion on P.9, so I'd like to get comments=20 >>>>>on the list about this: >>>>> P.9: A master device MUST be able to query the whitespace >>>>> database for channel availability information for a >>>>> specific expected coverage area around its current >>>>> location. >>>> >>>>This requirement addresses the need associated with a white space=20 >>>>master device which is mobile. >>>>The master device may query channel availability for a specific=20 >>>>contour or a set of locations on a certain path for example. >>>>Hence this requirement is primarily about allowing the query to=20 >>>>contain information that goes beyond just a specific lat/long co-ordina= te. >>>> >>>>-Raj >>>> >>>>_______________________________________________ >>>>paws mailing list >>>>paws@ietf.org >>>>https://www.ietf.org/mailman/listinfo/paws >>> >> > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Thu Jan 19 16:33:28 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D34E21F86DF for ; Thu, 19 Jan 2012 16:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIAey6Voj4W7 for ; Thu, 19 Jan 2012 16:33:28 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id B389E21F86D9 for ; Thu, 19 Jan 2012 16:33:27 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jan 2012 00:33:25 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.215]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 20 Jan 2012 00:33:25 +0000 From: To: , Date: Fri, 20 Jan 2012 00:33:23 +0000 Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAA4qMoAAAD6pAAABmtzgAAGf7GAAAqhM+A= Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406003E11E@EMV62-UKRD.domain1.systemhost.net> References: <4F184EFB.5080108@joelhalpern.com> <88BE24FD9280884487DEAE0CE1FD3A5B0FD6771A@008-AM1MPN1-025.mgdnok.nokia.com> In-Reply-To: <88BE24FD9280884487DEAE0CE1FD3A5B0FD6771A@008-AM1MPN1-025.mgdnok.nokia.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 00:33:28 -0000 Scott Regarding time constraints for message delivery from the database, Ofcom ha= s moved away from specifying a time limit for a database to respond to a re= quest, on the basis that if it is a first request then the master will not = transmit if it fails to receive a response, and if it is a 'revalidation' r= equest and the master receives no response, the master will cease transmitt= ing anyway when the time validity timer expires. I think in principle we ne= ed not specify a time limit for delivery of pushed information; if received= , the master must act on it, but if not received, it will continue to trans= mit until its validity timer expires. I think that is reasonable. In practi= ce the risk of non-delivery is tiny, as is the likelihood of invoking the k= ill switch in the first place as a method of solving interference issues (e= ven in an emergency).=20 Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 19 January 2012 19:42 To: paws@ietf.org Subject: Re: [paws] next steps for the wg Hi All, I believe it is relevant to look at Ofcom's Implementing Geolocation Summar= y of consultation responses and next steps. Paragraph 3.42 states: > >Ofcom retains control over the performance of the algorithms used in=20 >the databases and will update them if required to manage interference.=20 >A kill switch is a useful reactive tool and we believe that it should=20 >form a core part of the protocol which describes the information=20 >exchange between WSDs and the database. > Following the notion that a kill switch should form a core part of the prot= ocol, this could be included in a very basic use case like "Hotspot: urban = internet connectivity service". I can volunteer to make this addition in th= e use case. Regarding the requirement we could say the database must be able to deliver= updated channel information to any registered master device. We have not s= pecified elsewhere any time constraints on message delivery, I wonder if th= is is needed in this case either. Kind Regards, Scott -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Joel M. Halpern Sent: Thursday, January 19, 2012 11:12 AM To: Rosen, Brian Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg Thanks Brian. That works much better for me. Yours, Joel On 1/19/2012 9:08 AM, Rosen, Brian wrote: > At this stage, we should say that we have a requirement to change availab= ility of spectrum on a short notice, we need a use case that would motivate= some decision on what "short" means, and we should not worry about which m= echanism we should choose to achieve it. > > Push, fast poll, and notice broadcast (i.e. a single bit sent to all clie= nts telling them to "phone home" soon) are all reasonable mechanisms to mee= t the requirements. > > Brian > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Thu Jan 19 19:24:15 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07D21F859E for ; Thu, 19 Jan 2012 19:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYkr6CAkcmxU for ; Thu, 19 Jan 2012 19:24:14 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id C16B021F85A3 for ; Thu, 19 Jan 2012 19:24:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lk0cbJvCgB8t3rbwYrjrYDy76LGa0Z/xNwOZD1CLXnOI8Fv5yENqKtB5fKqeZ7Gi; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Ro55E-0002rN-GP; Thu, 19 Jan 2012 22:24:08 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406003E11E@EMV62-UKRD.domain1.systemhost.net> Date: Thu, 19 Jan 2012 19:24:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7F45832C-ECE8-4084-9E19-819A615E535D@earthlink.net> References: <4F184EFB.5080108@joelhalpern.com> <88BE24FD9280884487DEAE0CE1FD3A5B0FD6771A@008-AM1MPN1-025.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F7141406003E11E@EMV62-UKRD.domain1.systemhost.net> To: Andy Sago X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad861bbcd86ad7fb3fedd52b99a29cfddc3c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 03:24:15 -0000 Dear Andy,=20 In that you are looking at this from the Ofcom aspect, and many other = countries are or will be implementing such controls as a "kill switch", = it may be useful to see if from an agnostic technology point of view, just how valuable = this is by use case. Certainly there are other precautions in the UK for many situations that are handled day to day, but is that = the same in most countries and what their regulations require. Isn't it = safer to have this in the protocol than not? I am not an expert but I do think = there are several scenarios that can call for a kill switch besides = interference, intentional or not or emergencies natural or not. Just my personal opinion. Sincerely, Nancy On Jan 19, 2012, at 4:33 PM, = wrote: > Scott >=20 > Regarding time constraints for message delivery from the database, = Ofcom has moved away from specifying a time limit for a database to = respond to a request, on the basis that if it is a first request then = the master will not transmit if it fails to receive a response, and if = it is a 'revalidation' request and the master receives no response, the = master will cease transmitting anyway when the time validity timer = expires. I think in principle we need not specify a time limit for = delivery of pushed information; if received, the master must act on it, = but if not received, it will continue to transmit until its validity = timer expires. I think that is reasonable. In practice the risk of = non-delivery is tiny, as is the likelihood of invoking the kill switch = in the first place as a method of solving interference issues (even in = an emergency).=20 >=20 > Regards >=20 > Andy >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com > Sent: 19 January 2012 19:42 > To: paws@ietf.org > Subject: Re: [paws] next steps for the wg >=20 > Hi All, >=20 > I believe it is relevant to look at Ofcom's Implementing Geolocation = Summary of consultation responses and next steps. Paragraph 3.42 states: >=20 >>=20 >> Ofcom retains control over the performance of the algorithms used in=20= >> the databases and will update them if required to manage = interference.=20 >> A kill switch is a useful reactive tool and we believe that it should=20= >> form a core part of the protocol which describes the information=20 >> exchange between WSDs and the database. >>=20 >=20 > Following the notion that a kill switch should form a core part of the = protocol, this could be included in a very basic use case like "Hotspot: = urban internet connectivity service". I can volunteer to make this = addition in the use case. >=20 > Regarding the requirement we could say the database must be able to = deliver updated channel information to any registered master device. We = have not specified elsewhere any time constraints on message delivery, I = wonder if this is needed in this case either. >=20 > Kind Regards, > Scott >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Joel M. Halpern > Sent: Thursday, January 19, 2012 11:12 AM > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] next steps for the wg >=20 > Thanks Brian. That works much better for me. > Yours, > Joel >=20 > On 1/19/2012 9:08 AM, Rosen, Brian wrote: >> At this stage, we should say that we have a requirement to change = availability of spectrum on a short notice, we need a use case that = would motivate some decision on what "short" means, and we should not = worry about which mechanism we should choose to achieve it. >>=20 >> Push, fast poll, and notice broadcast (i.e. a single bit sent to all = clients telling them to "phone home" soon) are all reasonable mechanisms = to meet the requirements. >>=20 >> Brian >>=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Fri Jan 20 02:29:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717C421F8628 for ; Fri, 20 Jan 2012 02:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiwTj+DeL5wn for ; Fri, 20 Jan 2012 02:29:32 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E9E5E21F83EF for ; Fri, 20 Jan 2012 02:29:31 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jan 2012 10:29:29 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.215]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Fri, 20 Jan 2012 10:29:29 +0000 From: To: Date: Fri, 20 Jan 2012 10:29:29 +0000 Thread-Topic: [paws] next steps for the wg Thread-Index: AczXIvxFn16rCd9USseRxBR9c6pKWAAOruBQ Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406003E371@EMV62-UKRD.domain1.systemhost.net> References: <4F184EFB.5080108@joelhalpern.com> <88BE24FD9280884487DEAE0CE1FD3A5B0FD6771A@008-AM1MPN1-025.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F7141406003E11E@EMV62-UKRD.domain1.systemhost.net> <7F45832C-ECE8-4084-9E19-819A615E535D@earthlink.net> In-Reply-To: <7F45832C-ECE8-4084-9E19-819A615E535D@earthlink.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 10:29:36 -0000 Nancy Thanks for your views, I am in favour of PAWS developing a protocol for a k= ill switch and will be happy to review Scott's proposed text for this (sub)= use case when it is posted. The protocol will need to cover the anticipate= d regulatory requirements across different countries. Regards Andy -----Original Message----- From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 Sent: 20 January 2012 03:24 To: Sago,AJ,Andy,COD R Cc: scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] next steps for the wg Dear Andy, In that you are looking at this from the Ofcom aspect, and many other count= ries are or will be implementing such controls as a "kill switch", it may b= e useful to see if from an agnostic technology point of view, just how valu= able this is by use case. Certainly there are other precautions in the UK f= or many situations that are handled day to day, but is that the same in mos= t countries and what their regulations require. Isn't it safer to have this= in the protocol than not? I am not an expert but I do think there are seve= ral scenarios that can call for a kill switch besides interference, intent= ional or not or emergencies natural or not. Just my personal opinion. Sincerely, Nancy On Jan 19, 2012, at 4:33 PM, wrote: > Scott >=20 > Regarding time constraints for message delivery from the database, Ofcom = has moved away from specifying a time limit for a database to respond to a = request, on the basis that if it is a first request then the master will no= t transmit if it fails to receive a response, and if it is a 'revalidation'= request and the master receives no response, the master will cease transmi= tting anyway when the time validity timer expires. I think in principle we = need not specify a time limit for delivery of pushed information; if receiv= ed, the master must act on it, but if not received, it will continue to tra= nsmit until its validity timer expires. I think that is reasonable. In prac= tice the risk of non-delivery is tiny, as is the likelihood of invoking the= kill switch in the first place as a method of solving interference issues = (even in an emergency).=20 >=20 > Regards >=20 > Andy >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of scott.probasco@nokia.com > Sent: 19 January 2012 19:42 > To: paws@ietf.org > Subject: Re: [paws] next steps for the wg >=20 > Hi All, >=20 > I believe it is relevant to look at Ofcom's Implementing Geolocation Summ= ary of consultation responses and next steps. Paragraph 3.42 states: >=20 >>=20 >> Ofcom retains control over the performance of the algorithms used in=20 >> the databases and will update them if required to manage interference. >> A kill switch is a useful reactive tool and we believe that it should=20 >> form a core part of the protocol which describes the information=20 >> exchange between WSDs and the database. >>=20 >=20 > Following the notion that a kill switch should form a core part of the pr= otocol, this could be included in a very basic use case like "Hotspot: urba= n internet connectivity service". I can volunteer to make this addition in = the use case. >=20 > Regarding the requirement we could say the database must be able to deliv= er updated channel information to any registered master device. We have not= specified elsewhere any time constraints on message delivery, I wonder if = this is needed in this case either. >=20 > Kind Regards, > Scott >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Joel M. Halpern > Sent: Thursday, January 19, 2012 11:12 AM > To: Rosen, Brian > Cc: paws@ietf.org > Subject: Re: [paws] next steps for the wg >=20 > Thanks Brian. That works much better for me. > Yours, > Joel >=20 > On 1/19/2012 9:08 AM, Rosen, Brian wrote: >> At this stage, we should say that we have a requirement to change availa= bility of spectrum on a short notice, we need a use case that would motivat= e some decision on what "short" means, and we should not worry about which = mechanism we should choose to achieve it. >>=20 >> Push, fast poll, and notice broadcast (i.e. a single bit sent to all cli= ents telling them to "phone home" soon) are all reasonable mechanisms to me= et the requirements. >>=20 >> Brian >>=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Fri Jan 20 06:01:58 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB1021F84C4 for ; Fri, 20 Jan 2012 06:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.024 X-Spam-Level: X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeKgaRQnrXNb for ; Fri, 20 Jan 2012 06:01:55 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id A4CB521F84E1 for ; Fri, 20 Jan 2012 06:01:41 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jan 2012 14:01:33 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.215]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Fri, 20 Jan 2012 14:01:33 +0000 From: To: Date: Fri, 20 Jan 2012 14:01:32 +0000 Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCw== Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406003E665@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/related; boundary="_004_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:01:58 -0000 --_004_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_ Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_" --_000_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The "Note" on= the slide now has two bullets and reads: * Note: Further signalling can take place (outside the scope of PAW= S) to establish direct links among those slave devices that have associated= with the master device. * Machine communication over a TVWS channel, whether to a master de= vice or to another machine (slave device), is under the control of the mast= er device, and would cease if so requested by the master, or if connection = to the master is lost I have also copied the revised slide here: [cid:image001.png@01CCD76C.DFFAFEF0] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description - I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy --_000_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

<= p class=3DMsoNormal> 

There was a request for cl= arification on the M2M use case presented at the Taipei F2F, in particular = with regard to slave-to-slave communication. Juan Carlos Zuniga, Mike Fitch= and myself have agreed a couple of changes to the M2M slide to make this c= learer. We have added two arrows so that it is clear that each of the slave= s is in communication over TVWS with the master, as well as the slaves bein= g in communication with each other. The “Note” on the slide now= has two bullets and reads:

 

·         <= /span>Note: Further signalling can take place (outside the sc= ope of PAWS) to establish direct links among those slave devices that have = associated with the master device.

· &= nbsp;       Machine comm= unication over a TVWS channel, whether to a master device or to another mac= hine (slave device), is under the control of the master device, and would c= ease if so requested by the master, or if connection to the master is lost<= o:p>

 

I ha= ve also copied the revised slide here:

 

=

 

The sequence of events is= as follows (note that steps 1-5 are the same as in the use case descriptio= n in the current working group draft, but we have removed the last sentence= in step 6 (previously the final step) so that this can be expanded in the = new step 7):

 

   1.  The m= aster device powers up with its whitespace radio in idle or

   &= nbsp;   listen mode only (no active transmission on the whitespac= e

&n= bsp;      frequency band).

 

 =

   2. = The master device has internet connectivity and establishes a

  &nbs= p;    connection to a trusted white space database (see Section 3.1

       ab= ove).

   3.  The master device sends its geolocation and loca= tion uncertainty

       information, and optional= ly additional information which may

       includ= e (1) device ID and (2) antenna characteristics, to a

=

    &= nbsp;  trusted database, requesting a list of available whitespace

<= span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New"'> &= nbsp;     channels based upon this information.

 =

 &n= bsp; 4.  The database responds with a list of available white space

=  =       channels that the master device may use, and= optional information

       which may include in= ter alia (1) a duration of time for the use

     &nb= sp; of each channel (channel validity time) (2) a maximum radiated

  =      power for each channel, (3) an indication of the q= uality of the

       spectrum for each channel an= d (4) directivity and other antenna

       inform= ation.

   5.  Once the master device authenticates the whites= pace channel list

       response message from th= e database, the master device selects one

       = or more available whitespace channels from the list.

<= p class=3DMsoNormal style=3D'page-break-before:always'> 

   6.  T= he slave devices fitted to the machines scan the TV bands to

  &nbs= p;    locate the master transmissions, and associate with th= e master

       device.  <= /p>

 

   7.&nbs= p; Further signaling can take place outside scope of PAWS=

   &nb= sp;   to establish direct links among those slave devices that ha= ve

&= nbsp;      associated with the same master device.= At all times these direct

       links are= under the control of the master device. For example,

    =    common to all use cases, there may be a regulatory requir= ement

       = requested by the master, or if connection to the master is lost =

  &n= bsp;    for more than a specified period of time. When = one of these

       conditions occurs, tran= smissions from slave to slave would also

      &= nbsp;cease. Direct slave to slave transmissions could only restart if =

 &n= bsp;     each slave subsequently restores its conn= ection to the same

       master, or each s= lave joins the network of another master.

 

- end of event sequence de= scription –

 =

I hope this is now clearer. Please let me have any further q= ueries on the reflector.

 <= /span>

To deflect one set of questions before they start, ple= ase note that we have removed any inference in this use case that slaves ma= y talk directly with other slaves when one or other of them is out of range= of the master (i.e. a type of relay or proxy function). This is not a requ= irement that is particular to M2M, and will be dealt with in a separate thread.

 

Regards

 

Andy

 

<= div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4= .0pt'>

 

<= /div>= --_000_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_-- --_004_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Fri, 20 Jan 2012 14:01:32 GMT"; modification-date="Fri, 20 Jan 2012 14:01:32 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_619CDADDCCD2B44380834BE8BF6F7141406003E665EMV62UKRDdoma_-- From jmalyar@telcordia.com Fri Jan 20 06:10:32 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A1721F859B for ; Fri, 20 Jan 2012 06:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuzN4A9UZub3 for ; Fri, 20 Jan 2012 06:10:25 -0800 (PST) Received: from dnsmx1mnh.telcordia.com (dnsmx1mnh.telcordia.com [192.4.156.21]) by ietfa.amsl.com (Postfix) with ESMTP id A193D21F859E for ; Fri, 20 Jan 2012 06:10:24 -0800 (PST) Received: from rrc-dte-bms01.telcordia.com (rrc-dte-bms01.cc.telcordia.com [128.96.150.38]) by dnsmx1mnh.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q0KEAD2X024979; Fri, 20 Jan 2012 09:10:21 -0500 (EST) X-AuditID: 80609626-b7bf3ae0000009f3-b1-4f1975c82244 Received: from rrc-dte-exhb1.dte.telcordia.com (rrc-dte-exhb1.cc.telcordia.com [128.96.20.12]) by rrc-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id C0.BC.02547.8C5791F4; Fri, 20 Jan 2012 09:10:16 -0500 (EST) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Fri, 20 Jan 2012 09:10:21 -0500 From: "Malyar, John P" To: "'andy.sago@bt.com'" , "'paws@ietf.org'" Date: Fri, 20 Jan 2012 09:10:20 -0500 Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCwAALR7Q Message-ID: <5CFF94AC6128EA478EB1B82775E1B6A726F20E5903@rrc-dte-exmb1.dte.telcordia.com> References: <619CDADDCCD2B44380834BE8BF6F7141406003E665@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406003E665@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:10:32 -0000 X-List-Received-Date: Fri, 20 Jan 2012 14:10:32 -0000 --_004_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_ Content-Type: multipart/alternative; boundary="_000_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_" --_000_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, I believe that Step 7 addresses and clarifies the issues raised at the F2F = (at least the ones that I had raised). Thank you. Regards, John Malyar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of and= y.sago@bt.com Sent: Friday, January 20, 2012 9:02 AM To: paws@ietf.org Subject: [paws] Clarification of M2M use case All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The "Note" on= the slide now has two bullets and reads: * Note: Further signalling can take place (outside the scope of PAWS)= to establish direct links among those slave devices that have associated w= ith the master device. * Machine communication over a TVWS channel, whether to a master devi= ce or to another machine (slave device), is under the control of the master= device, and would cease if so requested by the master, or if connection to= the master is lost I have also copied the revised slide here: [cid:image001.png@01CCD753.5562AF90] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description - I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy --_000_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

 

<= p class=3DMsoNormal>I believe that Step 7 addresses and clarifies th= e issues raised at the F2F (at least the ones that I had raised). Thank you= .

 =

Regards,

 

John= Malyar

 <= /span>

From: paws-bounces@ietf.org [mai= lto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com
Sent:= Friday, January 20, 2012 9:02 AM
To: paws@ietf.org
Sub= ject: [paws] Clarification of M2M use case

<= /div>

 

All<= o:p>

 

There was a request for clarification on the M2M use = case presented at the Taipei F2F, in particular with regard to slave-to-sla= ve communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a c= ouple of changes to the M2M slide to make this clearer. We have added two a= rrows so that it is clear that each of the slaves is in communication over = TVWS with the master, as well as the slaves being in communication with eac= h other. The “Note” on the slide now has two bullets and reads:=

 

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l= fo2'>·       <= /span>Note: Further signalling can take place (outside the sco= pe of PAWS) to establish direct links among those slave devices that have a= ssociated with the master device.

·       = Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost

 <= /span>

I have also copied the revised slide here= :

 

=

 

The sequen= ce of events is as follows (note that steps 1-5 are the same as in the use = case description in the current working group draft, but we have removed th= e last sentence in step 6 (previously the final step) so that this can be e= xpanded in the new step 7):

 

   1.  The master device powers up with its whitespace radi= o in idle or

       listen mode only (no active t= ransmission on the whitespace

       frequency ba= nd).

 

 

   2.  The master device has internet connectivity an= d establishes a

       connection to a trusted wh= ite space database (see Section 3.1

  = ;     above).

 

   3.  The master device se= nds its geolocation and location uncertainty

     &nb= sp; information, and optionally additional information which may=

  &n= bsp;    include (1) device ID and (2) antenna characteristic= s, to a

       trusted database, requesting a lis= t of available whitespace

       channels based= upon this information.

 

   4.  The database responds with a = list of available white space

       channels tha= t the master device may use, and optional information

=

    &= nbsp;  which may include inter alia (1) a duration of time for the use=

&nb= sp;      of each channel (channel validity time) (= 2) a maximum radiated

       power for each chann= el, (3) an indication of the quality of the

     &nb= sp; spectrum for each channel and (4) directivity and other antenna

  = ;     information.

 

   5.  Once the master= device authenticates the whitespace channel list

    &nb= sp;  response message from the database, the master device selects one=

&nb= sp;      or more available whitespace channels fro= m the list.

 

   6.  The slave devices fitted to the machines s= can the TV bands to

       locate the master tran= smissions, and associate with the master

       d= evice. 

 

   7.  Further signaling can take place outside= scope of PAWS

       to establish direct links a= mong those slave devices that have

       associa= ted with the same master device. At all times these direct

   &= nbsp;   links are under the control of the master device. Fo= r example,

       common to all use cases, = there may be a regulatory requirement

      &nbs= p;for transmissions from slave to master to cease immediately if so

 &nbs= p;     requested by the master, or if connection t= o the master is lost

       for more than a= specified period of time. When one of these

     &nb= sp; conditions occurs, transmissions from slave to slave would also

 = ;      cease. Direct slave to slave transmiss= ions could only restart if

       each slav= e subsequently restores its connection to the same

    &nb= sp;  master, or each slave joins the network of another master. <= o:p>

 

- end of event sequence description – <= /span>

 

I hope this is now clearer. Please let me have any further queri= es on the reflector.

&n= bsp;

To deflect one set of question= s before they start, please note that we have removed any inference in this= use case that slaves may talk directly with other slaves when one or other= of them is out of range of the master (i.e. a type of relay or proxy funct= ion). This is not a requirement that is particular to M2M, and will be deal= t with in a separate thread.

<= o:p> 

Regards

 

Andy

 

 

=
= --_000_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_-- --_004_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Fri, 20 Jan 2012 14:10:20 GMT"; modification-date="Fri, 20 Jan 2012 14:10:20 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_5CFF94AC6128EA478EB1B82775E1B6A726F20E5903rrcdteexmb1dt_-- From scott.probasco@nokia.com Fri Jan 20 09:50:27 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDCD21F85A7 for ; Fri, 20 Jan 2012 09:50:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg8bVCOT4d+8 for ; Fri, 20 Jan 2012 09:50:26 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 258E021F8575 for ; Fri, 20 Jan 2012 09:50:25 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0KHoCwY007504; Fri, 20 Jan 2012 19:50:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 19:50:17 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.241]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 20 Jan 2012 18:50:16 +0100 From: To: , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAA4qMoAAAD6pAAABmtzgAAGf7GAAAqhM+AAFekFgA== Date: Fri, 20 Jan 2012 17:50:16 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406003E11E@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <053E419121811E42B1DC904992134AD7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jan 2012 17:50:17.0246 (UTC) FILETIME=[F84ADBE0:01CCD79B] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 17:50:27 -0000 Hi Andy, I agree with you the risk of non-delivery of pushed messages is small. The kill switch is one method in the protocol to clear secondary users from specific channels at specific locations. Since Ofcom has included it in their Implementing Geolocation document I believe this is sufficient justification to include this feature in PAWS. Regards, Scott On 1/19/12 6:33 PM, "ext andy.sago@bt.com" wrote: >Scott > >Regarding time constraints for message delivery from the database, Ofcom >has moved away from specifying a time limit for a database to respond to >a request, on the basis that if it is a first request then the master >will not transmit if it fails to receive a response, and if it is a >'revalidation' request and the master receives no response, the master >will cease transmitting anyway when the time validity timer expires. I >think in principle we need not specify a time limit for delivery of >pushed information; if received, the master must act on it, but if not >received, it will continue to transmit until its validity timer expires. >I think that is reasonable. In practice the risk of non-delivery is tiny, >as is the likelihood of invoking the kill switch in the first place as a >method of solving interference issues (even in an emergency). > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 19 January 2012 19:42 >To: paws@ietf.org >Subject: Re: [paws] next steps for the wg > >Hi All, > >I believe it is relevant to look at Ofcom's Implementing Geolocation >Summary of consultation responses and next steps. Paragraph 3.42 states: > >> >>Ofcom retains control over the performance of the algorithms used in >>the databases and will update them if required to manage interference. >>A kill switch is a useful reactive tool and we believe that it should >>form a core part of the protocol which describes the information >>exchange between WSDs and the database. >> > >Following the notion that a kill switch should form a core part of the >protocol, this could be included in a very basic use case like "Hotspot: >urban internet connectivity service". I can volunteer to make this >addition in the use case. > >Regarding the requirement we could say the database must be able to >deliver updated channel information to any registered master device. We >have not specified elsewhere any time constraints on message delivery, I >wonder if this is needed in this case either. > >Kind Regards, >Scott > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >ext Joel M. Halpern >Sent: Thursday, January 19, 2012 11:12 AM >To: Rosen, Brian >Cc: paws@ietf.org >Subject: Re: [paws] next steps for the wg > >Thanks Brian. That works much better for me. >Yours, >Joel > >On 1/19/2012 9:08 AM, Rosen, Brian wrote: >> At this stage, we should say that we have a requirement to change >>availability of spectrum on a short notice, we need a use case that >>would motivate some decision on what "short" means, and we should not >>worry about which mechanism we should choose to achieve it. >> >> Push, fast poll, and notice broadcast (i.e. a single bit sent to all >>clients telling them to "phone home" soon) are all reasonable mechanisms >>to meet the requirements. >> >> Brian >> >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Fri Jan 20 09:59:35 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4B421F863B for ; Fri, 20 Jan 2012 09:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.235 X-Spam-Level: X-Spam-Status: No, score=-103.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCreyIetvgvR for ; Fri, 20 Jan 2012 09:59:35 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id C83CA21F8638 for ; Fri, 20 Jan 2012 09:59:34 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0KHxT7r011352; Fri, 20 Jan 2012 19:59:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 19:59:28 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Fri, 20 Jan 2012 18:59:28 +0100 From: To: , , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAA4qMoAAAD6pAAABmtzgAAGf7GAAAqhM+AAFekFgAAAVdSA Date: Fri, 20 Jan 2012 17:59:27 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <9BA89AF99104884EADAC7A52661EF8E3@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jan 2012 17:59:28.0456 (UTC) FILETIME=[40D6D480:01CCD79D] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 17:59:35 -0000 I believe we have general consensus to include a requirement for unsolicited Push notifications/messages to be sent by the white space device to the master device. Proposal for requirement in I-D: Requirement: A white space database should be able to send unsolicited messages to a master device which has registered with it. The protocol between the WS database and master device MUST allow for push notifications to be sent from the database to the master device. -Raj =20 On 1/20/12 11:50 AM, "ext scott.probasco@nokia.com" wrote: >Hi Andy, > >I agree with you the risk of non-delivery of pushed messages is small. > >The kill switch is one method in the protocol to clear secondary users >from specific channels at specific locations. Since Ofcom has included it >in their Implementing Geolocation document I believe this is sufficient >justification to include this feature in PAWS. > >Regards, >Scott > >On 1/19/12 6:33 PM, "ext andy.sago@bt.com" wrote: > >>Scott >> >>Regarding time constraints for message delivery from the database, Ofcom >>has moved away from specifying a time limit for a database to respond to >>a request, on the basis that if it is a first request then the master >>will not transmit if it fails to receive a response, and if it is a >>'revalidation' request and the master receives no response, the master >>will cease transmitting anyway when the time validity timer expires. I >>think in principle we need not specify a time limit for delivery of >>pushed information; if received, the master must act on it, but if not >>received, it will continue to transmit until its validity timer expires. >>I think that is reasonable. In practice the risk of non-delivery is tiny, >>as is the likelihood of invoking the kill switch in the first place as a >>method of solving interference issues (even in an emergency). >> >>Regards >> >>Andy >> >>-----Original Message----- >>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>scott.probasco@nokia.com >>Sent: 19 January 2012 19:42 >>To: paws@ietf.org >>Subject: Re: [paws] next steps for the wg >> >>Hi All, >> >>I believe it is relevant to look at Ofcom's Implementing Geolocation >>Summary of consultation responses and next steps. Paragraph 3.42 states: >> >>> >>>Ofcom retains control over the performance of the algorithms used in >>>the databases and will update them if required to manage interference. >>>A kill switch is a useful reactive tool and we believe that it should >>>form a core part of the protocol which describes the information >>>exchange between WSDs and the database. >>> >> >>Following the notion that a kill switch should form a core part of the >>protocol, this could be included in a very basic use case like "Hotspot: >>urban internet connectivity service". I can volunteer to make this >>addition in the use case. >> >>Regarding the requirement we could say the database must be able to >>deliver updated channel information to any registered master device. We >>have not specified elsewhere any time constraints on message delivery, I >>wonder if this is needed in this case either. >> >>Kind Regards, >>Scott >> >>-----Original Message----- >>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>ext Joel M. Halpern >>Sent: Thursday, January 19, 2012 11:12 AM >>To: Rosen, Brian >>Cc: paws@ietf.org >>Subject: Re: [paws] next steps for the wg >> >>Thanks Brian. That works much better for me. >>Yours, >>Joel >> >>On 1/19/2012 9:08 AM, Rosen, Brian wrote: >>> At this stage, we should say that we have a requirement to change >>>availability of spectrum on a short notice, we need a use case that >>>would motivate some decision on what "short" means, and we should not >>>worry about which mechanism we should choose to achieve it. >>> >>> Push, fast poll, and notice broadcast (i.e. a single bit sent to all >>>clients telling them to "phone home" soon) are all reasonable mechanisms >>>to meet the requirements. >>> >>> Brian >>> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Fri Jan 20 11:08:17 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79A021F8656 for ; Fri, 20 Jan 2012 11:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C42cC1IY5Ru8 for ; Fri, 20 Jan 2012 11:08:16 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF5821F8648 for ; Fri, 20 Jan 2012 11:08:16 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 20 Jan 2012 14:08:44 -0500 From: Peter Stanforth To: "Basavaraj.Patil@nokia.com" , "scott.probasco@nokia.com" , "andy.sago@bt.com" , "paws@ietf.org" Date: Fri, 20 Jan 2012 14:08:17 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczXpuz0g2o94x/NSH2OcOs86qc6NQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:08:17 -0000 What Brian and I were saying is that we need a mechanism to deal with changes to spectrum availability and that push is only one option. I like the description Brian gave: "At this stage, we should say that we have a requirement to change availability of spectrum on a short notice" On FriJan/20/12 Fri Jan 20, 12:59 PM, "Basavaraj.Patil@nokia.com" wrote: > >I believe we have general consensus to include a requirement for >unsolicited Push notifications/messages to be sent by the white space >device to the master device. >Proposal for requirement in I-D: > >Requirement: A white space database should be able to send unsolicited >messages to a master device which has registered with it. The protocol >between the WS database and master device MUST allow for push >notifications to be sent from the database to the master device. > >-Raj >=20 > >On 1/20/12 11:50 AM, "ext scott.probasco@nokia.com" > wrote: > >>Hi Andy, >> >>I agree with you the risk of non-delivery of pushed messages is small. >> >>The kill switch is one method in the protocol to clear secondary users >>from specific channels at specific locations. Since Ofcom has included it >>in their Implementing Geolocation document I believe this is sufficient >>justification to include this feature in PAWS. >> >>Regards, >>Scott >> >>On 1/19/12 6:33 PM, "ext andy.sago@bt.com" wrote: >> >>>Scott >>> >>>Regarding time constraints for message delivery from the database, Ofcom >>>has moved away from specifying a time limit for a database to respond to >>>a request, on the basis that if it is a first request then the master >>>will not transmit if it fails to receive a response, and if it is a >>>'revalidation' request and the master receives no response, the master >>>will cease transmitting anyway when the time validity timer expires. I >>>think in principle we need not specify a time limit for delivery of >>>pushed information; if received, the master must act on it, but if not >>>received, it will continue to transmit until its validity timer expires. >>>I think that is reasonable. In practice the risk of non-delivery is >>>tiny, >>>as is the likelihood of invoking the kill switch in the first place as a >>>method of solving interference issues (even in an emergency). >>> >>>Regards >>> >>>Andy >>> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>scott.probasco@nokia.com >>>Sent: 19 January 2012 19:42 >>>To: paws@ietf.org >>>Subject: Re: [paws] next steps for the wg >>> >>>Hi All, >>> >>>I believe it is relevant to look at Ofcom's Implementing Geolocation >>>Summary of consultation responses and next steps. Paragraph 3.42 states: >>> >>>> >>>>Ofcom retains control over the performance of the algorithms used in >>>>the databases and will update them if required to manage interference. >>>>A kill switch is a useful reactive tool and we believe that it should >>>>form a core part of the protocol which describes the information >>>>exchange between WSDs and the database. >>>> >>> >>>Following the notion that a kill switch should form a core part of the >>>protocol, this could be included in a very basic use case like "Hotspot: >>>urban internet connectivity service". I can volunteer to make this >>>addition in the use case. >>> >>>Regarding the requirement we could say the database must be able to >>>deliver updated channel information to any registered master device. We >>>have not specified elsewhere any time constraints on message delivery, I >>>wonder if this is needed in this case either. >>> >>>Kind Regards, >>>Scott >>> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>ext Joel M. Halpern >>>Sent: Thursday, January 19, 2012 11:12 AM >>>To: Rosen, Brian >>>Cc: paws@ietf.org >>>Subject: Re: [paws] next steps for the wg >>> >>>Thanks Brian. That works much better for me. >>>Yours, >>>Joel >>> >>>On 1/19/2012 9:08 AM, Rosen, Brian wrote: >>>> At this stage, we should say that we have a requirement to change >>>>availability of spectrum on a short notice, we need a use case that >>>>would motivate some decision on what "short" means, and we should not >>>>worry about which mechanism we should choose to achieve it. >>>> >>>> Push, fast poll, and notice broadcast (i.e. a single bit sent to all >>>>clients telling them to "phone home" soon) are all reasonable >>>>mechanisms >>>>to meet the requirements. >>>> >>>> Brian >>>> >>>_______________________________________________ >>>paws mailing list >>>paws@ietf.org >>>https://www.ietf.org/mailman/listinfo/paws >>>_______________________________________________ >>>paws mailing list >>>paws@ietf.org >>>https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Fri Jan 20 11:13:53 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F34421F85CC for ; Fri, 20 Jan 2012 11:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VhjK6sCzRxG for ; Fri, 20 Jan 2012 11:13:52 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 78CC321F859E for ; Fri, 20 Jan 2012 11:13:52 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0KJDhVE011630; Fri, 20 Jan 2012 21:13:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jan 2012 21:13:43 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Fri, 20 Jan 2012 20:13:42 +0100 From: To: , , , Thread-Topic: [paws] next steps for the wg Thread-Index: AczRhliAfIo6ax8ISdaloRE0jyYFSADq/fYAABKn0gAAEf3zAAA4qMoAAAD6pAAABmtzgAAGf7GAAAqhM+AAFekFgAAAVdSAAA72f4D//50KAA== Date: Fri, 20 Jan 2012 19:13:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D49B662ECCBD14380A79ADF565A90D3@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jan 2012 19:13:43.0459 (UTC) FILETIME=[A03A5730:01CCD7A7] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:13:53 -0000 I am okay with your proposal. But the requirement as worded is specifically tied to a specific usage scenario. Whereas the Push mechanism could be applied for other reasons as well. -Raj On 1/20/12 1:08 PM, "ext Peter Stanforth" wrote: >What Brian and I were saying is that we need a mechanism to deal with >changes to spectrum availability and that push is only one option. I like >the description Brian gave: >"At this stage, we should say that we have a requirement to change >availability of spectrum on a short notice" > > > >On FriJan/20/12 Fri Jan 20, 12:59 PM, "Basavaraj.Patil@nokia.com" > wrote: > >> >>I believe we have general consensus to include a requirement for >>unsolicited Push notifications/messages to be sent by the white space >>device to the master device. >>Proposal for requirement in I-D: >> >>Requirement: A white space database should be able to send unsolicited >>messages to a master device which has registered with it. The protocol >>between the WS database and master device MUST allow for push >>notifications to be sent from the database to the master device. >> >>-Raj >>=20 >> >>On 1/20/12 11:50 AM, "ext scott.probasco@nokia.com" >> wrote: >> >>>Hi Andy, >>> >>>I agree with you the risk of non-delivery of pushed messages is small. >>> >>>The kill switch is one method in the protocol to clear secondary users >>>from specific channels at specific locations. Since Ofcom has included >>>it >>>in their Implementing Geolocation document I believe this is sufficient >>>justification to include this feature in PAWS. >>> >>>Regards, >>>Scott >>> >>>On 1/19/12 6:33 PM, "ext andy.sago@bt.com" wrote: >>> >>>>Scott >>>> >>>>Regarding time constraints for message delivery from the database, >>>>Ofcom >>>>has moved away from specifying a time limit for a database to respond >>>>to >>>>a request, on the basis that if it is a first request then the master >>>>will not transmit if it fails to receive a response, and if it is a >>>>'revalidation' request and the master receives no response, the master >>>>will cease transmitting anyway when the time validity timer expires. I >>>>think in principle we need not specify a time limit for delivery of >>>>pushed information; if received, the master must act on it, but if not >>>>received, it will continue to transmit until its validity timer >>>>expires. >>>>I think that is reasonable. In practice the risk of non-delivery is >>>>tiny, >>>>as is the likelihood of invoking the kill switch in the first place as >>>>a >>>>method of solving interference issues (even in an emergency). >>>> >>>>Regards >>>> >>>>Andy >>>> >>>>-----Original Message----- >>>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>>scott.probasco@nokia.com >>>>Sent: 19 January 2012 19:42 >>>>To: paws@ietf.org >>>>Subject: Re: [paws] next steps for the wg >>>> >>>>Hi All, >>>> >>>>I believe it is relevant to look at Ofcom's Implementing Geolocation >>>>Summary of consultation responses and next steps. Paragraph 3.42 >>>>states: >>>> >>>>> >>>>>Ofcom retains control over the performance of the algorithms used in >>>>>the databases and will update them if required to manage interference. >>>>>A kill switch is a useful reactive tool and we believe that it should >>>>>form a core part of the protocol which describes the information >>>>>exchange between WSDs and the database. >>>>> >>>> >>>>Following the notion that a kill switch should form a core part of the >>>>protocol, this could be included in a very basic use case like >>>>"Hotspot: >>>>urban internet connectivity service". I can volunteer to make this >>>>addition in the use case. >>>> >>>>Regarding the requirement we could say the database must be able to >>>>deliver updated channel information to any registered master device. We >>>>have not specified elsewhere any time constraints on message delivery, >>>>I >>>>wonder if this is needed in this case either. >>>> >>>>Kind Regards, >>>>Scott >>>> >>>>-----Original Message----- >>>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>>ext Joel M. Halpern >>>>Sent: Thursday, January 19, 2012 11:12 AM >>>>To: Rosen, Brian >>>>Cc: paws@ietf.org >>>>Subject: Re: [paws] next steps for the wg >>>> >>>>Thanks Brian. That works much better for me. >>>>Yours, >>>>Joel >>>> >>>>On 1/19/2012 9:08 AM, Rosen, Brian wrote: >>>>> At this stage, we should say that we have a requirement to change >>>>>availability of spectrum on a short notice, we need a use case that >>>>>would motivate some decision on what "short" means, and we should not >>>>>worry about which mechanism we should choose to achieve it. >>>>> >>>>> Push, fast poll, and notice broadcast (i.e. a single bit sent to all >>>>>clients telling them to "phone home" soon) are all reasonable >>>>>mechanisms >>>>>to meet the requirements. >>>>> >>>>> Brian >>>>> >>>>_______________________________________________ >>>>paws mailing list >>>>paws@ietf.org >>>>https://www.ietf.org/mailman/listinfo/paws >>>>_______________________________________________ >>>>paws mailing list >>>>paws@ietf.org >>>>https://www.ietf.org/mailman/listinfo/paws >>> >>>_______________________________________________ >>>paws mailing list >>>paws@ietf.org >>>https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > From jmalyar@telcordia.com Fri Jan 20 11:14:08 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1C21F8646 for ; Fri, 20 Jan 2012 11:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XG7SocmMs8V for ; Fri, 20 Jan 2012 11:14:07 -0800 (PST) Received: from dnsmx1mnh.telcordia.com (dnsmx1mnh.telcordia.com [192.4.156.21]) by ietfa.amsl.com (Postfix) with ESMTP id 89C6621F8587 for ; Fri, 20 Jan 2012 11:14:07 -0800 (PST) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx1mnh.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q0KJE0ni008798; Fri, 20 Jan 2012 14:14:04 -0500 (EST) X-AuditID: 80602530-b7bceae0000009fd-7f-4f19bcf50bdb Received: from pya-dte-exhb1.dte.telcordia.com (pya-dte-exhb1.cc.telcordia.com [128.96.20.11]) by pya-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id 66.EA.02557.5FCB91F4; Fri, 20 Jan 2012 14:13:57 -0500 (EST) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by pya-dte-exhb1.dte.telcordia.com ([128.96.20.11]) with mapi; Fri, 20 Jan 2012 14:14:03 -0500 From: "Malyar, John P" To: "'Peter Stanforth'" , "'Basavaraj.Patil@nokia.com'" , "'scott.probasco@nokia.com'" , "'andy.sago@bt.com'" , "'paws@ietf.org'" Date: Fri, 20 Jan 2012 14:14:02 -0500 Thread-Topic: [paws] next steps for the wg Thread-Index: AczXpuz0g2o94x/NSH2OcOs86qc6NQAAADBQ Message-ID: <5CFF94AC6128EA478EB1B82775E1B6A726F20E5FD6@rrc-dte-exmb1.dte.telcordia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [paws] next steps for the wg X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:14:08 -0000 Peter, I also believe that the description Brian shared is the most flexible way t= o address the functional need. It gives us an opportunity to review the pos= sible implementations. The way it was recently described by Raj specifies a= specific implementation that may/will have significant impact on the maste= r white space device (i.e. is must also be a Server to support notification= s).=20 Regards, John=20 -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pet= er Stanforth Sent: Friday, January 20, 2012 2:08 PM To: Basavaraj.Patil@nokia.com; scott.probasco@nokia.com; andy.sago@bt.com; = paws@ietf.org Subject: Re: [paws] next steps for the wg What Brian and I were saying is that we need a mechanism to deal with changes to spectrum availability and that push is only one option. I like the description Brian gave: "At this stage, we should say that we have a requirement to change availability of spectrum on a short notice" On FriJan/20/12 Fri Jan 20, 12:59 PM, "Basavaraj.Patil@nokia.com" wrote: > >I believe we have general consensus to include a requirement for >unsolicited Push notifications/messages to be sent by the white space >device to the master device. >Proposal for requirement in I-D: > >Requirement: A white space database should be able to send unsolicited >messages to a master device which has registered with it. The protocol >between the WS database and master device MUST allow for push >notifications to be sent from the database to the master device. > >-Raj >=20 > >On 1/20/12 11:50 AM, "ext scott.probasco@nokia.com" > wrote: > >>Hi Andy, >> >>I agree with you the risk of non-delivery of pushed messages is small. >> >>The kill switch is one method in the protocol to clear secondary users >>from specific channels at specific locations. Since Ofcom has included it >>in their Implementing Geolocation document I believe this is sufficient >>justification to include this feature in PAWS. >> >>Regards, >>Scott >> >>On 1/19/12 6:33 PM, "ext andy.sago@bt.com" wrote: >> >>>Scott >>> >>>Regarding time constraints for message delivery from the database, Ofcom >>>has moved away from specifying a time limit for a database to respond to >>>a request, on the basis that if it is a first request then the master >>>will not transmit if it fails to receive a response, and if it is a >>>'revalidation' request and the master receives no response, the master >>>will cease transmitting anyway when the time validity timer expires. I >>>think in principle we need not specify a time limit for delivery of >>>pushed information; if received, the master must act on it, but if not >>>received, it will continue to transmit until its validity timer expires. >>>I think that is reasonable. In practice the risk of non-delivery is >>>tiny, >>>as is the likelihood of invoking the kill switch in the first place as a >>>method of solving interference issues (even in an emergency). >>> >>>Regards >>> >>>Andy >>> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>scott.probasco@nokia.com >>>Sent: 19 January 2012 19:42 >>>To: paws@ietf.org >>>Subject: Re: [paws] next steps for the wg >>> >>>Hi All, >>> >>>I believe it is relevant to look at Ofcom's Implementing Geolocation >>>Summary of consultation responses and next steps. Paragraph 3.42 states: >>> >>>> >>>>Ofcom retains control over the performance of the algorithms used in >>>>the databases and will update them if required to manage interference. >>>>A kill switch is a useful reactive tool and we believe that it should >>>>form a core part of the protocol which describes the information >>>>exchange between WSDs and the database. >>>> >>> >>>Following the notion that a kill switch should form a core part of the >>>protocol, this could be included in a very basic use case like "Hotspot: >>>urban internet connectivity service". I can volunteer to make this >>>addition in the use case. >>> >>>Regarding the requirement we could say the database must be able to >>>deliver updated channel information to any registered master device. We >>>have not specified elsewhere any time constraints on message delivery, I >>>wonder if this is needed in this case either. >>> >>>Kind Regards, >>>Scott >>> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>ext Joel M. Halpern >>>Sent: Thursday, January 19, 2012 11:12 AM >>>To: Rosen, Brian >>>Cc: paws@ietf.org >>>Subject: Re: [paws] next steps for the wg >>> >>>Thanks Brian. That works much better for me. >>>Yours, >>>Joel >>> >>>On 1/19/2012 9:08 AM, Rosen, Brian wrote: >>>> At this stage, we should say that we have a requirement to change >>>>availability of spectrum on a short notice, we need a use case that >>>>would motivate some decision on what "short" means, and we should not >>>>worry about which mechanism we should choose to achieve it. >>>> >>>> Push, fast poll, and notice broadcast (i.e. a single bit sent to all >>>>clients telling them to "phone home" soon) are all reasonable >>>>mechanisms >>>>to meet the requirements. >>>> >>>> Brian >>>> >>>_______________________________________________ >>>paws mailing list >>>paws@ietf.org >>>https://www.ietf.org/mailman/listinfo/paws >>>_______________________________________________ >>>paws mailing list >>>paws@ietf.org >>>https://www.ietf.org/mailman/listinfo/paws >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Tue Jan 24 09:50:06 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EDA11E807A for ; Tue, 24 Jan 2012 09:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=-0.658, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-5lyxJtAV2x for ; Tue, 24 Jan 2012 09:50:05 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5865211E8088 for ; Tue, 24 Jan 2012 09:50:05 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0OHnuQK014761; Tue, 24 Jan 2012 19:49:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 19:49:55 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Tue, 24 Jan 2012 18:49:55 +0100 From: To: , Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCwDCefoA Date: Tue, 24 Jan 2012 17:49:54 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406003E665@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.36] Content-Type: multipart/related; boundary="_004_CB444B0C186ABbasavarajpatilnokiacom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2012 17:49:55.0795 (UTC) FILETIME=[9528B230:01CCDAC0] X-Nokia-AV: Clean Subject: Re: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 17:50:07 -0000 --_004_CB444B0C186ABbasavarajpatilnokiacom_ Content-Type: multipart/alternative; boundary="_000_CB444B0C186ABbasavarajpatilnokiacom_" --_000_CB444B0C186ABbasavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, Question about the following statement: " Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost " How does the master know that slaves are communicating with each other dire= ctly using TVWS channels? Do you assume that communication between slaves i= s routed through the master? -Raj From: "andy.sago@bt.com" > Date: Fri, 20 Jan 2012 14:01:32 +0000 To: "paws@ietf.org" > Subject: [paws] Clarification of M2M use case All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The =93Note= =94 on the slide now has two bullets and reads: =B7 Note: Further signalling can take place (outside the scope of P= AWS) to establish direct links among those slave devices that have associat= ed with the master device. =B7 Machine communication over a TVWS channel, whether to a master = device or to another machine (slave device), is under the control of the ma= ster device, and would cease if so requested by the master, or if connectio= n to the master is lost I have also copied the revised slide here: [cid:image001.png@01CCD76C.DFFAFEF0] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description =96 I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB444B0C186ABbasavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <23DFAC158C11764F88BC002BF258F0DD@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Andy,

Question about the following statement:
"
Machine communication over a TVWS channel, whether to a mas= ter device or to another machine (slave device), is under the control of th= e master device, and would cease if so requested by the master, or if connection to the master is lost<= /div>
"

How does the master know that slaves are communicating with each other= directly using TVWS channels? Do you assume that communication between sla= ves is routed through the master?

-Raj

From: "andy.sago@bt.com" <andy.sago@bt.com>
Date: Fri, 20 Jan 2012 14:01:32 = 3;0000
To: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] Clarification of M2= M use case

All

 

There was a request for clarification on the M2M us= e case presented at the Taipei F2F, in particular with regard to slave-to-s= lave communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to the M2M slide to = make this clearer. We have added two arrows so that it is clear that each o= f the slaves is in communication over TVWS with the master, as well as the = slaves being in communication with each other. The =93Note=94 on the slide now has two bullets and reads:

 

=B7         Note: Further signalling can take place= (outside the scope of PAWS) to establish direct links among those slave de= vices that have associated with the master device.

=B7         Machine communication over a TVWS chann= el, whether to a master device or to another machine (slave device), is und= er the control of the master device, and would cease if so requested by the master, or if connection to the mas= ter is lost

 

I have also copied the revised slide here:

 

 

The sequence of events is as follows (note that ste= ps 1-5 are the same as in the use case description in the current working g= roup draft, but we have removed the last sentence in step 6 (previously the final step) so that this can be ex= panded in the new step 7):

 

   1.&nb= sp; The master device powers up with its whitespace radio in idle or

   =     listen mode only (no active transmission on the whitespa= ce

   =     frequency band).

 <= /span>

 <= /span>

   2.&nb= sp; The master device has internet connectivity and establishes a

   =     connection to a trusted white space database (see Section 3.1

   =     above).

 <= /span>

   3.&nb= sp; The master device sends its geolocation and location uncertainty

   =     information, and optionally additional information which= may

   =     include (1) device ID and (2) antenna characteristics, t= o a

   =     trusted database, requesting a list of available whitesp= ace

   =     channels based upon this information.<= /p>

 <= /span>

   4.&nb= sp; The database responds with a list of available white space

   =     channels that the master device may use, and optional in= formation

   =     which may include inter alia (1) a duration of time for = the use

   =     of each channel (channel validity time) (2) a maximum ra= diated

   =     power for each channel, (3) an indication of the quality= of the

   =     spectrum for each channel and (4) directivity and other = antenna

   =     information.

 <= /span>

   5.&nb= sp; Once the master device authenticates the whitespace channel list

   =     response message from the database, the master device se= lects one

   =     or more available whitespace channels from the list.

 <= /span>

   6.&nb= sp; The slave devices fitted to the machines scan the TV bands to

   =     locate the master transmissions, and associate with the = master

   =     device. 

 <= /span>

   7.&nb= sp; Further signaling can take place outside scope of PAWS

   =     to establish direct links among those slave devices that= have

   =     associated with the same master device. At all times the= se direct

   =     links are under the control of the master device. F= or example,

   =     common to all use cases, there may be a regulatory = requirement

   =     for transmissions from slave to master to cease imm= ediately if so

   =     requested by the master, or if connection to the ma= ster is lost

   =     for more than a specified period of time. When one = of these

   =     conditions occurs, transmissions from slave to slav= e would also

   =     cease. Direct slave to slave transmissions could on= ly restart if

   =     each slave subsequently restores its connection to = the same

   =     master, or each slave joins the network of another = master.

 

- end of event sequence description =96

 

I hope this is now clearer. Please let me have any = further queries on the reflector.

 

To deflect one set of questions before they start, = please note that we have removed any inference in this use case that slaves= may talk directly with other slaves when one or other of them is out of range of the master (i.e. a type of re= lay or proxy function). This is not a requirement that is particular to M2M= , and will be dealt with in a separate thread.

 

Regards

 

Andy

 

&nbs= p;

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB444B0C186ABbasavarajpatilnokiacom_-- --_004_CB444B0C186ABbasavarajpatilnokiacom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Tue, 24 Jan 2012 17:49:54 GMT"; modification-date="Tue, 24 Jan 2012 17:49:54 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_CB444B0C186ABbasavarajpatilnokiacom_-- From andy.sago@bt.com Wed Jan 25 07:07:03 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC81B21F8613 for ; Wed, 25 Jan 2012 07:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsHZ+52oAMJN for ; Wed, 25 Jan 2012 07:06:59 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 7B34F21F8605 for ; Wed, 25 Jan 2012 07:06:58 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 25 Jan 2012 15:06:56 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Wed, 25 Jan 2012 15:06:56 +0000 From: To: , Date: Wed, 25 Jan 2012 15:06:52 +0000 Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCwDCefoAADnTZRA= Message-ID: <619CDADDCCD2B44380834BE8BF6F71414060BB50DF@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F7141406003E665@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/related; boundary="_004_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:07:03 -0000 --_004_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_ Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_" --_000_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raj The master doesn't need to know that slaves are talking direct, and traffic= is not routed through the master. Each slave is within range of the master= , and associated to it. A command from the master to tell slaves stop TVWS = communications on the current channel (if such a protocol is developed) wou= ld be received by all slaves and acted upon. This would apply to slave-slav= e transmissions as well as slave-master transmissions since they are both u= sing TVWS. Alternatively if the master dropped comms (stopped beaconing or = whatever) then both slaves could detect that, and the default action then w= ould be to cease all transmissions over the air, to the master or to other = slaves. Thus, the direct slave-slave transmissions are under control of the= master in so far as the master decides whether all slaves can transmit or = not, based on information from the database. I don't think there is anythin= g extra needed wrt PAWS protocols to enable this. The scenario is similar if the master is allocated a choice of channels by = the database, and the list is passed to the slave. I suppose the master cou= ld make itself known on channel A, and slaves associate on channel A and ar= e told that channels B and C are also available (at particular powers etc).= They then use B and C for direct slave-slave comms. If the database indica= tes (by push or pull) a revised list of channels to the master, with channe= l A still usable but B or C not, then the changed list of frequencies shoul= d be signalled to the slave. This could result in a change of frequency by = the slave, rather than a ceasing of all transmissions, and the existing net= work on channel A would be unaffected. The previous paragraph is just a theoretical exercise, I don't see any reas= on why slave-slave comms would use a different channel to slave-master com= ms in the M2M use case, but don't see any reason to prevent it. Regards Andy From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: 24 January 2012 17:50 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] Clarification of M2M use case Hi Andy, Question about the following statement: " Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost " How does the master know that slaves are communicating with each other dire= ctly using TVWS channels? Do you assume that communication between slaves i= s routed through the master? -Raj From: "andy.sago@bt.com" > Date: Fri, 20 Jan 2012 14:01:32 +0000 To: "paws@ietf.org" > Subject: [paws] Clarification of M2M use case All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The "Note" on= the slide now has two bullets and reads: * Note: Further signalling can take place (outside the scope of PAW= S) to establish direct links among those slave devices that have associated= with the master device. * Machine communication over a TVWS channel, whether to a master de= vice or to another machine (slave device), is under the control of the mast= er device, and would cease if so requested by the master, or if connection = to the master is lost I have also copied the revised slide here: [cid:image001.png@01CCDB6E.21499E20] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description - I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raj

 

The master doesn̵= 7;t need to know that slaves are talking direct, and traffic is not routed = through the master. Each slave is within range of the master, and associate= d to it. A command from the master to tell slaves stop TVWS communications = on the current channel (if such a protocol is developed) would be received = by all slaves and acted upon. This would apply to slave-slave transmissions= as well as slave-master transmissions since they are both using TVWS. Alte= rnatively if the master dropped comms (stopped beaconing or whatever) then = both slaves could detect that, and the default action then would be to ceas= e all transmissions over the air, to the master or to other slaves. Thus, t= he direct slave-slave transmissions are under control of the master in so f= ar as the master decides whether all slaves can transmit or not, based on i= nformation from the database. I don’t think there is anything extra n= eeded wrt PAWS protocols to enable this.

 

The scenario is similar if the master = is allocated a choice of channels by the database, and the list is passed t= o the slave. I suppose the master could make itself known on channel A, and= slaves associate on channel A and are told that channels B and C are also = available (at particular powers etc). They then use B and C for direct slav= e-slave comms. If the database indicates (by push or pull) a revised list o= f channels to the master, with channel A still usable but B or C not, then = the changed list of frequencies should be signalled to the slave. This coul= d result in a change of frequency by the slave, rather than a ceasing of al= l transmissions, and the existing network on channel A would be unaffected.=

 

The= previous paragraph is just a theoretical exercise, I don’t see any r= eason why slave-slave comms would use a different channel  to slave-ma= ster comms in the M2M use case, but don’t see any reason to prevent i= t.

 

R= egards

 

Andy

 

 

= From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nok= ia.com]
Sent: 24 January 2012 17:50
To: Sago,AJ,Andy,C= OD R; paws@ietf.org
Subject: Re: [paws] Clarification of M2M use = case

 

 

=

Hi Andy,

 

Question about the following statement:

=

"

Machine communication over a TVWS chan= nel, whether to a master device or to another machine (slave device), is un= der the control of the master device, and would cease if so requested by th= e master, or if connection to the master is lost<= /o:p>

"=

 

How do= es the master know that slaves are communicating with each other directly u= sing TVWS channels? Do you assume that communication between slaves is rout= ed through the master?

 

-Raj=

 

From: "andy.sago@bt.com" <= ;andy.sago@bt.com>
Date: <= /b>Fri, 20 Jan 2012 14:01:32 +0000
To: "paws@ietf.org" <p= aws@ietf.org>
Subject: [paws] Clarification of M2M use cas= e

 

All

 

There was a request for clarification on= the M2M use case presented at the Taipei F2F, in particular with regard to= slave-to-slave communication. Juan Carlos Zuniga, Mike Fitch and myself ha= ve agreed a couple of changes to the M2M slide to make this clearer. We hav= e added two arrows so that it is clear that each of the slaves is in commun= ication over TVWS with the master, as well as the slaves being in communica= tion with each other. The “Note” on the slide now has two bulle= ts and reads:

 

·         <= ![endif]>N= ote: Further signalling can take place (outside the scope of PAWS) to estab= lish direct links among those slave devices that have associated with the m= aster device.

·         = = Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost

 

I have also copied the revised slide here:

 

 

The sequence of e= vents is as follows (note that steps 1-5 are the same as in the use case de= scription in the current working group draft, but we have removed the last = sentence in step 6 (previously the final step) so that this can be expanded= in the new step 7):

 

  = 1.  The master device powers up with its whitespace radio in idle or<= /span>

     &n= bsp; listen mode only (no active transmission on the whitespace

       freque= ncy band).

 

 =

   2.  The master device has internet connectivity and e= stablishes a

   &= nbsp;   connection to a trusted white space database (see Section 3.1

<= span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New";color:bl= ack'>       above).

 

 &= nbsp; 3.  The master device sends its geolocation and location uncerta= inty

    &nb= sp;  information, and optionally additional information which may

      = include (1) device ID and (2) antenna characteristics, to a

       trusted d= atabase, requesting a list of available whitespace

       channels based upon= this information.

=

 =

   4.  The database res= ponds with a list of available white space

       channels that the master de= vice may use, and optional information

       which may include inter alia (1= ) a duration of time for the use

       of each channel (channel validity tim= e) (2) a maximum radiated

&nbs= p;      power for each channel, (3) an indication = of the quality of the<= /p>

 &nbs= p;     spectrum for each channel and (4) directivity an= d other antenna

  &nb= sp;    information.<= /o:p>

 

   5. = Once the master device authenticates the whitespace channel list

       re= sponse message from the database, the master device selects one

       or mor= e available whitespace channels from the list.

 &nbs= p; 6.  The slave devices fitted to the machines scan the TV bands to

     &nb= sp; locate the master transmissions, and associate with the master

       de= vice. 

 

   7.  Further signaling can = take place outside scope of PAWS

       to establish direct links among those= slave devices that have

 &= nbsp;     associated with the same master device. At al= l times these direct <= /p>

 &nbs= p;     links are under the control of the master d= evice. For example,

  = ;     common to all use cases, there may be a regu= latory requirement

  =      for transmissions from slave to master to cea= se immediately if so <= /p>

 &nbs= p;     requested by the master, or if connection t= o the master is lost <= /p>

 &nbs= p;     for more than a specified period of time. W= hen one of these

<= p class=3DMsoNormal style=3D'page-break-before:always'>  &n= bsp;    conditions occurs, transmissions from slave to = slave would also

<= p class=3DMsoNormal style=3D'page-break-before:always'>  &n= bsp;    cease. Direct slave to slave transmissions coul= d only restart if

=

  &= nbsp;    each slave subsequently restores its connectio= n to the same

  &nb= sp;    master, or each slave joins the network of anoth= er master.

 

- end of event sequence description –

 

I hope this is now cleare= r. Please let me have any further queries on the reflector.

 

To deflect one set of= questions before they start, please note that we have removed any inferenc= e in this use case that slaves may talk directly with other slaves when one= or other of them is out of range of the master (i.e. a type of relay or pr= oxy function). This is not a requirement that is particular to M2M, and wil= l be dealt with in a separate thread.

 

Regards

 =

Andy

 

 

=

________________________________________= _______ paws mailing list paws@ietf.org https://www.ietf.o= rg/mailman/listinfo/paws

= --_000_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_-- --_004_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Wed, 25 Jan 2012 15:06:52 GMT"; modification-date="Wed, 25 Jan 2012 15:06:52 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_619CDADDCCD2B44380834BE8BF6F71414060BB50DFEMV62UKRDdoma_-- From scott.probasco@nokia.com Wed Jan 25 12:49:16 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52CF11E80C7 for ; Wed, 25 Jan 2012 12:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.179 X-Spam-Level: X-Spam-Status: No, score=-1.179 tagged_above=-999 required=5 tests=[AWL=-1.420, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMagmoSxXy5Q for ; Wed, 25 Jan 2012 12:49:15 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAAD21F857A for ; Wed, 25 Jan 2012 12:49:15 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0PKmblC003268 for ; Wed, 25 Jan 2012 22:49:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 22:49:11 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.241]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Wed, 25 Jan 2012 21:49:10 +0100 From: To: Thread-Topic: Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM26LJph+Yc0pEHUy0sgx3BmU5sA== Date: Wed, 25 Jan 2012 20:49:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2012 20:49:11.0912 (UTC) FILETIME=[CAB7A680:01CCDBA2] X-Nokia-AV: Clean Subject: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 20:49:16 -0000 SGVsbG8gQWxsLA0KDQpBcyBlZGl0b3JzIG9mIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNh c2VzICYgcmVxdWlyZW1lbnRzIGRyYWZ0IHdlIGFyZQ0KYXR0ZW1wdGluZyB0byBwcmVwYXJlIGEg Y29tcGxldGVkIGRyYWZ0IHdoaWNoIGNvdWxkIGJlIHJlYWR5IGZvciB3b3JraW5nDQpncm91cCBs YXN0IGNhbGwgYmVmb3JlIElFVEY4My4gSW4gdGhlIGNvbWluZyBkYXlzIHdlIHdpbGwgcG9zdCB0 aGUNCnNlY3Rpb25zIG9mIHRoZSBkcmFmdCB0byB0aGUgbWFpbGluZyBsaXN0LiBPdXIgcmVxdWVz dCBpcyB0aGF0IHlvdSByZXZpZXcNCnRoZXNlIHNlY3Rpb25zIGFuZCByZXBseSB0byB0aGUgZW1h aWwgd2l0aCBhbnkgY29tbWVudHMuDQoNCkJlbG93IGlzIHRoZSB0ZXh0IGZvciBzZWN0aW9ucyAx IHRvIDMuIFRoaXMgdGV4dCBoYXMgbm90IGNoYW5nZWQgZnJvbQ0KdmVyc2lvbi0wMSBhcyB1cGxv YWRlZCBPY3RvYmVyIDMxLCAyMDExLiBPdXIgZ29hbCBpcyB0aGF0IGFueSBkaXNjdXNzaW9uDQpv biB0aGlzIHRleHQgd2lsbCBjb25jbHVkZSBieSBGZWJydWFyeSAxLiBUbyBiZSBjbGVhciwgYXBw cm92YWwgb2YgdGhlDQpkb2N1bWVudCB3aWxsIGdvIHRocm91Z2ggdGhlIG5vcm1hbCBwcm9jZXNz IG9mIGxhc3QgY2FsbHMgZXRjLi4gV2UgYXJlDQpzaW1wbHkgYXNraW5nIGZvciB5b3VyIGFzc2lz dGFuY2UgaW4gcHJlcGFyaW5nIGEgY29tcGxldGUgJiBhY2N1cmF0ZQ0KZG9jdW1lbnQgdGhhdCBj b3VsZCBwcm9ncmVzcyB0aGUgd29yay4gU28gcGxlYXNlIHJldmlldyB0aGUgdGV4dCBhbmQgc2Vu ZA0KeW91ciBjb21tZW50cyBlaXRoZXIgZGlyZWN0bHkgdG8gdGhlIGVkaXRvciBvciB0byB0aGUg bWFpbGluZyBsaXN0Lg0KDQpLaW5kIFJlZ2FyZHMsDQpSYWogJiBTY290dA0KDQoNCjEuICBJbnRy b2R1Y3Rpb24NCg0KMS4xLiAgSW50cm9kdWN0aW9uIHRvIFRWIHdoaXRlIHNwYWNlDQoNCiAgIFdp cmVsZXNzIHNwZWN0cnVtIGlzIGEgY29tbW9kaXR5IHRoYXQgaXMgcmVndWxhdGVkIGJ5IGdvdmVy bm1lbnRzLg0KICAgVGhlIHNwZWN0cnVtIGlzIHVzZWQgZm9yIHZhcmlvdXMgcHVycG9zZXMsIHdo aWNoIGluY2x1ZGUNCiAgIGVudGVydGFpbm1lbnQgKGUuZy4gcmFkaW8gYW5kIHRlbGV2aXNpb24p LCBjb21tdW5pY2F0aW9uICh0ZWxlcGhvbnkNCiAgIGFuZCBJbnRlcm5ldCBhY2Nlc3MpLCBtaWxp dGFyeSAocmFkYXJzIGV0Yy4pIGFuZCwgbmF2aWdhdGlvbg0KICAgKHNhdGVsbGl0ZSBjb21tdW5p Y2F0aW9uLCBHUFMpLiAgUG9ydGlvbnMgb2YgdGhlIHJhZGlvIHNwZWN0cnVtIHRoYXQNCiAgIGFy ZSBhbGxvY2F0ZWQgdG8gYSBsaWNlbnNlZCwgcHJpbWFyeSB1c2VyIGJ1dCBhcmUgdW51c2VkIG9y DQogICB1bm9jY3VwaWVkIGF0IHNwZWNpZmljIGxvY2F0aW9ucyBhbmQgdGltZXMgYXJlIGRlZmlu ZWQgYXMgIndoaXRlDQogICBzcGFjZSIuICBUaGUgY29uY2VwdCBvZiBhbGxvd2luZyBzZWNvbmRh cnkgdHJhbnNtaXNzaW9ucyAobGljZW5zZWQgb3INCiAgIHVubGljZW5zZWQpIGluIHdoaXRlIHNw YWNlIGlzIGEgdGVjaG5pcXVlIHRvICJ1bmxvY2siIGV4aXN0aW5nDQogICBzcGVjdHJ1bSBmb3Ig bmV3IHVzZS4gIEFuIG9idmlvdXMgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGVzZSBzZWNvbmRhcnkN CiAgIHRyYW5zbWlzc2lvbnMgZG8gbm90IGludGVyZmVyZSB3aXRoIHRoZSBwcmltYXJ5IHVzZSBv ZiB0aGUgc3BlY3RydW0uDQogICBPbmUgaW50ZXJlc3Rpbmcgb2JzZXJ2YXRpb24gaXMgdGhhdCBv ZnRlbiwgaW4gYSBnaXZlbiBwaHlzaWNhbA0KICAgbG9jYXRpb24sIHRoZSBwcmltYXJ5IHVzZXIo cykgbWF5IG5vdCBiZSB1c2luZyB0aGUgZW50aXJlIGJhbmQNCiAgIGFsbG9jYXRlZCB0byB0aGVt LiAgVGhlIGF2YWlsYWJsZSBzcGVjdHJ1bSBmb3IgYSBzZWNvbmRhcnkgdXNlIHdvdWxkDQogICB0 aGVuIGRlcGVuZCBvbiB0aGUgbG9jYXRpb24gb2YgdGhlIHNlY29uZGFyeSB1c2VyLiAgVGhlIGZ1 bmRhbWVudGFsDQogICBpc3N1ZSBpcyBob3cgdG8gZGV0ZXJtaW5lIGZvciBhIHNwZWNpZmljIGxv Y2F0aW9uIGFuZCBzcGVjaWZpYyB0aW1lLA0KICAgaWYgYW55IG9mIHRoZSBwcmltYXJ5IHNwZWN0 cnVtIGlzIGF2YWlsYWJsZSBmb3Igc2Vjb25kYXJ5IHVzZS4NCiAgIEFjYWRlbWlhIGFuZCBJbmR1 c3RyeSBoYXZlIHN0dWRpZWQgbXVsdGlwbGUgY29nbml0aXZlIHJhZGlvDQogICBtZWNoYW5pc21z IGZvciB1c2UgaW4gc3VjaCBhIHNjZW5hcmlvLiAgT25lIHNpbXBsZSBtZWNoYW5pc20gaXMgdG8N CiAgIHVzZSBhIGdlb3NwYXRpYWwgZGF0YWJhc2UgdGhhdCByZWNvcmRzIHRoZSBwcmltYXJ5IHVz ZXJzIG9jY3VwYXRpb24sDQogICBhbmQgcmVxdWlyZSB0aGUgc2Vjb25kYXJ5IHVzZXJzIHRvIGNo ZWNrIHRoZSBkYXRhYmFzZSBwcmlvciB0bw0KICAgc2VsZWN0aW5nIHdoYXQgcGFydCBvZiB0aGUg c3BlY3RydW0gdGhleSB1c2UuICBTdWNoIGRhdGFiYXNlcyBjb3VsZA0KICAgYmUgYXZhaWxhYmxl IG9uIHRoZSBJbnRlcm5ldCBmb3IgcXVlcnkgYnkgc2Vjb25kYXJ5IHVzZXJzLg0KDQogICBTcGVj dHJ1bSB1c2VhYmxlIGZvciBkYXRhIGNvbW11bmljYXRpb25zLCBlc3BlY2lhbGx5IHdpcmVsZXNz DQogICBJbnRlcm5ldCBjb21tdW5pY2F0aW9ucywgaXMgc2NhcmNlLiAgT25lIGFyZWEgd2hpY2gg aGFzIHJlY2VpdmVkIG11Y2gNCiAgIGF0dGVudGlvbiBnbG9iYWxseSBpcyB0aGUgVFYgd2hpdGUg c3BhY2U6IHBvcnRpb25zIG9mIHRoZSBUViBiYW5kDQogICB0aGF0IGFyZSBub3QgdXNlZCBieSBi cm9hZGNhc3RlcnMgaW4gYSBnaXZlbiBhcmVhLiAgSW4gMjAwOCB0aGUNCiAgIFVuaXRlZCBTdGF0 ZXMgcmVndWxhdG9yICh0aGUgRkNDKSB0b29rIGluaXRpYWwgc3RlcHMgd2hlbiB0aGV5DQogICBw dWJsaXNoZWQgdGhlaXIgZmlyc3QgcnVsaW5nIG9uIHRoZSB1c2Ugb2YgVFYgd2hpdGUgc3BhY2Us IGFuZCB0aGVuDQogICBmb2xsb3dlZCBpdCB1cCB3aXRoIGEgZmluYWwgcnVsaW5nIGluIDIwMTAg W0ZDQyBSdWxpbmddLiAgRmlubGFuZA0KICAgcGFzc2VkIGFuIEFjdCBpbiAyMDA5IGVuYWJsaW5n IHRlc3Rpbmcgb2YgY29nbml0aXZlIHJhZGlvIHN5c3RlbXMgaW4NCiAgIHRoZSBUViB3aGl0ZSBz cGFjZS4gIFRoZSBFQ0MgaGFzIGNvbXBsZXRlZCBSZXBvcnQgMTU5IFtFQ0MgUmVwb3J0DQogICAx NTldIGNvbnRhaW5pbmcgcmVxdWlyZW1lbnRzIGZvciBvcGVyYXRpb24gb2YgY29nbml0aXZlIHJh ZGlvIHN5c3RlbXMNCiAgIGluIHRoZSBUViB3aGl0ZSBzcGFjZS4gIE9mY29tIHB1Ymxpc2hlZCBp biAyMDA0IHRoZWlyIFNwZWN0cnVtDQogICBGcmFtZXdvcmsgUmV2aWV3IFtTcGVjdHJ1bSBGcmFt ZXdvcmsgUmV2aWV3XSBhbmQgdGhlaXIgRGlnaXRhbA0KICAgRGl2aWRlbmQgUmV2aWV3IFtERFJd IGluIDIwMDUsIGFuZCBoYXZlIGZvbGxvd2VkIHVwIHdpdGggYSBwcm9wb3NhbA0KICAgdG8gYWNj ZXNzIFRWIHdoaXRlIHNwYWNlLiAgTW9yZSBjb3VudHJpZXMgYXJlIGV4cGVjdGVkIHRvIHByb3Zp ZGUNCiAgIGFjY2VzcyB0byB0aGVpciBUViBzcGVjdHJ1bSBpbiBzaW1pbGFyIHdheXMuICBBbnkg ZW50aXR5IGhvbGRpbmcNCiAgIHNwZWN0cnVtIHRoYXQgaXMgbm90IGRlbnNlbHkgdXNlZCBtYXkg YmUgYXNrZWQgdG8gZ2l2ZSBpdCB1cCBpbiBvbmUNCiAgIHdheSBvciBhbm90aGVyIGZvciBtb3Jl IGludGVuc2l2ZSB1c2UuICBQcm92aWRpbmcgYSBtZWNoYW5pc20gYnkNCiAgIHdoaWNoIHNlY29u ZGFyeSB1c2VycyBzaGFyZSB0aGUgc3BlY3RydW0gd2l0aCB0aGUgcHJpbWFyeSB1c2VyIGlzDQog ICBhdHRyYWN0aXZlIGluIG1hbnkgYmFuZHMgaW4gbWFueSBjb3VudHJpZXMuDQoNCg0KDQoNClBy b2Jhc2NvICYgUGF0aWwgICAgICAgICAgRXhwaXJlcyBKdWx5IDE4LCAyMDEyICAgICAgICAgICAg ICAgICBbUGFnZSA0XQ0KDQpJbnRlcm5ldC1EcmFmdCAgICBQQVdTOiBQcm9ibGVtLCB1c2VzIGFu ZCByZXF1aXJlbWVudHMgICAgICBKYW51YXJ5IDIwMTINCg0KDQogICBUZWxldmlzaW9uIHRyYW5z bWlzc2lvbiB1bnRpbCBub3cgaGFzIHByaW1hcmlseSBiZWVuIGFuYWxvZy4gIFRoZQ0KICAgc3dp dGNoIHRvIGRpZ2l0YWwgdHJhbnNtaXNzaW9uIGhhcyBiZWd1bi4gIEFzIGEgcmVzdWx0IHRoZSBz cGVjdHJ1bQ0KICAgYWxsb2NhdGVkIGZvciB0ZWxldmlzaW9uIHRyYW5zbWlzc2lvbiBjYW4gbm93 IGJlIG1vcmUgZWZmZWN0aXZlbHkNCiAgIHVzZWQuICBVbnVzZWQgY2hhbm5lbHMgYW5kIGJhbmRz IGJldHdlZW4gY2hhbm5lbHMgY2FuIGJlIHVzZWQgYXMgbG9uZw0KICAgYXMgdGhleSBkbyBub3Qg aW50ZXJmZXJlIHdpdGggdGhlIHByaW1hcnkgc2VydmljZSBmb3Igd2hpY2ggdGhhdA0KICAgY2hh bm5lbCBpcyBhbGxvY2F0ZWQuICBXaGlsZSB1cmJhbiBhcmVhcyB0ZW5kIHRvIGhhdmUgZGVuc2Ug dXNhZ2Ugb2YNCiAgIHNwZWN0cnVtIGFuZCBhIG51bWJlciBvZiBUViBjaGFubmVscywgdGhlIHNh bWUgaXMgbm90IHRydWUgaW4gcnVyYWwNCiAgIGFuZCBzZW1pLXVyYmFuIGFyZWFzLiAgVGhlcmUg Y2FuIGJlIGEgbnVtYmVyIG9mIHVudXNlZCBUViBjaGFubmVscyBpbg0KICAgc3VjaCBhcmVhcyB0 aGF0IGNhbiBiZSB1c2VkIGZvciBvdGhlciBzZXJ2aWNlcy4gIFRoZSBmaWd1cmUgYmVsb3cNCiAg IHNob3dzIFRWIHdoaXRlIHNwYWNlIHdpdGhpbiB0aGUgbG93ZXIgVUhGIGJhbmQ6DQoNCg0KICAg ICAgICBBdmcgIHwNCiAgICAgICAgdXNhZ2V8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 LS0tLS0tLS0tLS0tLS0gV2hpdGUgU3BhY2UNCiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICB8ICAgIHwgICB8ICAgfCAgfA0KICAgICAgICAgIDAuNnwgICAgICAgICAgICAgICAgICAg fHwgICAgfHwgIFYgICBWICB8fA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfHwg ICB8fHwgICAgfCAgICB8fA0KICAgICAgICAgIDAuNHwgICAgICAgICAgICAgICAgICAgfHwgICB8 fHx8ICAgfCAgICB8fA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgfHwgICB8fHx8 ICAgfCAgICB8fDwtLS0tVFYgdHJhbnNtaXNzaW9uDQogICAgICAgICAgMC4yfCAgICAgICAgICAg ICAgICAgICB8fCAgIHx8fHwgICB8ICAgIHx8DQogICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICA0MDAgICAgIDUwMCAgICAg ICA2MDAgICAgICA3MDAgICAgICAgODAwDQogICAgICAgICAgICAgICAgICAgICAgRnJlcXVlbmN5 IGluIE1IeiAtPg0KDQoNCg0KICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBIaWdoIGxldmVsIHZp ZXcgb2YgVFYgV2hpdGUgU3BhY2UNCg0KICAgVGhlIGZ1bmRhbWVudGFsIGlzc3VlIGlzIGhvdyB0 byBkZXRlcm1pbmUgZm9yIGEgc3BlY2lmaWMgbG9jYXRpb24gYW5kDQogICBzcGVjaWZpYyB0aW1l IGlmIGFueSBvZiB0aGUgc3BlY3RydW0gaXMgYXZhaWxhYmxlIGZvciBzZWNvbmRhcnkgdXNlLg0K ICAgVGhlcmUgYXJlIHR3byBkaW1lbnNpb25zIG9mIHVzZSB0aGF0IG1heSBiZSBpbnRlcmVzdGlu Zzogc3BhY2UgKHRoZQ0KICAgYXJlYSBpbiB3aGljaCBhIHNlY29uZGFyeSB1c2VyIHdvdWxkIG5v dCBpbnRlcmZlcmUgd2l0aCBhIHByaW1hcnkNCiAgIHVzZXIsIGFuZCB0aW1lOiB3aGVuIHRoZSBz ZWNvbmRhcnkgdXNlIHdvdWxkIG5vdCBpbnRlcmZlcmUgd2l0aCB0aGUNCiAgIHByaW1hcnkgdXNl LiAgSW4gdGhpcyBkaXNjdXNzaW9uLCB3ZSBjb25zaWRlciB0aGUgdGltZSBlbGVtZW50IHRvIGJl DQogICByZWxhdGl2ZWx5IGxvbmcgdGVybSAoaG91cnMgaW4gYSBkYXkpIHJhdGhlciB0aGFuIHNo b3J0IHRlcm0NCiAgIChmcmFjdGlvbnMgb2YgYSBzZWNvbmQpLiAgTG9jYXRpb24gaW4gdGhpcyBk aXNjdXNzaW9uIGlzIGdlb2xvY2F0aW9uOg0KICAgd2hlcmUgdGhlIHRyYW5zbWl0dGVycyAoYW5k IHNvbWV0aW1lcyByZWNlaXZlcnMpIGFyZSBsb2NhdGVkIHJlbGF0aXZlDQogICB0byBvbmUgYW5v dGhlci4gIEluIG9wZXJhdGlvbiwgdGhlIGRhdGFiYXNlIHJlY29yZHMgdGhlIGV4aXN0aW5nDQog ICB1c2VyJ3MgdHJhbnNtaXR0ZXIgKGFuZCBzb21lIHRpbWVzIHJlY2VpdmVyKSBsb2NhdGlvbnMg YWxvbmcgd2l0aA0KICAgYmFzaWMgdHJhbnNtaXNzaW9uIGNoYXJhY3RlcmlzdGljcyBzdWNoIGFz IGFudGVubmEgaGVpZ2h0LCBhbmQNCiAgIHNvbWV0aW1lcyBwb3dlci4gIFVzaW5nIHJ1bGVzIGVz dGFibGlzaGVkIGJ5IHRoZSByZWd1bGF0b3IsIHRoZQ0KICAgZGF0YWJhc2UgY2FsY3VsYXRlcyBh biBleGNsdXNpb24gem9uZSBmb3IgZWFjaCBhdXRob3JpemVkIHByaW1hcnkNCiAgIHVzZXIsIGFu ZCBhdHRhY2hlcyBhIHRpbWUgc2NoZWR1bGUgdG8gdGhhdCB1c2UuICBUaGUgc2Vjb25kYXJ5IHVz ZXINCiAgIHF1ZXJpZXMgdGhlIGRhdGFiYXNlIHdpdGggaXRzIGxvY2F0aW9uLiAgVGhlIGRhdGFi YXNlIGludGVyc2VjdHMgdGhlDQogICBleGNsdXNpb24gem9uZXMgd2l0aCB0aGUgcXVlcmllZCBs b2NhdGlvbiwgYW5kIHJldHVybnMgdGhlIHBvcnRpb24gb2YNCiAgIHRoZSBzcGVjdHJ1bSBub3Qg aW4gYW55IGV4Y2x1c2lvbiB6b25lLiAgU3VjaCBtZXRob2RzIG9mIGdlb3NwYXRpYWwNCiAgIGRh dGFiYXNlIHF1ZXJ5IHRvIGF2b2lkIGludGVyZmVyZW5jZSBoYXZlIGJlZW4gc2hvd24gdG8gYWNo aWV2ZQ0KICAgZmF2b3JhYmxlIHJlc3VsdHMsIGFuZCBhcmUgdGh1cyB0aGUgYmFzaXMgZm9yIHJ1 bGluZ3MgYnkgdGhlIEZDQyBhbmQNCg0KDQoNClByb2Jhc2NvICYgUGF0aWwgICAgICAgICAgRXhw aXJlcyBKdWx5IDE4LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDQpJbnRlcm5ldC1E cmFmdCAgICBQQVdTOiBQcm9ibGVtLCB1c2VzIGFuZCByZXF1aXJlbWVudHMgICAgICBKYW51YXJ5 IDIwMTINCg0KDQogICByZXBvcnRzIGZyb20gRUNDIGFuZCBPZmNvbS4gIEluIGFueSBjb3VudHJ5 LCB0aGUgcnVsZXMgZm9yIHdoaWNoDQogICBwcmltYXJ5IGVudGl0aWVzIGFyZSBlbnRpdGxlZCB0 byBwcm90ZWN0aW9uLCBob3cgdGhlIGV4Y2x1c2lvbiB6b25lcw0KICAgYXJlIGNhbGN1bGF0ZWQs IGFuZCB3aGF0IHRoZSBsaW1pdHMgb2YgdXNlIGJ5IHNlY29uZGFyeSBlbnRpdGllcyBhcmUNCiAg IG1heSB2YXJ5LiAgSG93ZXZlciwgdGhlIGZ1bmRhbWVudGFsIG5vdGlvbiBvZiByZWNvcmRpbmcg cHJpbWFyeQ0KICAgdXNlcnMsIGNhbGN1bGF0aW5nIGV4Y2x1c2lvbiB6b25lcywgcXVlcnlpbmcg YnkgbG9jYXRpb24gYW5kDQogICByZXR1cm5pbmcgYXZhaWxhYmxlIHNwZWN0cnVtIChhbmQgdGhl IHNjaGVkdWxlIGZvciB0aGF0IHNwZWN0cnVtKSBhcmUNCiAgIGNvbW1vbg0KDQogICBUaGlzIGRv Y3VtZW50IGluY2x1ZGVzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgdXNlIGNhc2VzIGFuZA0KICAg cmVxdWlyZW1lbnRzIGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIHdoaXRlIHNwYWNlIHNwZWN0 cnVtIGJ5DQogICBzZWNvbmRhcnkgdXNlcnMgdmlhIGEgZGF0YWJhc2UgcXVlcnkgcHJvdG9jb2wu DQoNCjEuMi4gIFNjb3BlDQoNCjEuMi4xLiAgSW4gU2NvcGUNCg0KICAgVGhpcyBkb2N1bWVudCBh cHBsaWVzIG9ubHkgdG8gY29tbXVuaWNhdGlvbnMgcmVxdWlyZWQgZm9yIGJhc2ljDQogICBzZXJ2 aWNlIGluIFRWIHdoaXRlIHNwYWNlLiAgVGhlIHByb3RvY29sIHdpbGwgZW5hYmxlIGEgd2hpdGUg c3BhY2UNCiAgIHJhZGlvIGRldmljZSB0byBjb21wbGV0ZSB0aGUgZm9sbG93aW5nIHRhc2tzOg0K DQogICAxLiAgRGV0ZXJtaW5lIHRoZSByZWxldmFudCB3aGl0ZSBzcGFjZSBkYXRhYmFzZSB0byBx dWVyeS4NCg0KICAgMi4gIENvbm5lY3QgdG8gdGhlIGRhdGFiYXNlIHVzaW5nIGEgd2VsbC1kZWZp bmVkIGFjY2VzcyBtZXRob2QuDQoNCiAgIDMuICBSZWdpc3RlciB3aXRoIHRoZSBkYXRhYmFzZSB1 c2luZyBhIHdlbGwtZGVmaW5lZCBwcm90b2NvbC4NCg0KICAgNC4gIFByb3ZpZGUgaXRzIGdlb2xv Y2F0aW9uIGFuZCBwZXJoYXBzIG90aGVyIGRhdGEgdG8gdGhlIGRhdGFiYXNlDQogICAgICAgdXNp bmcgYSB3ZWxsLWRlZmluZWQgZm9ybWF0IGZvciBxdWVyeWluZyB0aGUgZGF0YWJhc2UuDQoNCiAg IDUuICBSZWNlaXZlIGluIHJldHVybiBhIGxpc3Qgb2YgY3VycmVudGx5IGF2YWlsYWJsZSB3aGl0 ZSBzcGFjZSB1c2luZw0KICAgICAgIGEgd2VsbC1kZWZpbmVkIGZvcm1hdCBmb3IgcmV0dXJuaW5n IGluZm9ybWF0aW9uLg0KDQogICBBcyBhIHJlc3VsdCwgc29tZSBvZiB0aGUgc2NlbmFyaW9zIGRl c2NyaWJlZCBpbiB0aGUgZm9sbG93aW5nIHNlY3Rpb24NCiAgIGFyZSBvdXQgb2Ygc2NvcGUgZm9y IHRoaXMgc3BlY2lmaWNhdGlvbiAoYWx0aG91Z2ggdGhleSBtaWdodCBiZQ0KICAgYWRkcmVzc2Vk IGJ5IGZ1dHVyZSBzcGVjaWZpY2F0aW9ucykuDQoNCjEuMi4yLiAgT3V0IG9mIFNjb3BlDQoNCiAg IFRoZSBmb2xsb3dpbmcgdG9waWNzIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNh dGlvbjoNCg0KICAgVEJEDQoNCg0KMi4gIENvbnZlbnRpb25zIGFuZCBUZXJtaW5vbG9neQ0KDQoN Cg0KDQoNCg0KDQpQcm9iYXNjbyAmIFBhdGlsICAgICAgICAgIEV4cGlyZXMgSnVseSAxOCwgMjAx MiAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCg0KSW50ZXJuZXQtRHJhZnQgICAgUEFXUzogUHJv YmxlbSwgdXNlcyBhbmQgcmVxdWlyZW1lbnRzICAgICAgSmFudWFyeSAyMDEyDQoNCg0KMi4xLiAg Q29udmVudGlvbnMgVXNlZCBpbiBUaGlzIERvY3VtZW50DQoNCiAgIFRoZSBrZXkgd29yZHMgIk1V U1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJT SE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFM IiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIFJGQyAyMTE5IFtSRkMyMTE5XS4NCg0KMi4yLiAgVGVybWlub2xvZ3kNCg0KICAgRGF0YWJh c2UNCg0KICAgICAgSW4gdGhlIGNvbnRleHQgb2Ygd2hpdGUgc3BhY2UgYW5kIGNvZ25pdGl2ZSBy YWRpbyB0ZWNobm9sb2dpZXMsDQogICAgICB0aGUgZGF0YWJhc2UgaXMgYW4gZW50aXR5IHdoaWNo IGNvbnRhaW5zIGN1cnJlbnQgaW5mb3JtYXRpb24gYWJvdXQNCiAgICAgIGF2YWlsYWJsZSBzcGVj dHJ1bSBhdCBhbnkgZ2l2ZW4gbG9jYXRpb24gYW5kIG90aGVyIHR5cGVzIG9mDQogICAgICBpbmZv cm1hdGlvbi4NCg0KICAgRGV2aWNlIElEDQoNCiAgICAgIEEgdW5pcXVlIG51bWJlciBmb3IgZWFj aCBtYXN0ZXIgZGV2aWNlIGFuZCBzbGF2ZSBkZXZpY2UgdGhhdA0KICAgICAgaWRlbnRpZmllcyB0 aGUgbWFudWZhY3R1cmVyLCBtb2RlbCBudW1iZXIgYW5kIHNlcmlhbCBudW1iZXIuDQoNCiAgIExv Y2F0aW9uIEJhc2VkIFNlcnZpY2UNCg0KICAgICAgQW4gYXBwbGljYXRpb24gb3IgZGV2aWNlIHdo aWNoIHByb3ZpZGVzIGRhdGEsIGluZm9ybWF0aW9uIG9yDQogICAgICBzZXJ2aWNlIHRvIGEgdXNl ciBiYXNlZCBvbiB0aGVpciBsb2NhdGlvbi4NCg0KICAgTWFzdGVyIERldmljZQ0KDQogICAgICBB IGRldmljZSB3aGljaCBxdWVyaWVzIHRoZSBXUyBEYXRhYmFzZSB0byBmaW5kIG91dCB0aGUgYXZh aWxhYmxlDQogICAgICBvcGVyYXRpbmcgY2hhbm5lbHMuDQoNCiAgIFByb3RlY3RlZCBFbnRpdHkN Cg0KICAgICAgQSBwcmltYXJ5IHVzZXIgb2Ygd2hpdGUgc3BhY2Ugc3BlY3RydW0gd2hpY2ggaXMg YWZmb3JkZWQNCiAgICAgIHByb3RlY3Rpb24gYWdhaW5zdCBpbnRlcmZlcmVuY2UgYnkgc2Vjb25k YXJ5IHVzZXJzICh3aGl0ZSBzcGFjZQ0KICAgICAgZGV2aWNlcykgZm9yIGl0cyB1c2UgaW4gYSBn aXZlbiBhcmVhIGFuZCB0aW1lLg0KDQogICBQcm90ZWN0ZWQgQ29udG91cg0KDQogICAgICBUaGUg ZXhjbHVzaW9uIGFyZWEgZm9yIGEgUHJvdGVjdGVkIEVudGl0eSwgaGVsZCBpbiB0aGUgZGF0YWJh c2UNCiAgICAgIGFuZCBleHByZXNzZWQgYXMgYSBwb2x5Z29uIHdpdGggZ2Vvc3BhdGlhbCBwb2lu dHMgYXMgdGhlIHZlcnRpY2VzLg0KDQogICBTbGF2ZSBEZXZpY2UNCg0KICAgICAgQSBkZXZpY2Ug d2hpY2ggdXNlcyB0aGUgc3BlY3RydW0gbWFkZSBhdmFpbGFibGUgYnkgYSBtYXN0ZXINCiAgICAg IGRldmljZS4NCg0KDQoNCg0KDQoNClByb2Jhc2NvICYgUGF0aWwgICAgICAgICAgRXhwaXJlcyBK dWx5IDE4LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDQpJbnRlcm5ldC1EcmFmdCAg ICBQQVdTOiBQcm9ibGVtLCB1c2VzIGFuZCByZXF1aXJlbWVudHMgICAgICBKYW51YXJ5IDIwMTIN Cg0KDQogICBUViBXaGl0ZSBTcGFjZQ0KDQogICAgICBUViB3aGl0ZSBzcGFjZSByZWZlcnMgc3Bl Y2lmaWNhbGx5IHRvIHJhZGlvIHNwZWN0cnVtIHdoaWNoIGhhcw0KICAgICAgYmVlbiBhbGxvY2F0 ZWQgZm9yIFRWIGJyb2FkY2FzdCwgYnV0IGlzIG5vdCBvY2N1cGllZCBieSBhIFRWDQogICAgICBi cm9hZGNhc3QsIG9yIG90aGVyIGxpY2Vuc2VkIHVzZXIgKHN1Y2ggYXMgYSB3aXJlbGVzcyBtaWNy b3Bob25lKSwNCiAgICAgIGF0IGEgc3BlY2lmaWMgbG9jYXRpb24gYW5kIHRpbWUuDQoNCiAgIFdo aXRlIFNwYWNlDQoNCiAgICAgIFJhZGlvIHNwZWN0cnVtIHdoaWNoIGhhcyBiZWVuIGFsbG9jYXRl ZCBmb3Igc29tZSBwcmltYXJ5IHVzZSwgYnV0DQogICAgICBpcyBub3QgZnVsbHkgb2NjdXBpZWQg YnkgdGhhdCBwcmltYXJ5IHVzZSBhdCBhIHNwZWNpZmljIGxvY2F0aW9uDQogICAgICBhbmQgdGlt ZS4NCg0KICAgV2hpdGUgU3BhY2UgRGV2aWNlIChXU0QpDQoNCiAgICAgIEEgZGV2aWNlIHdoaWNo IGlzIGEgc2Vjb25kYXJ5IHVzZXIgb2Ygc29tZSBwYXJ0IG9mIHdoaXRlIHNwYWNlDQogICAgICBz cGVjdHJ1bS4gIEEgd2hpdGUgc3BhY2UgZGV2aWNlIGNhbiBiZSBhbiBhY2Nlc3MgcG9pbnQsIGJh c2UNCiAgICAgIHN0YXRpb24sIGEgcG9ydGFibGUgZGV2aWNlIG9yIHNpbWlsYXIuICBJbiB0aGlz IGNvbnRleHQsIGEgd2hpdGUNCiAgICAgIHNwYWNlIGRldmljZSBpcyByZXF1aXJlZCB0byBxdWVy eSBhIGRhdGFiYXNlIHdpdGggaXRzIGxvY2F0aW9uIHRvDQogICAgICBvYnRhaW4gaW5mb3JtYXRp b24gYWJvdXQgYXZhaWxhYmxlIHNwZWN0cnVtLg0KDQoNCjMuICBQcmlvciBXb3JrDQoNCjMuMS4g IFRoZSBjb25jZXB0IG9mIENvZ25pdGl2ZSBSYWRpbw0KDQogICBBIGNvZ25pdGl2ZSByYWRpbyB1 c2VzIGtub3dsZWRnZSBvZiB0aGUgbG9jYWwgcmFkaW8gZW52aXJvbm1lbnQgdG8NCiAgIGR5bmFt aWNhbGx5IGFkYXB0IGl0cyBvd24gY29uZmlndXJhdGlvbiBhbmQgZnVuY3Rpb24gcHJvcGVybHkg aW4gYQ0KICAgY2hhbmdpbmcgcmFkaW8gZW52aXJvbm1lbnQuICBLbm93bGVkZ2Ugb2YgdGhlIGxv Y2FsIHJhZGlvIGVudmlyb25tZW50DQogICBjYW4gY29tZSBmcm9tIHZhcmlvdXMgdGVjaG5vbG9n eSBtZWNoYW5pc21zIGluY2x1ZGluZyBzZW5zaW5nDQogICAoYXR0ZW1wdGluZyB0byBhc2NlcnRh aW4gcHJpbWFyeSB1c2VycyBieSBsaXN0ZW5pbmcgZm9yIHRoZW0gd2l0aGluDQogICB0aGUgc3Bl Y3RydW0pLCBsb2NhdGlvbiBkZXRlcm1pbmF0aW9uIGFuZCBpbnRlcm5ldCBjb25uZWN0aXZpdHkg dG8gYQ0KICAgZGF0YWJhc2UgdG8gbGVhcm4gdGhlIGRldGFpbHMgb2YgdGhlIGxvY2FsIHJhZGlv IGVudmlyb25tZW50LiAgVFYNCiAgIFdoaXRlIFNwYWNlIGlzIG9uZSBpbXBsZW1lbnRhdGlvbiBv ZiBjb2duaXRpdmUgcmFkaW8uICBCZWNhdXNlIGENCiAgIGNvZ25pdGl2ZSByYWRpbyBhZGFwdHMg aXRzZWxmIHRvIHRoZSBhdmFpbGFibGUgc3BlY3RydW0gaW4gYSBtYW5uZXINCiAgIHRoYXQgcHJl dmVudHMgdGhlIGNyZWF0aW9uIG9mIGhhcm1mdWwgaW50ZXJmZXJlbmNlLCB0aGUgc3BlY3RydW0g Y2FuDQogICBiZSBzaGFyZWQgYW1vbmcgZGlmZmVyZW50IHJhZGlvIHVzZXJzLg0KDQozLjIuICBC YWNrZ3JvdW5kIGluZm9ybWF0aW9uIG9uIHdoaXRlIHNwYWNlIGluIFVTDQoNCiAgIFRlbGV2aXNp b24gdHJhbnNtaXNzaW9uIGluIHRoZSBVbml0ZWQgU3RhdGVzIGhhcyBtb3ZlZCB0byB0aGUgdXNl IG9mDQogICBkaWdpdGFsIHNpZ25hbHMgYXMgb2YgSnVuZSAxMiwgMjAwOS4gIFNpbmNlIEp1bmUg MTMsIDIwMDksIGFsbCBmdWxsLQ0KICAgcG93ZXIgVS5TLiB0ZWxldmlzaW9uIHN0YXRpb25zIGhh dmUgYnJvYWRjYXN0IG92ZXItdGhlLWFpciBzaWduYWxzIGluDQogICBkaWdpdGFsIG9ubHkuICBB biBpbXBvcnRhbnQgYmVuZWZpdCBvZiB0aGUgc3dpdGNoIHRvIGFsbC1kaWdpdGFsDQogICBicm9h ZGNhc3RpbmcgaXMgdGhhdCBpdCBmcmVlZCB1cCBwYXJ0cyBvZiB0aGUgdmFsdWFibGUgYnJvYWRj YXN0DQogICBzcGVjdHJ1bS4gIE1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN3aXRjaCB0byBk aWdpdGFsIHRyYW5zbWlzc2lvbg0KICAgaXMgYXQgOiBbRFRWXS4NCg0KDQoNCg0KUHJvYmFzY28g JiBQYXRpbCAgICAgICAgICBFeHBpcmVzIEp1bHkgMTgsIDIwMTIgICAgICAgICAgICAgICAgIFtQ YWdlIDhdDQoNCkludGVybmV0LURyYWZ0ICAgIFBBV1M6IFByb2JsZW0sIHVzZXMgYW5kIHJlcXVp cmVtZW50cyAgICAgIEphbnVhcnkgMjAxMg0KDQoNCiAgIFdpdGggdGhlIHN3aXRjaCB0byBkaWdp dGFsIHRyYW5zbWlzc2lvbiBmb3IgVFYsIHRoZSBndWFyZCBiYW5kcyB0aGF0DQogICBleGlzdGVk IHRvIHByb3RlY3QgdGhlIHNpZ25hbHMgYmV0d2VlbiBzdGF0aW9ucyBjYW4gbm93IGJlIHVzZWQg Zm9yDQogICBvdGhlciBwdXJwb3Nlcy4gIFRoZSBGQ0MgaGFzIG1hZGUgdGhpcyBzcGVjdHJ1bSBh dmFpbGFibGUgZm9yDQogICB1bmxpY2Vuc2VkIHVzZSBhbmQgdGhpcyBpcyBnZW5lcmFsbHkgcmVm ZXJyZWQgdG8gYXMgd2hpdGUgc3BhY2UuDQogICBQbGVhc2Ugc2VlIHRoZSBkZXRhaWxzIG9mIHRo ZSBGQ0MgcnVsaW5nIGFuZCByZWd1bGF0aW9ucyBpbiBbRkNDDQogICBSdWxpbmddLiAgVGhlIHNw ZWN0cnVtIGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgd2lyZWxlc3MgYnJvYWRiYW5kIGFzDQogICBh biBleGFtcGxlLiAgVGhlIHRlcm0gIlN1cGVyLVdpZmkiIGlzIGFsc28gdXNlZCB0byBkZXNjcmli ZSB0aGlzDQogICBzcGVjdHJ1bSBhbmQgcG90ZW50aWFsIGZvciBwcm92aWRpbmcgd2lmaSB0eXBl IG9mIHNlcnZpY2UuDQoNCjMuMy4gIEFpciBJbnRlcmZhY2VzDQoNCiAgIEVmZm9ydHMgYXJlIG9u Z29pbmcgdG8gc3BlY2lmeSBhaXItaW50ZXJmYWNlcyBmb3IgdXNlIGluIHdoaXRlIHNwYWNlDQog ICBzcGVjdHJ1bS4gIElFRUVzIDgwMi4xMWFmIHRhc2sgZ3JvdXAgaXMgY3VycmVudGx5IHdvcmtp bmcgb24gb25lIHN1Y2gNCiAgIHNwZWNpZmljYXRpb24uICBJRUVFIDgwMi4yMiBpcyBhbm90aGVy IGV4YW1wbGUuICBPdGhlciBhaXIgaW50ZXJmYWNlcw0KICAgY291bGQgYmUgc3BlY2lmaWVkIGlu IHRoZSBmdXR1cmUgc3VjaCBhcyBMVEUuDQoNCg== From scott.probasco@nokia.com Wed Jan 25 13:02:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ADB21F8582 for ; Wed, 25 Jan 2012 13:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.855, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlvuSFaVi7Zz for ; Wed, 25 Jan 2012 13:02:35 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0C721F8577 for ; Wed, 25 Jan 2012 13:02:35 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0PL2XRk015646 for ; Wed, 25 Jan 2012 23:02:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 23:02:32 +0200 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.241]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Wed, 25 Jan 2012 22:02:32 +0100 From: To: Thread-Topic: Use cases and requirements I-D: Section 5 Problem Statement Thread-Index: AQHM26SnENJw6c6ZxkOX+mR68oSoNw== Date: Wed, 25 Jan 2012 21:02:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <915A734A765B324188E05E7ADDEB760F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2012 21:02:32.0911 (UTC) FILETIME=[A82665F0:01CCDBA4] X-Nokia-AV: Clean Subject: [paws] Use cases and requirements I-D: Section 5 Problem Statement X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:02:36 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section 5. This text has not changed from version-01 as uploaded October 31, 2011. Our goal is that any discussion on this text will conclude by February 1. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 5. Problem Statement The use of white space spectrum is enabled via the capability of a device to query a database and obtain information about the availability of spectrum for use at a given location. The databases are reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be country independent. An example high-level architecture of the devices and white space databases is shown in the figure below: Probasco & Patil Expires July 18, 2012 [Page 24] Internet-Draft PAWS: Problem, uses and requirements January 2012 ----------- |WS Device| ------------ |Lat: X |\ .---. /--------|Database X| |Long: Y | \ ( ) / ------------ ----------- \-------/ \/ o ( Internet ) o ----------- /------( )\ o |WS Device| / (_____) \ ------------ |Lat: X |/ \--------|Database Y| |Long: Y | ------------ ----------- Figure 11: High level view of the White space database architecture In the figure above, note that there could be multiple databases serving white space devices. The databases are country specific since the regulations and available spectrum may vary. In some countries, for example, the U.S., the regulator has determined that multiple, competing databases may provide service to White Space Devices. A messaging interface between the white space devices and the database is required for operating a network using the white space spectrum. The following sections discuss various aspects of such an interface and the need for a standard. Other aspects of a solution including provisioning the database, and calculating protected contours are considered out of scope of the initial effort, as there are significant differences between countries and spectrum bands. 5.1. Global applicability The use of TV white space spectrum is currently approved by the FCC in the United States. However regulatory bodies in other countries are also considering similar use of available spectrum. The principles of cognitive radio usage for such spectrum is generally the same. Some of the regulatory details may vary on a country specific basis. However the need for devices that intend to use the spectrum to communicate with a database remains a common feature. The database provides a known, specifiable Protection Contour for the primary user, not dependent on the characteristics of the White Space Device or it's ability to sense the primary use. It also provides a way to specify a schedule of use, because some primary users (for example, wireless microphones) only operate in limited time slots. Devices need to be able to query a database, directly or indirectly over the public Internet and/or private IP networks prior to operating in available spectrum. Information about available Probasco & Patil Expires July 18, 2012 [Page 25] Internet-Draft PAWS: Problem, uses and requirements January 2012 spectrum, schedule, power, etc. are provided by the database as a response to the query from a device. The messaging interface needs to be: 1. Radio/air interface agnostic - The radio/air interface technology used by the white space device in available spectrum can be 802.11af, 802.16, 802.22, LTE etc. However the messaging interface between the white space device and the database should be agnostic to the air interface while being cognizant of the characteristics of various air-interface technologies and the need to include relevant attributes in the query to the database. 2. Spectrum agnostic - the spectrum used by primary and secondary users varies by country. Some spectrum has an explicit notion of a "channel" a defined swath of spectrum within a band that has some assigned identifier. Other spectrum bands may be subject to white space sharing, but only have actual frequency low/high parameters to define protected entity use. The protocol should be able to be used in any spectrum band where white space sharing is permitted. 3. Globally applicable - A common messaging interface between white space devices and databases will enable the use of such spectrum for various purposes on a global basis. Devices can operate in any country where such spectrum is available and a common interface ensures uniformity in implementations and deployment. Since the White Space device must know it's geospatial location to do a query, it is possible to determine which database, and which rules, are applicable, even though they are country specific. 4. Address regulatory requirements - Each country will likely have regulations that are unique to that country. The messaging interface needs to be flexible to accommodate the specific needs of a regulatory body in the country where the white space device is operating and connecting to the relevant database. 5.2. Database discovery Another aspect of the problem space is the need to discover the database. A white space device needs to find the relevant database to query based on its current location or for another location. Since the spectrum and databases are country specific, the device will need to discover the relevant database. The device needs to obtain the IP address of the specific database to which it can send queries in addition to registering itself for operation and using the available spectrum. Probasco & Patil Expires July 18, 2012 [Page 26] Internet-Draft PAWS: Problem, uses and requirements January 2012 5.3. Protocol A protocol that enables a white space device to query a database to obtain information about available channels is needed. A device may be required to register with the database with some credentials prior to being allowed to query. The requirements for such a protocol are specified in this document. 5.4. Data model definition The contents of the queries and response need to be specified. A data model is required which enables the white space device to query the database while including all the relevant information such as geolocation, radio technology, power characteristics, etc. which may be country and spectrum and regulatory dependent. All databases are able to interpret the data model and respond to the queries using the same data model that is understood by all devices. Use of XML for specifying a data model is an attractive option. The intent is to evaluate the best option that meets the need for use between white space devices and databases. From Basavaraj.Patil@nokia.com Wed Jan 25 13:12:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0779021F8618 for ; Wed, 25 Jan 2012 13:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSBe0asoBjOZ for ; Wed, 25 Jan 2012 13:11:59 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9C89421F8613 for ; Wed, 25 Jan 2012 13:11:58 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0PLBrhK023173; Wed, 25 Jan 2012 23:11:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jan 2012 23:11:52 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.244]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Wed, 25 Jan 2012 22:11:51 +0100 From: To: , Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCwDCefoAADnTZRD///wWAA== Date: Wed, 25 Jan 2012 21:11:51 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414060BB50DF@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: multipart/related; boundary="_004_CB45CBEA18765basavarajpatilnokiacom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jan 2012 21:11:52.0627 (UTC) FILETIME=[F5C44830:01CCDBA5] X-Nokia-AV: Clean Subject: Re: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:12:01 -0000 --_004_CB45CBEA18765basavarajpatilnokiacom_ Content-Type: multipart/alternative; boundary="_000_CB45CBEA18765basavarajpatilnokiacom_" --_000_CB45CBEA18765basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the clarification. I guess it is important to point out in the use case that the slave devices= are listening to a beacon from a master device (as an example at least) an= d the loss of such a beacon would result in communications that may be dire= ctly between slaves ceasing immediately. -Raj From: "andy.sago@bt.com" > Date: Wed, 25 Jan 2012 15:06:52 +0000 To: Basavaraj Patil >, "paws@ietf.org" > Subject: RE: [paws] Clarification of M2M use case Hi Raj The master doesn=92t need to know that slaves are talking direct, and traff= ic is not routed through the master. Each slave is within range of the mast= er, and associated to it. A command from the master to tell slaves stop TVW= S communications on the current channel (if such a protocol is developed) w= ould be received by all slaves and acted upon. This would apply to slave-sl= ave transmissions as well as slave-master transmissions since they are both= using TVWS. Alternatively if the master dropped comms (stopped beaconing o= r whatever) then both slaves could detect that, and the default action then= would be to cease all transmissions over the air, to the master or to othe= r slaves. Thus, the direct slave-slave transmissions are under control of t= he master in so far as the master decides whether all slaves can transmit o= r not, based on information from the database. I don=92t think there is any= thing extra needed wrt PAWS protocols to enable this. The scenario is similar if the master is allocated a choice of channels by = the database, and the list is passed to the slave. I suppose the master cou= ld make itself known on channel A, and slaves associate on channel A and ar= e told that channels B and C are also available (at particular powers etc).= They then use B and C for direct slave-slave comms. If the database indica= tes (by push or pull) a revised list of channels to the master, with channe= l A still usable but B or C not, then the changed list of frequencies shoul= d be signalled to the slave. This could result in a change of frequency by = the slave, rather than a ceasing of all transmissions, and the existing net= work on channel A would be unaffected. The previous paragraph is just a theoretical exercise, I don=92t see any re= ason why slave-slave comms would use a different channel to slave-master c= omms in the M2M use case, but don=92t see any reason to prevent it. Regards Andy From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: 24 January 2012 17:50 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] Clarification of M2M use case Hi Andy, Question about the following statement: " Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost " How does the master know that slaves are communicating with each other dire= ctly using TVWS channels? Do you assume that communication between slaves i= s routed through the master? -Raj From: "andy.sago@bt.com" > Date: Fri, 20 Jan 2012 14:01:32 +0000 To: "paws@ietf.org" > Subject: [paws] Clarification of M2M use case All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The =93Note= =94 on the slide now has two bullets and reads: =B7 Note: Further signalling can take place (outside the scope of P= AWS) to establish direct links among those slave devices that have associat= ed with the master device. =B7 Machine communication over a TVWS channel, whether to a master = device or to another machine (slave device), is under the control of the ma= ster device, and would cease if so requested by the master, or if connectio= n to the master is lost I have also copied the revised slide here: [cid:image001.png@01CCDB6E.21499E20] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description =96 I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB45CBEA18765basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <163C21C849E5F147BDB5BA6DB3B95240@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Thanks for the clarification.
I guess it is important to point out in the use case that the slave de= vices are listening to a beacon from a master device (as an example at leas= t) and the loss of such a beacon would result in communications that may be= directly between slaves ceasing immediately.

-Raj

From: "andy.sago@bt.com" <andy.sago@bt.com>
Date: Wed, 25 Jan 2012 15:06:52 = 3;0000
To: Basavaraj Patil <basavaraj.patil@nokia.com>, "= paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Clarification o= f M2M use case

Hi Raj

 

The master doesn=92t need to know that slaves are t= alking direct, and traffic is not routed through the master. Each slave is = within range of the master, and associated to it. A command from the master to tell slaves stop TVWS communications o= n the current channel (if such a protocol is developed) would be received b= y all slaves and acted upon. This would apply to slave-slave transmissions = as well as slave-master transmissions since they are both using TVWS. Alternatively if the master dropped comms = (stopped beaconing or whatever) then both slaves could detect that, and the= default action then would be to cease all transmissions over the air, to t= he master or to other slaves. Thus, the direct slave-slave transmissions are under control of the master in so= far as the master decides whether all slaves can transmit or not, based on= information from the database. I don=92t think there is anything extra nee= ded wrt PAWS protocols to enable this.

 

The scenario is similar if the master is allocated = a choice of channels by the database, and the list is passed to the slave. = I suppose the master could make itself known on channel A, and slaves associate on channel A and are told that ch= annels B and C are also available (at particular powers etc). They then use= B and C for direct slave-slave comms. If the database indicates (by push o= r pull) a revised list of channels to the master, with channel A still usable but B or C not, then the change= d list of frequencies should be signalled to the slave. This could result i= n a change of frequency by the slave, rather than a ceasing of all transmis= sions, and the existing network on channel A would be unaffected.

 

The previous paragraph is just a theoretical exerci= se, I don=92t see any reason why slave-slave comms would use a different ch= annel  to slave-master comms in the M2M use case, but don=92t see any reason to prevent it.

 

Regards

 

Andy

 

 

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.= com]
Sent: 24 January 2012 17:50
To: Sago,AJ,Andy,COD R; paws@ietf.o= rg
Subject: Re: [paws] Clarification of M2M use case<= /p>

 

 

Hi Andy,

 

Question about the following statement:

"

Machine communicat= ion over a TVWS channel, whether to a master device or to another machine (= slave device), is under the control of the master device, and would cease if so requested by the master, or if co= nnection to the master is lost

"

 

How does the master know that slaves are co= mmunicating with each other directly using TVWS channels? Do you assume tha= t communication between slaves is routed through the master?

 

-Raj

 

From: "andy.sago@bt.co= m" <andy.sago@bt.com>= ;
Date: Fri, 20 Jan 2012 14:01:32 +0000
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] Clarification of M2M use case

 

All

 

There was a request for clarification on the M2M us= e case presented at the Taipei F2F, in particular with regard to slave-to-s= lave communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to the M2M slide to = make this clearer. We have added two arrows so that it is clear that each o= f the slaves is in communication over TVWS with the master, as well as the = slaves being in communication with each other. The =93Note=94 on the slide now has two bullets and reads:

 

=B7         Note: Further signalling can take place= (outside the scope of PAWS) to establish direct links among those slave de= vices that have associated with the master device.

=B7         Machine communication over a TVWS chann= el, whether to a master device or to another machine (slave device), is und= er the control of the master device, and would cease if so requested by the master, or if connection to the mas= ter is lost

 

I have also copied the revised slide here:

 

 

The sequence of events is as follows (note that ste= ps 1-5 are the same as in the use case description in the current working g= roup draft, but we have removed the last sentence in step 6 (previously the final step) so that this can be ex= panded in the new step 7):

 

&nbs= p;  1.  The master device powers up with its whitespace radio in = idle or

&nbs= p;      listen mode only (no active transmission o= n the whitespace

&nbs= p;      frequency band).

&nbs= p;

&nbs= p;

&nbs= p;  2.  The master device has internet connectivity and establish= es a

&nbs= p;      connection to a trusted white space databa= se (see Section 3.1

&nbs= p;      above).=

&nbs= p;

&nbs= p;  3.  The master device sends its geolocation and location unce= rtainty

&nbs= p;      information, and optionally additional inf= ormation which may

&nbs= p;      include (1) device ID and (2) antenna char= acteristics, to a

&nbs= p;      trusted database, requesting a list of ava= ilable whitespace

&nbs= p;      channels based upon this information.

&nbs= p;

&nbs= p;  4.  The database responds with a list of available white spac= e

&nbs= p;      channels that the master device may use, a= nd optional information

&nbs= p;      which may include inter alia (1) a duratio= n of time for the use<= /p>

&nbs= p;      of each channel (channel validity time) (2= ) a maximum radiated

&nbs= p;      power for each channel, (3) an indication = of the quality of the<= /p>

&nbs= p;      spectrum for each channel and (4) directiv= ity and other antenna<= /p>

&nbs= p;      information.

&nbs= p;

&nbs= p;  5.  Once the master device authenticates the whitespace chann= el list

&nbs= p;      response message from the database, the ma= ster device selects one

&nbs= p;      or more available whitespace channels from= the list.

&nbs= p;

&nbs= p;  6.  The slave devices fitted to the machines scan the TV band= s to

&nbs= p;      locate the master transmissions, and assoc= iate with the master

&nbs= p;      device. 

&nbs= p;

&nbs= p;  7.  Further signaling can take place outside scope of PAWS

&nbs= p;      to establish direct links among those slav= e devices that have

&nbs= p;      associated with the same master device. At= all times these direct

&nbs= p;      links are under the control of the ma= ster device. For example,

&nbs= p;      common to all use cases, there may be= a regulatory requirement

&nbs= p;      for transmissions from slave to maste= r to cease immediately if so

&nbs= p;      requested by the master, or if connec= tion to the master is lost

&nbs= p;      for more than a specified period of t= ime. When one of these

&nbs= p;      conditions occurs, transmissions from= slave to slave would also

&nbs= p;      cease. Direct slave to slave transmis= sions could only restart if

&nbs= p;      each slave subsequently restores its = connection to the same

&nbs= p;      master, or each slave joins the netwo= rk of another master.

 

- end of event sequence description =96

 

I hope this is now clearer. Please let me have any = further queries on the reflector.

 

To deflect one set of questions before they start, = please note that we have removed any inference in this use case that slaves= may talk directly with other slaves when one or other of them is out of range of the master (i.e. a type of re= lay or proxy function). This is not a requirement that is particular to M2M= , and will be dealt with in a separate thread.

 

Regards

 

Andy<= /span>

 

 

___________________________________________= ____ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB45CBEA18765basavarajpatilnokiacom_-- --_004_CB45CBEA18765basavarajpatilnokiacom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Wed, 25 Jan 2012 21:11:51 GMT"; modification-date="Wed, 25 Jan 2012 21:11:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_CB45CBEA18765basavarajpatilnokiacom_-- From andy.sago@bt.com Thu Jan 26 06:07:08 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CBB21F8629 for ; Thu, 26 Jan 2012 06:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rjsZ-WyxGYR for ; Thu, 26 Jan 2012 06:07:03 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 30F4F21F8622 for ; Thu, 26 Jan 2012 06:07:01 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jan 2012 14:07:00 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.35]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Thu, 26 Jan 2012 14:07:00 +0000 From: To: , Date: Thu, 26 Jan 2012 14:06:56 +0000 Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCwDCefoAADnTZRD///wWAP/+ixuQ Message-ID: <619CDADDCCD2B44380834BE8BF6F71414060BB5730@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F71414060BB50DF@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/related; boundary="_004_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 14:07:08 -0000 --_004_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_ Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_" --_000_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Raj Firstly just to reiterate that this is out of scope for PAWS - action to be= taken if slaves lose communication with a master must be out of scope (cle= arly we can't define a message exchange if the underlying transport has dis= appeared). But I have included it in the use case to address concerns raise= d in Taipei. I would be OK to add an additional sentence into my new point = 7 in the M2M use case, after the sentence "When one of these conditions occ= urs, transmissions from slave to slave would also cease." This extra senten= ce would say "Various mechanisms could be used to detect loss of signal fro= m the master, for example by requiring masters to transmit regular beacons = if they allow slave to slave communications". In the UK, when Ofcom writes= the statutory legislation that licence exempts slave devices, they will ne= ed to specify the rules for controlling slave to slave communication. Regards Andy From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] Sent: 25 January 2012 21:12 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] Clarification of M2M use case Thanks for the clarification. I guess it is important to point out in the use case that the slave devices= are listening to a beacon from a master device (as an example at least) an= d the loss of such a beacon would result in communications that may be dire= ctly between slaves ceasing immediately. -Raj From: "andy.sago@bt.com" > Date: Wed, 25 Jan 2012 15:06:52 +0000 To: Basavaraj Patil >, "paws@ietf.org" > Subject: RE: [paws] Clarification of M2M use case Hi Raj The master doesn't need to know that slaves are talking direct, and traffic= is not routed through the master. Each slave is within range of the master= , and associated to it. A command from the master to tell slaves stop TVWS = communications on the current channel (if such a protocol is developed) wou= ld be received by all slaves and acted upon. This would apply to slave-slav= e transmissions as well as slave-master transmissions since they are both u= sing TVWS. Alternatively if the master dropped comms (stopped beaconing or = whatever) then both slaves could detect that, and the default action then w= ould be to cease all transmissions over the air, to the master or to other = slaves. Thus, the direct slave-slave transmissions are under control of the= master in so far as the master decides whether all slaves can transmit or = not, based on information from the database. I don't think there is anythin= g extra needed wrt PAWS protocols to enable this. The scenario is similar if the master is allocated a choice of channels by = the database, and the list is passed to the slave. I suppose the master cou= ld make itself known on channel A, and slaves associate on channel A and ar= e told that channels B and C are also available (at particular powers etc).= They then use B and C for direct slave-slave comms. If the database indica= tes (by push or pull) a revised list of channels to the master, with channe= l A still usable but B or C not, then the changed list of frequencies shoul= d be signalled to the slave. This could result in a change of frequency by = the slave, rather than a ceasing of all transmissions, and the existing net= work on channel A would be unaffected. The previous paragraph is just a theoretical exercise, I don't see any reas= on why slave-slave comms would use a different channel to slave-master com= ms in the M2M use case, but don't see any reason to prevent it. Regards Andy From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: 24 January 2012 17:50 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] Clarification of M2M use case Hi Andy, Question about the following statement: " Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost " How does the master know that slaves are communicating with each other dire= ctly using TVWS channels? Do you assume that communication between slaves i= s routed through the master? -Raj From: "andy.sago@bt.com" > Date: Fri, 20 Jan 2012 14:01:32 +0000 To: "paws@ietf.org" > Subject: [paws] Clarification of M2M use case All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The "Note" on= the slide now has two bullets and reads: * Note: Further signalling can take place (outside the scope of PAW= S) to establish direct links among those slave devices that have associated= with the master device. * Machine communication over a TVWS channel, whether to a master de= vice or to another machine (slave device), is under the control of the mast= er device, and would cease if so requested by the master, or if connection = to the master is lost I have also copied the revised slide here: [cid:image001.png@01CCDC26.31AEF7C0] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description - I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Raj

<= p class=3DMsoNormal> 

Firstly just to reiterate = that this is out of scope for PAWS - action to be taken if slaves lose comm= unication with a master must be out of scope (clearly we can’t define= a message exchange if the underlying transport has disappeared). But I hav= e included it in the use case to address concerns raised in Taipei. I would= be OK to add an additional sentence into my new point 7 in the M2M use cas= e, after the sentence “When one of these conditions occurs, transmiss= ions from slave to slave would also cease.” This extra sentence would= say “Various mechanisms could be used to detect loss of signal from = the master, for example by requiring masters to transmit regular beacons if= they allow slave to slave communications”.  In the UK, when Ofc= om writes the statutory legislation that licence exempts slave devices, the= y will need to specify the rules for controlling slave to slave communicati= on.

 

= Regards

 

Andy

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm'>

From: Basavaraj.Patil@= nokia.com [mailto:Basavaraj.Patil@nokia.com]
Sent: 25 January 20= 12 21:12
To: Sago,AJ,Andy,COD R; paws@ietf.org
Subject:= Re: [paws] Clarification of M2M use case

=

 

 

Thanks for t= he clarification.

I guess it is important to point out in the use case that the slave device= s are listening to a beacon from a master device (as an example at least) a= nd the loss of such a beacon would result in communications that may be dir= ectly between slaves ceasing immediately.

<= p class=3DMsoNormal> 

-Raj

 

= From: "andy.sago@b= t.com" <andy.sago@bt.com>
Date: Wed, 25 Jan 2012 15:06:52 +0000
To: Basavar= aj Patil <basavaraj.patil@n= okia.com>, "paws@ietf.org&= quot; <paws@ietf.org>
Subj= ect: RE: [paws] Clarification of M2M use case

 

Hi Raj

 

=

The master doesn’t need to know that slaves are talking di= rect, and traffic is not routed through the master. Each slave is within ra= nge of the master, and associated to it. A command from the master to tell = slaves stop TVWS communications on the current channel (if such a protocol = is developed) would be received by all slaves and acted upon. This would ap= ply to slave-slave transmissions as well as slave-master transmissions sinc= e they are both using TVWS. Alternatively if the master dropped comms (stop= ped beaconing or whatever) then both slaves could detect that, and the defa= ult action then would be to cease all transmissions over the air, to the ma= ster or to other slaves. Thus, the direct slave-slave transmissions are und= er control of the master in so far as the master decides whether all slaves= can transmit or not, based on information from the database. I don’t= think there is anything extra needed wrt PAWS protocols to enable this.

=  

<= span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>The scenari= o is similar if the master is allocated a choice of channels by the databas= e, and the list is passed to the slave. I suppose the master could make its= elf known on channel A, and slaves associate on channel A and are told that= channels B and C are also available (at particular powers etc). They then = use B and C for direct slave-slave comms. If the database indicates (by pus= h or pull) a revised list of channels to the master, with channel A still u= sable but B or C not, then the changed list of frequencies should be signal= led to the slave. This could result in a change of frequency by the slave, = rather than a ceasing of all transmissions, and the existing network on cha= nnel A would be unaffected.

 

The previous paragraph is just a theoretical exercise, I= don’t see any reason why slave-slave comms would use a different cha= nnel  to slave-master comms in the M2M use case, but don’t see a= ny reason to prevent it.

 

Regards

 =

Andy

 

=

 

<= div>

From: Basavaraj.Patil@n= okia.com [mailto:Basavaraj= .Patil@nokia.com]
Sent: 24 January 2012 17:50
To: = Sago,AJ,Andy,COD R; paws@ietf.org
<= b>Subject: Re: [paws] Clarification of M2M use case

 

 

Hi Andy,

 <= span style=3D'color:black'>

Question about the following statement:

"=

Machine communication over a TVWS channe= l, whether to a master device or to another machine (slave device), is unde= r the control of the master device, and would cease if so requested by the = master, or if connection to the master is lost

"

 

How d= oes the master know that slaves are communicating with each other directly = using TVWS channels? Do you assume that communication between slaves is rou= ted through the master?

 

-Raj

 

From: &qu= ot;andy.sago@bt.com" <andy.sago@bt.com>
Date: Fri= , 20 Jan 2012 14:01:32 +0000
To: "paws@ietf.org" <paws@ie= tf.org>
Subject: [paws] Clarification of M2M use case

 

All

 

There was a request for clarification on the M2M us= e case presented at the Taipei F2F, in particular with regard to slave-to-s= lave communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a= couple of changes to the M2M slide to make this clearer. We have added two= arrows so that it is clear that each of the slaves is in communication ove= r TVWS with the master, as well as the slaves being in communication with e= ach other. The “Note” on the slide now has two bullets and read= s:

 = ;

· &= nbsp;       Note: Furthe= r signalling can take place (outside the scope of PAWS) to establish direct= links among those slave devices that have associated with the master devic= e.

· =         <= span style=3D'font-family:"Calibri","sans-serif";color:#1F497D'>Machine com= munication over a TVWS channel, whether to a master device or to another ma= chine (slave device), is under the control of the master device, and would = cease if so requested by the master, or if connection to the master is lost=

 <= /span>

I have a= lso copied the revised slide here:<= /o:p>

 

 

The sequence of events is= as follows (note that steps 1-5 are the same as in the use case descriptio= n in the current working group draft, but we have removed the last sentence= in step 6 (previously the final step) so that this can be expanded in the = new step 7):

 

   1. = ; The master device powers up with its whitespace radio in idle or

       li= sten mode only (no active transmission on the whitespace

       frequency ba= nd).

 

 =

&n= bsp;  2.  The master device has internet connectivity and establi= shes a

    &= nbsp;  connection to a trusted white space database (see Section 3.1

&= nbsp;      above).

 

=

   = 3.  The master device sends its geolocation and location uncertainty

     &nb= sp; information, and optionally additional information which may

       inclu= de (1) device ID and (2) antenna characteristics, to a

       trusted databas= e, requesting a list of available whitespace

       channels based upon this = information.

 

   4.  The database responds = with a list of available white space

<= span lang=3DEN style=3D'font-size:10.0pt;font-family:"Courier New";color:bl= ack'>       channels that the master device m= ay use, and optional information

       which may include inter alia (1) a du= ration of time for the use

&nbs= p;      of each channel (channel validity time) (2= ) a maximum radiated

  = ;     power for each channel, (3) an indication of the = quality of the

  &nb= sp;    spectrum for each channel and (4) directivity and oth= er antenna

   &nb= sp;   information.<= /span>

&nb= sp;

   5.  Once t= he master device authenticates the whitespace channel list

       response me= ssage from the database, the master device selects one

       or more availab= le whitespace channels from the list.

=  

   6.&nbs= p; The slave devices fitted to the machines scan the TV bands to

       locat= e the master transmissions, and associate with the master

       device. = ;

 

   7.  Further signaling can take place= outside scope of PAWS=

 &nb= sp;     to establish direct links among those slave dev= ices that have

  &nb= sp;    associated with the same master device. At all times = these direct

   =     links are under the control of the master device. F= or example,

   &= nbsp;   common to all use cases, there may be a regulatory r= equirement

   &n= bsp;   for transmissions from slave to master to cease immed= iately if so

   =     requested by the master, or if connection to the ma= ster is lost

   =     for more than a specified period of time. When one = of these

   &nb= sp;   conditions occurs, transmissions from slave to slave w= ould also

   &nb= sp;   cease. Direct slave to slave transmissions could only = restart if

   &n= bsp;   each slave subsequently restores its connection to th= e same

    =    master, or each slave joins the network of another master= .

 

- end of event sequence description –

 

I hope this is now clearer. Please = let me have any further queries on the reflector.

 

To deflect one set of questions be= fore they start, please note that we have removed any inference in this use= case that slaves may talk directly with other slaves when one or other of = them is out of range of the master (i.e. a type of relay or proxy function)= . This is not a requirement that is particular to M2M, and will be dealt wi= th in a separate thread.

 

Regards

 =

Andy

 

=
<= div>

 

_______________________________________________ paws ma= iling list paws@ietf.org https://www.ietf.org/mailman/list= info/paws

= --_000_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_-- --_004_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Thu, 26 Jan 2012 14:06:57 GMT"; modification-date="Thu, 26 Jan 2012 14:06:57 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_619CDADDCCD2B44380834BE8BF6F71414060BB5730EMV62UKRDdoma_-- From nbravin@earthlink.net Thu Jan 26 14:30:32 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B011F21F871D for ; Thu, 26 Jan 2012 14:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w6S5B8IChHE for ; Thu, 26 Jan 2012 14:30:31 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id B9B4B21F871E for ; Thu, 26 Jan 2012 14:30:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nW1j3+R4GKYCma7Y2MkIo00pXit5Ye3dw5DEYOmE+YLpBUtNLw/FfPZZV5nH0ft0; h=Received:From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RqXpu-0005Gy-H8; Thu, 26 Jan 2012 17:30:30 -0500 From: Nancy Bravin Content-Type: multipart/alternative; boundary=Apple-Mail-2--730005269 Date: Thu, 26 Jan 2012 14:30:29 -0800 Message-Id: <85354118-2131-4502-9A68-A8234F0215B8@earthlink.net> To: scott.probasco@nokia.com Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86bd45dc516b9a1c07c5e86b7c084a3131350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] proposed edits X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 22:30:32 -0000 --Apple-Mail-2--730005269 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Scott and Raj and all,=20 I offer the following as edits to the document : 1.1 page 4 " Television transmission until now has primarily been analog. The switch to digital transmission has begun. As a result the spectrum allocated for television transmission can now be more effectively used. Unused channels and bands between channels can be used as long as they do not interfere with the primary service for which that channel is allocated. While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi-urban areas." =20 I would change " While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi-urban areas." =20 =20 to=20 =85..while urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in = semi-rural, rural and remote areas. Since there are many countries that also have "remote" areas, I would = consider adding remote as a more global outlook for billions of people that live = in remote areas. 1.1 page 5 >> "In any country, the rules for which >> primary entities are entitled to protection, how the exclusion = zones >> are calculated, and what the limits of use by secondary entities = are >> may vary. However, the fundamental notion of recording primary >> users, calculating exclusion zones, querying by location and >> returning available spectrum (and the schedule for that spectrum) = are >> common" > To me I would change "are calculated, and what the limits of use by = secondary entities are may vary." to: > are calculated, and what the limits of use are by secondary entities = may vary. Or put a comma after are and leave as is. >=20 > ALso, I think you need a period after "are common" to end the = sentence. 2.2. Terminology page 6 Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. I propose: ..."is an entity which contains, but is not limited to, current = information about available spectrum at any given location." May avoid comments like=85."what other types of information?"=85and = listing more when you should not have to at this time??? >> 3.3. Air Interfaces page 8 >>=20 >> Efforts are ongoing to specify air-interfaces for use in white = space >> spectrum. IEEEs 802.11af task group is currently working on one = such >> specification. IEEE 802.22 is another example. Other air = interfaces >> could be specified in the future such as LTE. >=20 I propose: Efforts are ongoing to specify air-interfaces for use in white space=20 spectrum. IEEE802.11af and IEEE802.15.4m task groups are currently = working on such efforts, and IEEE 802.22 , continues its work on the first WS = standard approved. Other air interfaces could be specified in the future with LTE for = example. It makes it accurate and agnostic technology wise.=20 SIncerely, Nancy --Apple-Mail-2--730005269 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = Scott and Raj and all, 

I offer the following as = edits to the document :

 1.1 page = 4
   " Television transmission until now has = primarily been analog.  The
  switch to = digital transmission has begun.  As a result the = spectrum
  allocated for television transmission can now be = more effectively
  used.  Unused channels and bands = between channels can be used as long
  as they do not = interfere with the primary service for which that
  channel = is allocated.  While urban areas tend to have dense usage = of
  spectrum and a number of TV channels, the same is not = true in rural
  and semi-urban areas." =  

 I would = change

" While urban areas tend to have dense = usage of
  spectrum and a number of TV channels, the same = is not true in rural
  and semi-urban areas." =   
 
to 
=85..while urban areas tend = to have dense usage of
 spectrum and a number of TV channels, the same = is not true in semi-rural, rural and remote = areas.

  Since there are many countries that also have = "remote" areas, I would consider
adding remote as a more = global outlook for billions of people that live in remote = areas.


 1.1 page = 5
 "In any = country, the rules for which
  primary entities are = entitled to protection, how the exclusion zones
  are = calculated, and what the limits of use by secondary entities = are
  may vary.  However, the fundamental notion of = recording primary
  users, calculating exclusion zones, = querying by location and
  returning available spectrum = (and the schedule for that spectrum) = are
  common"

To me I would change "are = calculated, and what the limits of use by secondary entities are may = vary." to:
are calculated, and what the limits of use are by = secondary entities may vary. Or put a comma after are and leave as = is.

ALso, I think you need a period after "are = common" to end the = sentence.

 2.2. =  Terminology page 6

  Database

    &nbs= p;In the context of white space and cognitive radio = technologies,
     the database is an entity = which contains current information = about
     available spectrum at any given = location and other types = of
     information.

I = propose:

..."is an entity which = contains, but is not limited to, current information about available = spectrum at any given location."

May avoid comments = like=85."what other types of information?"=85and listing more when you = should not have to at this time???


3.3.  Air Interfaces = page 8

  Efforts are ongoing to specify = air-interfaces for use in white space
  spectrum. =  IEEEs 802.11af task group is currently working on one = such
  specification.  IEEE 802.22 is another example. =  Other air interfaces
  could be specified in the = future such as = LTE.
I = propose:

 Efforts are ongoing to specify air-interfaces = for use in white space 
spectrum. =  IEEE802.11af and IEEE802.15.4m task groups are currently = working
on such efforts, and IEEE 802.22 , continues its work = on the first WS standard approved.
Other air interfaces could = be specified in the future with LTE for example.


It makes it accurate and = agnostic technology wise. 

SIncerely, = Nancy

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 22:40:01 -0000 --_000_CB47321C18853basavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Nancy, Your proposals definitely help improve the text in these sections. We will = incorporate them as suggested. -Raj From: ext Nancy Bravin = > Date: Thu, 26 Jan 2012 14:30:29 -0800 To: Scott Probasco > Cc: "paws@ietf.org" > Subject: [paws] proposed edits Dear Scott and Raj and all, I offer the following as edits to the document : 1.1 page 4 " Television transmission until now has primarily been analog. The switch to digital transmission has begun. As a result the spectrum allocated for television transmission can now be more effectively used. Unused channels and bands between channels can be used as long as they do not interfere with the primary service for which that channel is allocated. While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi-urban areas." I would change " While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi-urban areas." to =85..while urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in semi-rural, = rural and remote areas. Since there are many countries that also have "remote" areas, I would con= sider adding remote as a more global outlook for billions of people that live in = remote areas. 1.1 page 5 "In any country, the rules for which primary entities are entitled to protection, how the exclusion zones are calculated, and what the limits of use by secondary entities are may vary. However, the fundamental notion of recording primary users, calculating exclusion zones, querying by location and returning available spectrum (and the schedule for that spectrum) are common" To me I would change "are calculated, and what the limits of use by seconda= ry entities are may vary." to: are calculated, and what the limits of use are by secondary entities may va= ry. Or put a comma after are and leave as is. ALso, I think you need a period after "are common" to end the sentence. 2.2. Terminology page 6 Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. I propose: ..."is an entity which contains, but is not limited to, current information= about available spectrum at any given location." May avoid comments like=85."what other types of information?"=85and listing= more when you should not have to at this time??? 3.3. Air Interfaces page 8 Efforts are ongoing to specify air-interfaces for use in white space spectrum. IEEEs 802.11af task group is currently working on one such specification. IEEE 802.22 is another example. Other air interfaces could be specified in the future such as LTE. I propose: Efforts are ongoing to specify air-interfaces for use in white space spectrum. IEEE802.11af and IEEE802.15.4m task groups are currently working on such efforts, and IEEE 802.22 , continues its work on the first WS stand= ard approved. Other air interfaces could be specified in the future with LTE for example. It makes it accurate and agnostic technology wise. SIncerely, Nancy _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB47321C18853basavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0C2DE4125E3DDF47A99A665304DEAEF0@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Nancy,

Your proposals definitely help improve the text in these sections. We = will incorporate them as suggested.

-Raj

From: ext Nancy Bravin <nbravin@earthlink.net>
Date: Thu, 26 Jan 2012 14:30:29 -08= 00
To: Scott Probasco <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] proposed edits

Dear Scott and Raj and all, 

I offer the following as edits to the document :

 1.1 page 4
   "=  Television transmission until now has primarily been analog.  Th= e
  switch to di= gital transmission has begun.  As a result the spectrum
  allocated for television transmission can now be more effective= ly
  used.  Unused channels and bands between channels can be u= sed as long
  as they do not interfere with the primary service for which tha= t
  channel is allocated.  While urban areas tend to have dens= e usage of
  spectrum and a number of TV channels, the same is not true in r= ural
  and semi-urban areas."  

 I would change

" While urban areas tend to have dense usage of
  spectrum and a number of TV channels, the same is not true in r= ural
  and semi-urban areas."   
 
to 
=85..while urban ar= eas tend to have dense usage of
 spectrum and = a number of TV channels, the same is not true in semi-rural, rural and remo= te areas.

  Since there = are many countries that also have "remote" areas, I would conside= r
adding remote as a = more global outlook for billions of people that live in remote areas.


 1.1 page 5
 "In any country, the rules for which
  primary entities are entitled to protection, how the exclusion = zones
  are calculated, and what the limits of use by secondary entitie= s are
  may vary.  However, the fundamental notion of recording pr= imary
  users, calculating exclusion zones, querying by location and   returning available spectrum (and the schedule for that spectru= m) are
  common"

To me I would change "are calculated, and what the limits of use = by secondary entities are may vary." to:
are calculated, and what the limits of use are by secondary entities m= ay vary. Or put a comma after are and leave as is.

ALso, I think you need a period after "are common" to end th= e sentence.

 2.2.  Terminology page 6

  Database

     In the context of white space and cognitive r= adio technologies,
     the database is an entity which contains curr= ent information about
     available spectrum at any given location and = other types of
     information.

I propose:

..."is an enti= ty which contains, but is not limited to, current information about availab= le spectrum at any given location."

May avoid comments = like=85."what other types of information?"=85and listing more whe= n you should not have to at this time???


3.3.  Air Interfaces page 8

  Efforts are ongoing to specify air-interfaces for use in white = space
  spectrum.  IEEEs 802.11af task group is currently working = on one such
  specification.  IEEE 802.22 is another example.  Othe= r air interfaces
  could be specified in the future such as LTE.


I propose:

 Efforts are o= ngoing to specify air-interfaces for use in white space 
spectrum.  IEE= E802.11af and IEEE802.15.4m task groups are currently working
on such efforts, an= d IEEE 802.22 , continues its work on the first WS standard approved.
Other air interface= s could be specified in the future with LTE for example.


It makes it accurat= e and agnostic technology wise. 

SIncerely, Nancy

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB47321C18853basavarajpatilnokiacom_-- From Basavaraj.Patil@nokia.com Thu Jan 26 15:30:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED321F875B for ; Thu, 26 Jan 2012 15:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFMj7DH9MXGO for ; Thu, 26 Jan 2012 15:30:20 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B30B121F8759 for ; Thu, 26 Jan 2012 15:30:19 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0QNUEk6031629; Fri, 27 Jan 2012 01:30:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 01:30:13 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 00:30:12 +0100 From: To: , Thread-Topic: [paws] Clarification of M2M use case Thread-Index: AczXfANjS3SqPIPyTDyOKxnAeL8nCwDCefoAADnTZRD///wWAP/+ixuQgAMt4wA= Date: Thu, 26 Jan 2012 23:30:11 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414060BB5730@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: multipart/related; boundary="_004_CB473DBF1888Cbasavarajpatilnokiacom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jan 2012 23:30:13.0532 (UTC) FILETIME=[73E79DC0:01CCDC82] X-Nokia-AV: Clean Subject: Re: [paws] Clarification of M2M use case X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 23:30:21 -0000 --_004_CB473DBF1888Cbasavarajpatilnokiacom_ Content-Type: multipart/alternative; boundary="_000_CB473DBF1888Cbasavarajpatilnokiacom_" --_000_CB473DBF1888Cbasavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, Agree with your comment below. I am in favor of including the additional se= ntence that you proposed in your email to this use-case. -Raj From: "andy.sago@bt.com" > Date: Thu, 26 Jan 2012 14:06:56 +0000 To: Basavaraj Patil >, "paws@ietf.org" > Subject: RE: [paws] Clarification of M2M use case Raj Firstly just to reiterate that this is out of scope for PAWS - action to be= taken if slaves lose communication with a master must be out of scope (cle= arly we can=92t define a message exchange if the underlying transport has d= isappeared). But I have included it in the use case to address concerns rai= sed in Taipei. I would be OK to add an additional sentence into my new poin= t 7 in the M2M use case, after the sentence =93When one of these conditions= occurs, transmissions from slave to slave would also cease.=94 This extra = sentence would say =93Various mechanisms could be used to detect loss of si= gnal from the master, for example by requiring masters to transmit regular = beacons if they allow slave to slave communications=94. In the UK, when Of= com writes the statutory legislation that licence exempts slave devices, th= ey will need to specify the rules for controlling slave to slave communicat= ion. Regards Andy From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: 25 January 2012 21:12 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] Clarification of M2M use case Thanks for the clarification. I guess it is important to point out in the use case that the slave devices= are listening to a beacon from a master device (as an example at least) an= d the loss of such a beacon would result in communications that may be dire= ctly between slaves ceasing immediately. -Raj From: "andy.sago@bt.com" > Date: Wed, 25 Jan 2012 15:06:52 +0000 To: Basavaraj Patil >, "paws@ietf.org" > Subject: RE: [paws] Clarification of M2M use case Hi Raj The master doesn=92t need to know that slaves are talking direct, and traff= ic is not routed through the master. Each slave is within range of the mast= er, and associated to it. A command from the master to tell slaves stop TVW= S communications on the current channel (if such a protocol is developed) w= ould be received by all slaves and acted upon. This would apply to slave-sl= ave transmissions as well as slave-master transmissions since they are both= using TVWS. Alternatively if the master dropped comms (stopped beaconing o= r whatever) then both slaves could detect that, and the default action then= would be to cease all transmissions over the air, to the master or to othe= r slaves. Thus, the direct slave-slave transmissions are under control of t= he master in so far as the master decides whether all slaves can transmit o= r not, based on information from the database. I don=92t think there is any= thing extra needed wrt PAWS protocols to enable this. The scenario is similar if the master is allocated a choice of channels by = the database, and the list is passed to the slave. I suppose the master cou= ld make itself known on channel A, and slaves associate on channel A and ar= e told that channels B and C are also available (at particular powers etc).= They then use B and C for direct slave-slave comms. If the database indica= tes (by push or pull) a revised list of channels to the master, with channe= l A still usable but B or C not, then the changed list of frequencies shoul= d be signalled to the slave. This could result in a change of frequency by = the slave, rather than a ceasing of all transmissions, and the existing net= work on channel A would be unaffected. The previous paragraph is just a theoretical exercise, I don=92t see any re= ason why slave-slave comms would use a different channel to slave-master c= omms in the M2M use case, but don=92t see any reason to prevent it. Regards Andy From: Basavaraj.Patil@nokia.com [mailto:B= asavaraj.Patil@nokia.com] Sent: 24 January 2012 17:50 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] Clarification of M2M use case Hi Andy, Question about the following statement: " Machine communication over a TVWS channel, whether to a master device or to= another machine (slave device), is under the control of the master device,= and would cease if so requested by the master, or if connection to the mas= ter is lost " How does the master know that slaves are communicating with each other dire= ctly using TVWS channels? Do you assume that communication between slaves i= s routed through the master? -Raj From: "andy.sago@bt.com" > Date: Fri, 20 Jan 2012 14:01:32 +0000 To: "paws@ietf.org" > Subject: [paws] Clarification of M2M use case All There was a request for clarification on the M2M use case presented at the = Taipei F2F, in particular with regard to slave-to-slave communication. Juan= Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to th= e M2M slide to make this clearer. We have added two arrows so that it is cl= ear that each of the slaves is in communication over TVWS with the master, = as well as the slaves being in communication with each other. The =93Note= =94 on the slide now has two bullets and reads: =B7 Note: Further signalling can take place (outside the scope of P= AWS) to establish direct links among those slave devices that have associat= ed with the master device. =B7 Machine communication over a TVWS channel, whether to a master = device or to another machine (slave device), is under the control of the ma= ster device, and would cease if so requested by the master, or if connectio= n to the master is lost I have also copied the revised slide here: [cid:image001.png@01CCDC26.31AEF7C0] The sequence of events is as follows (note that steps 1-5 are the same as i= n the use case description in the current working group draft, but we have = removed the last sentence in step 6 (previously the final step) so that thi= s can be expanded in the new step 7): 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity and establishes a connection to a trusted white space database (see Section 3.1 above). 3. The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 4. The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 5. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 6. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. 7. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. - end of event sequence description =96 I hope this is now clearer. Please let me have any further queries on the r= eflector. To deflect one set of questions before they start, please note that we have= removed any inference in this use case that slaves may talk directly with = other slaves when one or other of them is out of range of the master (i.e. = a type of relay or proxy function). This is not a requirement that is parti= cular to M2M, and will be dealt with in a separate thread. Regards Andy _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB473DBF1888Cbasavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1317D888B87DE14B983C63B9FBBF825F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Hi Andy,

Agree with your comment below. I am in favor of including the addition= al sentence that you proposed in your email to this use-case.

-Raj

From: "andy.sago@bt.com" <andy.sago@bt.com>
Date: Thu, 26 Jan 2012 14:06:56 = 3;0000
To: Basavaraj Patil <basavaraj.patil@nokia.com>, "= paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Clarification o= f M2M use case

Raj

 

Firstly just to reiterate that this is out of scope= for PAWS - action to be taken if slaves lose communication with a master m= ust be out of scope (clearly we can=92t define a message exchange if the underlying transport has disappeared). Bu= t I have included it in the use case to address concerns raised in Taipei. = I would be OK to add an additional sentence into my new point 7 in the M2M = use case, after the sentence =93When one of these conditions occurs, transmissions from slave to slave would al= so cease.=94 This extra sentence would say =93Various mechanisms could be u= sed to detect loss of signal from the master, for example by requiring mast= ers to transmit regular beacons if they allow slave to slave communications=94.  In the UK, when Ofcom writes= the statutory legislation that licence exempts slave devices, they will ne= ed to specify the rules for controlling slave to slave communication.<= /o:p>

 

Regards

 

Andy

 

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.= com]
Sent: 25 January 2012 21:12
To: Sago,AJ,Andy,COD R; paws@ietf.o= rg
Subject: Re: [paws] Clarification of M2M use case<= /p>

 

 

Thanks for the clarification.

I guess it is important to point out in the= use case that the slave devices are listening to a beacon from a master de= vice (as an example at least) and the loss of such a beacon would result in communications that may be directly = between slaves ceasing immediately.

 

-Raj

 

 

Hi Raj

 

The master doesn=92t need to know that slaves are t= alking direct, and traffic is not routed through the master. Each slave is = within range of the master, and associated to it. A command from the master to tell slaves stop TVWS communications o= n the current channel (if such a protocol is developed) would be received b= y all slaves and acted upon. This would apply to slave-slave transmissions = as well as slave-master transmissions since they are both using TVWS. Alternatively if the master dropped comms = (stopped beaconing or whatever) then both slaves could detect that, and the= default action then would be to cease all transmissions over the air, to t= he master or to other slaves. Thus, the direct slave-slave transmissions are under control of the master in so= far as the master decides whether all slaves can transmit or not, based on= information from the database. I don=92t think there is anything extra nee= ded wrt PAWS protocols to enable this.

 

The scenario is similar if the master is allocated = a choice of channels by the database, and the list is passed to the slave. = I suppose the master could make itself known on channel A, and slaves associate on channel A and are told that ch= annels B and C are also available (at particular powers etc). They then use= B and C for direct slave-slave comms. If the database indicates (by push o= r pull) a revised list of channels to the master, with channel A still usable but B or C not, then the change= d list of frequencies should be signalled to the slave. This could result i= n a change of frequency by the slave, rather than a ceasing of all transmis= sions, and the existing network on channel A would be unaffected.<= /o:p>

 

The previous paragraph is just a theoretical exerci= se, I don=92t see any reason why slave-slave comms would use a different ch= annel  to slave-master comms in the M2M use case, but don=92t see any reason to prevent it.

 

Regards

 

Andy<= /span>

 

 

From: Basavaraj.Patil@nokia.com = [mailto:Basavaraj.Patil@nokia.= com]
Sent: 24 January 2012 17:50
To: Sago,AJ,Andy,COD R; paws@ietf.o= rg
Subject: Re: [paws] Clarification of M2M use case

 =

 

Hi Andy,=

 

Question about the following statement:

"

Machine communicat= ion over a TVWS channel, whether to a master device or to another machine (= slave device), is under the control of the master device, and would cease if so requested by the master, or if co= nnection to the master is lost

"

 

How does the master know that slaves are co= mmunicating with each other directly using TVWS channels? Do you assume tha= t communication between slaves is routed through the master?

 

-Raj

 

From: "andy.sago@bt.co= m" <andy.sago@bt.com>= ;
Date: Fri, 20 Jan 2012 14:01:32 +0000
To: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] Clarification of M2M use case

 

All

 

There was a request for clarification on the M2M us= e case presented at the Taipei F2F, in particular with regard to slave-to-s= lave communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to the M2M slide to = make this clearer. We have added two arrows so that it is clear that each o= f the slaves is in communication over TVWS with the master, as well as the = slaves being in communication with each other. The =93Note=94 on the slide now has two bullets and reads:

 

=B7         Note: Further signalling can take place= (outside the scope of PAWS) to establish direct links among those slave de= vices that have associated with the master device.

=B7         Machine communication over a TVWS chann= el, whether to a master device or to another machine (slave device), is und= er the control of the master device, and would cease if so requested by the master, or if connection to the mas= ter is lost

 

I have also copied the revised slide here:

 

 

The sequence of events is as follows (note that ste= ps 1-5 are the same as in the use case description in the current working g= roup draft, but we have removed the last sentence in step 6 (previously the final step) so that this can be ex= panded in the new step 7):

 

&nbs= p;  1.  The master device powers up with its whitespace radio in = idle or

&nbs= p;      listen mode only (no active transmission o= n the whitespace

&nbs= p;      frequency band).

&nbs= p;

&nbs= p;

&nbs= p;  2.  The master device has internet connectivity and establish= es a

&nbs= p;      connection to a trusted white space databa= se (see Section 3.1

&nbs= p;      above).=

&nbs= p;

&nbs= p;  3.  The master device sends its geolocation and location unce= rtainty

&nbs= p;      information, and optionally additional inf= ormation which may

&nbs= p;      include (1) device ID and (2) antenna char= acteristics, to a

&nbs= p;      trusted database, requesting a list of ava= ilable whitespace

&nbs= p;      channels based upon this information.

&nbs= p;

&nbs= p;  4.  The database responds with a list of available white spac= e

&nbs= p;      channels that the master device may use, a= nd optional information

&nbs= p;      which may include inter alia (1) a duratio= n of time for the use<= /p>

&nbs= p;      of each channel (channel validity time) (2= ) a maximum radiated

&nbs= p;      power for each channel, (3) an indication = of the quality of the<= /p>

&nbs= p;      spectrum for each channel and (4) directiv= ity and other antenna<= /p>

&nbs= p;      information.

&nbs= p;

&nbs= p;  5.  Once the master device authenticates the whitespace chann= el list

&nbs= p;      response message from the database, the ma= ster device selects one

&nbs= p;      or more available whitespace channels from= the list.

&nbs= p;

&nbs= p;  6.  The slave devices fitted to the machines scan the TV band= s to

&nbs= p;      locate the master transmissions, and assoc= iate with the master

&nbs= p;      device. 

&nbs= p;

&nbs= p;  7.  Further signaling can take place outside scope of PAWS

&nbs= p;      to establish direct links among those slav= e devices that have

&nbs= p;      associated with the same master device. At= all times these direct

&nbs= p;      links are under the control of the ma= ster device. For example,

&nbs= p;      common to all use cases, there may be= a regulatory requirement

&nbs= p;      for transmissions from slave to maste= r to cease immediately if so

&nbs= p;      requested by the master, or if connec= tion to the master is lost

&nbs= p;      for more than a specified period of t= ime. When one of these

&nbs= p;      conditions occurs, transmissions from= slave to slave would also

&nbs= p;      cease. Direct slave to slave transmis= sions could only restart if

&nbs= p;      each slave subsequently restores its = connection to the same

&nbs= p;      master, or each slave joins the netwo= rk of another master.

 

- end of event sequence description =96

 

I hope this is now clearer. Please let me have any = further queries on the reflector.

 

To deflect one set of questions before they start, = please note that we have removed any inference in this use case that slaves= may talk directly with other slaves when one or other of them is out of range of the master (i.e. a type of re= lay or proxy function). This is not a requirement that is particular to M2M= , and will be dealt with in a separate thread.

 

Regards

 

Andy<= /span>

 

 

___________________________________________= ____ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB473DBF1888Cbasavarajpatilnokiacom_-- --_004_CB473DBF1888Cbasavarajpatilnokiacom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=36285; creation-date="Thu, 26 Jan 2012 23:30:11 GMT"; modification-date="Thu, 26 Jan 2012 23:30:11 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeAAAAFoCAYAAACPNyggAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAI1SSURBVHhe7b13nB3HdSaq/XPfH0+yZUu21vaz duXwk73SPnv3eU3veiWSiEQkqQBKlBgkiKJIIgODDBAAMwmQHBJEzpiEATCDwSDnQACDnHOcQc4Z TOedqtuhurqqu/revqHvnObv/ji4t7vq1FfV9dWpqvPV1yDh1/5D24A+hAG1AWoD1AaoDeS7DUSl 069FfaDQ7s834JQ/vfTUBqgNUBugNsDaQNSLCJg8aJpBoDZAbYDaALWBGNoAEXAMINJolkaz1Aao DVAboDYQtQ0QARMB00iW2gC1AWoD1Aby0AaIgPMAetRREt1PI2tqA9QGqA0UXxsgAiYCppEvtQFq A9QGqA3koQ0QAecBdBrJFt9IluqU6pTaALWBqG2ACJgImEa+1AaoDVAboDaQhzZABJwH0KOOkuh+ GllTG6A2QG2g+NpAsyPgqAWm+wkBQoAQIAQIgUJAIPFCHIUAItlACBAChAAhQAhERYAIOCpidD8h QAgQAoQAIRADAkTAMYBISRAChAAhQAgQAlERIAKOihjdTwgQAoQAIUAIxIAAEXAMIFIShAAhQAgQ AoRAVASIgKMiRvcTAoQAIUAIEAIxIEAEHAOIlAQhQAgQAoQAIRAVASLgqIjR/YQAIUAIEAKEQAwI EAHHACIlQQgQAoQAIUAIREWACDgqYnQ/IUAIEAKEACEQAwJEwDGASEkQAoQAIUAIEAJRESACjooY 3U8IEAKEACFACMSAABFwDCBSEoQAIUAIEAKEQFQEiICjIkb3EwKEACFACBACMSDwtX/+538G+hAG 1AaoDVAboDZAbSCzNhCVk4mAaQBCAzBqA9QGqA1QG4ihDRABxwAijQIzGwUSfoQftQFqA82xDRAB EwHTSJbaALUBagPUBvLQBoiA8wB6cxzpUZnJw6E2QG2A2oC3DRABEwHTyJfaALUBagPUBvLQBoiA 8wA6jQLJE6A2QG2A2gC1ASJgImAa+VIboDZAbYDaQB7aABFwHkCnkS+NfKkNUBugNkBtgAiYCJhG vtQGqA1QG6A2kIc2QAScB9Bp5EsjX2oD1AaoDVAbIAImAqaRL7UBagPUBqgN5KENEAHnAXQa+dLI l9oAtQFqA9QGiICJgGnkS22A2gC1AWoDeWgDRMB5AJ1GvjTypTZAbYDaALUBImAiYBr5UhugNkBt gNpAHtoAEXAeQKeRL418qQ1QG6A2QG2ACJgImEa+1AaoDVAboDaQhzZABBwV9KFrELM1MNT0uaj3 m6Yb9T5uxymY+pTpqHMolpIVdWhhvphPTcXSMPNMy9OM7yu2umdtX1f/Ud+30Put90DoKU9NfUr9 ToSmJbVB3f2R66sZt+2o/WCB3U8EHLFCnprKun3zjp+/S5GIL0svU+SXmgi4aKYIi63u8Z1NFWkq PCW9v7G+n6mXVxrkWe9FVvNO5aEl+oh9VtG04yIsNxFwxEq1X3DVy+9r6NYoPZkEnKWBQES8tZ0H ecDmMxORCbjA6/6f9QQV2/sZ2L7U+ceWtz3AKNTZp7jeYUonKv/C15r7aMoaFBt5wal+71RhTJUW WydMBNx8CTigLcf1fnIyVXi5dv+n+j2uvFkeKTKPsNRFZGb+PhQQVlEZuJkT8FOQei+GpqbAAkeo bJTM1lzDppOsND01Ya/VhjzreNjealROXXk6LX+evrVUnrawZiw+r8g3bC1W7Jwca9Ma4fvX5Pgk v2JdzvFITNbvdC+liIOiEHK55VuCpxGp7tMZ0OvJMa73001HZ5+fIOPK25p9SGPAHEraykGr3Ab1 pB/fO2yVMUr/5byfUd+ZPJbPgOiJgA1Acl9CgRBDXhC3kwhYS7VbtExEdsNcs0azFmSTkGpTlUtQ HnKw7R0qEauwocVDFhoCXrOGjUCkfC17lWTjlMW/mcstfhpTnkEesJ2nz4MJwk1jg4VDeLlTaXsJ meqe75hQDLQyqXv94Dfm9zOgb/CvQcecdxozPOkQsFwO5dp67O9wGv0Xq4s0+sv8lM+8PyMCTpeA /zlolJz6LdUZa+4LIi1uk0ukXmILH507U1giATnDV80IVx5QKAmY96bqHeDKAUmY92+/VFF2Z3tH z37PO3zzWAoKw+k9Z5QeXO5TuNSg3GEu46gb8HjaIdW93jNOtX/1zILY3jJ8P4P6BeW7G3feqgFd cMcenYAN3s+A9XanjiJ562n2X2n1l/konzn5MvyiXs17CloelaaG4n5Ckr5XjSqVI035pbdIU+xs Ql8yXcehSMvbyUkvvIaA9VOq/g4jbB3Nzl/v0QQ0Zo2HYIaPyYvpJXptuQO8g1T5/LhQ3bv1Gr3u A4gpxvdTPwCwBkfy7ErseUdoo9Y7H9r2fe+MRYYR17pV2JjWY6iNmv4rvXcm9+WLuqRCBBzFA/aN 9FQviX+E7m90pi+XfJ/Z6FHZCEJHqVJeQWvASsw0tpq2sIBOQFmegPUsk/AN08GBNt7UxsBwZO7a RHXvaxJR6j5oaja291M38LPXExWzHbHnbdpOXFtDyU2FXeDMmGq9NeCFDq3HdPsvUywU9+W0fNG8 X/KAo5Cvswbh9Xh9jV4x5agj4LCNS/b0dfTOW9EQck7Api9N9EbLCVnZEZvnGdpZeQg2YIo8dK1O tsl0alEeyJmXzTdgKaa6DyXgON5PVZsMIN9Y+wY77+j1Hdqmddg5yyzyen10G4I9wHTTS/edUWz2 8uxHSNeeNPssBd+Y+if2fc16ClrZwKVGrZyKMRodqyq1CDzgtHY6GzTwnHrA8RNwuJdOdW8+85Fq L/G9n3L7CyHfrOQdnRzSJmDPFLZIwul6rCEzCJH7BFMsgu9zoiKc/OMun0G/JZEwEXAEL1i3DuF8 HzLCFD3e9NY0MogPzLkXZGore2ni24RltsHKWscz6QhUm6jENhPZA9arOHkIJ/b1/yCM415+yGLd B+Ad5/vp1kU4+bJ748/b1OsTOn3dnhTT2RzFQCKU1J19DmbvsFl6fiJLt7+UB3Fy/mb2pNlHGXAL EbABSKGbhezOEnfCqoP3FS+T4dqhP8bVjDx4wxIJJg8E7Ozk1hKdWecWzRMKHy2bvXTi9FWcHrA7 fR62oY3q3mRWyGBDVzrvJ+8XzNundhNSunmHDfyM9mF48TMnMXEaP6y/McdI3JQYpjHv67/S7i+l NuQbpMRdvmheMBGwMQGHhzWkQh4jdBr2BgHNjkrINA4YxSkcrdy8ELBLNr6BSVh4T1i9BHmedtq+ TSFROwvb/pgJ2Fkz5AoiXj1jZ1d1hjHgRVv3ugFW3O9nlLYSd97Y7kLfV01Hr5g5cTx030yT7Nlp yEj3PqX9Dlv5KGe+7N+wLxXbcFrvTL7KZ07CRMBhHb3ze4hnFTj9Y/aCupVhqITl7PDzVmO4EpbB ICHjXdCK0bfU2sLXQQMacujUrzUtKLdwk2ln3xRzFgjY42GJRlLdB2/k0b1LMb6f4qakwB4ySl3p 4s7V5THepR/gCXtMV+1QHoqYpc6bcK+A90PV3WT0Dkfpv5xyqnZma+oh3+Uz4BYiYAOQosZ20f3m I0DCirCK2gYyI6dk4K2d0qb+KpGaz7o2TgRMDbqoGnTUzpzuTwYh+TeomW36SWb9prEBi/qxRPZj RMDUcBPZcJPZsSaQ7Ary/QjfaJfo9hG2m7kg64TadjptjgiYGjMRMLWBxLUBox29iazX/MempkMk 9Ex6AxAi4ES+pOlVNr0khBu1AWoD1AYKpw0QARMBJ877oQ6kcDoQqguqC2oD6bcBImAiYCJgagPU BqgNUBvIQxsgAs4D6DRiTH/ESNgRdtQGqA0USxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9GIZvVE5 yBOhNkBtgNpA+m2ACJgImEa+1AaoDVAboDaQhzZABJwH0GnEmP6IkbAj7KgNUBsoljZABEwETCNf agPUBqgNUBvIQxsgAs4D6MUyeqNykCdCbYDaALWB9NsAETARMI18qQ1QG6A2QG0gD20gMgFHfYDu JwQIAUKAECAECIHMEfha5klQCoQAIUAIEAKEACEQFQEi4KiI0f2EACFACBAChEAMCBABxwAiJUEI EAKEACFACERFgAg4KmJ0PyFACBAChAAhEAMCRMAxgEhJEAKEACFACBACUREgAo6KGN1PCBAChAAh QAjEgAARcAwgUhKEACFACBAChEBUBIiAoyJG9xMChAAhQAgQAjEgQAQcA4iUBCFACBAChAAhEBUB IuCoiNH9hAAhQAgQAoRADAgQAccAIiVBCBAChAAhQAhERYAIOCpidD8hQAgQAoQAIRADAvkh4Cvd YPqmbyk+LWD33RhKFXMSDaVdoEtpQ2ypxp1ebIZlMaHmVubmVt4sNh1KmhAoWgQSTsBNUFPSBUpq mjwV1FRTAl1KasD7rWEdNtSAlJzhg1m+raEUjMcAUe7NhtlhGObbvihlTpKtUcpF9xIChEDeEcgr Adc2HnMAuN7YAj3iqB5wA5Qi0dbUiGSLpFzTAA2lpWD7rJyQu6AXi59S/N4hMuxc7e8dD5eRR439 vZWG3Qnjb6Wldlrq9J3BQFMNlNh5ys5zSHpovMKulN1NaJszQMA8Sq1/uGUs4fbbZRTLLg9U5Nan xcm6UcQULeGDH+9AB+uDZRyAIfcMOS5opzVCUtoo48cww7qz60ssS6T6xbKEYRIFS3avd2DEcMG2 IRK3qj4N7Mh770AGEAKEQFYRSD4B8w7fS6qpr6wOHn8TO2tGALzDZB280HM6HSnrLO3vHaK00hd/ Q3pvYOlI6bvpBHjSQrru1LaVXoBdWgL22JAiRl4EnW2qJqXDSbxXvIeTP348RGoNDoIwZOlJ9SWT acp2CT8P9ikSVZXRpH6V+dnljIwl4l0qDADlNhNQn4F2ZPW1p8QJAUKgEBBINgE7HqDlefG+PeWZ 2p6ix2MUOn/f904HLHT8dvpyp8rutX4TvSmvd2Z5iKp548D0BA9XIj8dAevL6Hr+Ks9RTF6XhreR Wt4dxzGFEyt/ikhSsxHcqRXJU8ZQImBj/OSpYAd/CS/rPl396vNLlTQtLB3bBDLO0I5C6BzIBkKA EMguAnklYP9GrIhT0IK30oTeWIMwJet4WTrPTutRBRFwwG+6epLy57cJU9C+6eQAT0/2+NReoNcD jrJurJwpkMplE26DPe3PPDxGvB6vNgQnxYyFtpnb+EX1gMNwNKovUyxTxNsgTkcrZzm8nrtx3WS3 D6DUCQFCIE8IJJ6AnU6Mrxm664q2h5ryatRrwB5vyJl2jkjAnE/tdU13bVO11unUcRABS/b6psPt tVe2jipsNNOVUWWbrq2FrQFbLiJf25bJuksXd008igecGo8Y4Mcwi7gGrKxfTX4iJmlhKRG+OM2e rh156hMoW0KAEMgRAvkh4BwVjrIpIgTkKegiKhoVhRAgBJonAkTAzbPek1dqIuDk1RlZTAgQAoEI EAFTAyEEUnPrTlhVTczCKwQwIUAIEAIqBJovAefSo8okr0ye1bX5dNJM55m43rkwYY9Y8nF30seS HEskn5jFVghKiBAgBLKFQOIJWLlhJlQwwytW4QOXbaixRDRECcooeXnSZB0x7hq2hTl0aSqFMoRO XCsgEcFeYyEM5hM6m9fUeJni4cRk26BYZcpI2MNjn7spzLXJDkdzN+AFCZE4uIhx5RxXe3MZEjQT crFEVXR1EQUz2x7Z5my97JQuIUAIFBYCySZgoxAjlWCGEF4i14ehcIIj+ODZ/WrlJafJ7pF2LBsL ZQjhLFEFRbRhRVIYkFoIQxQwUeAVBXsxRpg5hlzBJOUhisphUYU9VHa7cclS+hZh60N/BA9YxIeH WWGss7jDXip7aDiYMPBQ1YnH5sLqH8gaQoAQyCICiSZgrXiE1IEyuUYzoQmFEIMFfpS8VB61t+Nv QLlIZpOBUIZVFh7nLCasE6IIs9ciPpUnJ4p1hOEVFQ+HpNBuVAq1rUzJNnKbogl76LAT7TLC18FU Q8Ccx72HcZjkbQ8wxHqPWodZfO8p6WaEwJa9J2Ho+OXQ7/1aKGGfD4SP/Z3qN3af+Lv4nP130O9B aeNv/T6og48r1sCXX37VjGrDW9REE7Asteh6pepYXtf7CPCAIws+KPKK4AGHijFoPGDR65KntAMl GiUC1q5Tery8KB6wDo+UihbzcsVDMmIR9hDw9gwMIq3BqgnYsQ9J2Gk/unQjYmbXoVaVrdl2S1Tw OBEYOX4xjJy4FHYcbCyoz/qdx6FTjwlw4/a9OIubqLSSTcDWtKLvoAWVFKLuXkV16YQTdGueqsMR PMmyDlsQkRAJM1Qow2ANOJK9MgHbHp695q05JMFziIXjZSsETjTYqzxC/p116EJkYQ+N3TKZ6fD1 rj9zUFIHSQj4yJ6v+G9dumFiJqq1YyLgRPWZiTP29UlLoGzR1oKz+7PPvoBnh8yE67eIgAuucsig 4kPAka/Md9FEydJ820L5EwJZRuD1yUthet2WLOcSPfkbSLzPIAGz/zfXK/EecHOtuMSVO9J0cOJK RwYTAgWLQKES8HWcev4184BpCrpg2w4Z1gwQkKd6m0GRqYiEQM4QKFQCZp4vJ2DygHPWFgonI08o TsDZvYVjsWRJKi5VFa9sbHJOBC5ksxOGNXnuxs2JbixMBN4o1Clo2wMmAi7MhmNilVIQQSPEYafn E6NgRFRji2+4p/pohS/chHiMKCdB60i+FCEGp+HsYHYK6J6zG5qn84xauUm7CUgl1qEptwd3trM3 Qhk9m7VM83R2etfgRih7Y1eEenDqI9rzkcQ0rM1irH5Dd66bNFy6hxDIEQKF6gEzz5d5wLQLOkcN IfZsIolByJ4Y7ky241HF0KOwsB8xGeE53plLu2i1YVJMdxjPj3XCcaLkKRKw7AHr8AgQF/Efd+jH yb4nUhmj5CmU390hrhJQEc7TVTUmlSiKkWiG95xeZbhaPmYLYn9hKMHmiAB5wIVb64nehKUTNvDE tup2vOqmoB2BC3ORDF69SvEPtXiG936XjNMWjrDal04cQxvmEhQyJHj54kBFPH85SOAkUp4CAfvT N6gHla0h9RhdTMM6rIHc38LtzcgyJQJEwIXbMBJNwLKH6YpTmIljuMSiFu4I7Ws9JC541Dbp67wv 3h5SxNuAnrOS4ELbjGIK2mhGQPT2ouIUXka1RGdInsIUtC+mOsoarGpAESCaoazfiGIaodVENxAC eUYgbAq68cwZWLRokWPlYvz76tWrSqsPHjwI+/fv5789uH8fjh09mnbp2BQ0D0OiXdBpY5j3B3Vr wEbiGM4UtJqIoohk6LzuwDVdz5RpCkp1nsz7wgMRRAkpJhyh2ISlWwNWinXE4AHzoYQgqSmuARvn GUTAWkwUTU9THr0Yh7CJLUSARHWIRd4bPxlACBggEOYBb960CUaNGgk3b96EpsZGeO+dd+HI4cOw b98+WLliJdxHot29ayds3LABVq5cCR9//BF+vxyuX78Oe/fu5c+sXr0Kf98IX3zxBTRsaYC1a9fw 54IuRry0C9qgAukWQoAQIAQIgWQiEEbAW/FwlIkTJ8KyZctg7Zo1MG3aNNiHxHrw8CGYgN9XVVVB ZUU53Lp1C1atWgW1tbVQM38eLFm8BOoWLIDq6mrYuHEjlJeVwdy51TBr9mwoL6+AvXv2EAGHNJlk T0En830gqwkBQoAQyBkCYVPQa1evhjVIvG++8SYSZzmsQi93Yd0CmDR5IkyZPAXJtxImTZzEp5uX LFmCp5lt4UQ9f/58qMVPDeq7nz59Gmrx/2Wzy2D8uHGwBwn83r1ghSvaBQ1ABJyF1yBMWCLs9yyY lHaSSbI17ULSg4RAESMQ5gFfvnSJTyefPHkSLl26jJ9LfA14+/atsH3bNrh79y7s3beXe7nnzp3j v12+fBnOnj3rfO7cuQNncC2ZTTtv3doAmzdvxlOOviQPmDzgHL1ZUTYLiSZFfS6T+7MRShPVnqjV EXf6cnqZ6ELHbVtUbOh+QsAAgTAP2CCJrNxCSljF4AGrxB6wuRgLdGhEO7SbpxT5+YU9UruFtYIb VsctP9eAIhSejVZSB6/aCBS0ySsWwRFhg5QskmFqj2sjimtEwDto45PuZKpgIQ/EFwVXvGf0ljqY q08q8guDsN7ItOxZ6bkoUUIgAgKFSsD2FDRJUUaozIK6NUDsQT7ezj4jVyX0YCz+oMsv1SMrwon0 ghvq0CPc2cwUtSyQG3BzhO+S8lGWU+dhi7uuTcU/gkQyFOUW7XHPuy3xnKVrjLecvl0uo3ArlZCH fK6xUD+aNO3zgJXtPmpdZPjynD5/FdbtOAFrth4tmM/qrUdgx6GzcP+zzzMsHT2eLQTCpqCzlW9Y urQLOuEesE7sIZJAh1JAQy3+EHhuqy4m2Pne29nrYn8drxnJvkbBvyLRa8upJWB/uFWo+IdAwLJI Bs9GKLeRuEUEvOX07WLpBEfUYiiuh+tLz2O7WjTFtM6N6iKsRwr5/dkhM+DlN+dBv/drCuczpgY6 9JwMSzamYkPpKjwECt0DpuMIC6/NmFkkxdG6QhyoXyzM5QYKdEQUb3C9N2mKWUfAYYIbvnXElC50 Ke4o9IT9Ct6fSN7KckYgYA9pqVAPidFVe/7ehDwkFgXvyB6wWlBFKS3Jxw6u3rRO1MWUgLWiMGYt 2eiu54fNhktXbxndm8ubRoxfBBVLtucyS8orAgKFTsBhU9DnLt8E+OqrCCVOzq2J3wWtFHtA/I0F OiKKN+jyCyQiaaAQSlpBm3uk30IPb/AMDNIQHIlCwJzU/OIWoQSseU7nAbPvdWvAKgEWtVCIX0lM vQYsedC6wY2uzcXYF/xm+Gw40XQlxhTjSWrYJ/UwZ/mOeBKjVGJHgE1Bz1y4JfZ0M03w9t0HXIjj 2s27nqTYv9dvPwqjZ62EpwfNgNY9psOA0jq4ect7X6b5F8LziSfgQgAxbhsadN5v3Bk14/T8G+QK H4znkYBPniUCLvyaKiwLR0xYBOOqN8KtO/cL6tN08QaeIjcF7t7/DPYcPQtT67ZCj3droE2PKdC2 bzW07L8A2gxcAu2GrYBHelfDr5CsTxVg+8+ktomAM0EvG89SaEs2UC2KNBkB59sDVsV2kgdc2M2r HJcHnhlWDmwGhX3YUobzYf8WP+Jv7O+g38J+D0g7ZUs5vDCqDL7C/ybNXQ+d+86AH788Ax7tWwft hq+CJ15bD51GrIFOr66EjiNWQ8u+NdCx11RYu+1IYQMewToi4AhgZfPWbAleZCvdqFiE2RH0e9iz UW1J6v2qKejPPvsMKlC9qAYVifYfOOAp2oMHD+DixYue75qammANygmaXleuXIG1q9c4t584fpxr /ooXEbApmvHcl85q6N0Hn8FN1F5mO48L5XMTPfLPPnfFOti/l2/aB4M+rIWOPSdBi24zoE3/Wmg/ bDmS8Gpo228u/NMv3oQe78yJB8gCSKV4CVi39lkAoOMRSNLBCoVgFNpQyJjZEDXjGQKVB3zh/Hlg B2AwNaM333wLTpw4ARs2boB169ZDw9atMGTIEC6yz0Lali9fDkdRTvCdt96G+oV1XNXo+InjsHTp Ujh/4QJsWL8e9u7aA9euXYMVeO+2bVu5ROEmFOvfvXs3NGzagmndgqlTp+CeGJcGiIBz8/6earoM A3Et9PPPv/BkyAh1+MQVsOdIY24MyUEun+46Ck/2mQT/vcsb0LZ/DXQatQ7aDV4KjyAp/3zAdKhZ tRP95uRfiSdg1caZTAQoPKIRQqdfgqcRdWGnD7E4XUeMw91FqzsRiJEaf4597O3LjIBRECL1vZVG gOAFM0O52YrFJVtpa49ODEnXLaK9ecoSA1HZqLNDeA/CxEf4rUpMrDhqlVCHVYaowiXJfz29JVAR 8Hkk0TIUwWfX2LFjkUyXoQ7vHnjvvdGwdt06JMupwDzh3Xt2w/vvv88F96sqq+D48WP42zSu4Vtd PRfq6upQTH827Ny5E6ZMmQIr0UuuqpwDn4z7BA4fOoQC/DWwdNlS7Pw/h0mTJsDt27cd44iAs9/S HmCc9bPDK+CVNyt8mbEQsBY9K+Gx7pNg1+Ez2TcmBzls3HUMfjOiAlp3nwatS2pxLXgxdHh1DTz+ +gb+96O9KuC3IyuAxaGLg8EcmBZrFskmYJ0gg9XJi+E6LvnZHb06VEkpvCDsYuZE6BCpOi3nTNwA oRBVGkFiIaFhVbpmESakIT4nhVKFlVO9kSlEfCQAk6Dypy1cEuvrkt/EVFPQTJP39ddfg81btnDR /HXr1sLkqZNhzJgPYOeOHfzouO3bt8PYTz6GDz8s5QQ8Dkl1xYoVSLAVXHB/5sxZsHDhQvRyd8GH SNITxk/AU23mwpGjR6AOPeVtW7dxwmaeMzumbvr0acCmvu2LCDj77WLoJ4ugRY8ZsHXvSV9mfUfP hVb9aqHt4CXQptsE2LrPf0/2LcxODnvRq39/5nJ4asBUaPnKVGjVZw5fD247sB7+9dkP4A+vlcHn XwRrTmfHsnhSTTQBB4ofhITfGIlGuO6hQuWKu4MYr9uE/1OLPWhjSINiYSMJVaSUncTYZF+zCBPS 0BJwGqIdPrz84iN6TNzBjE/wQxtjLcRi64RL4nlPCiIV3SasLUi+bIrZJkXm7bKD0zF4kp/pegGn l/fg0XDsIHV2pBzzaLehyP6XX34Bx44d5We6MjF+ds/xY8e4iP42nL5mpHvs6DFYsmgJTl0f4c8f xyludgqOeBEBZ7d5TJm/AR56YTJ0GTADz9v1ks2Va7egY59pSL7L4PGRa+GxQUjUL42HjTuLZ6MS Q5dNr/90UDn801NvQitcF2absx7pNhMGflQLV64XXmy8aYtINAEHih+Exb9q1hKVBKEjAFvIX+eJ a4VC1IIRKQ8w4LcAL1f0kD23hcXxRiDgUNEOJ60U8TbgbIHPc9Vi4k5B+2J5AwgYKThYuMT0TUjA ffmIA2ZLvWxN2L5uIoHfEqaf2fdEwNlrPMs/3Q+te83GKddq+KRipS+jeSu2Q5veKa+w/fAV0BmJ qe3gRdDy5UmwuoENwpJx7TjYCBeu6uN8b929DwvX7YV+qLz2WLfJ0Bo3ZLVmU9G958KT/abB9gOn k1FQycpkEzAWJujQBLfzNxegSIuAJTvYphg7b6VwR6AHbG5r0GEFTj3HScBsfKAQ2lC2/ADxETUm 6RIwN8pzwEIi30QDo/NBwAZmEQGbgJTGPQePnYXHS2ZBiwH10K5PGRw/dd6Xysuvz4YWfWtxfXQ1 dEICbo8xs51HrkFPGKejUcDisOKZNEzJ+iOlZavgyYEV0Ou9ebD00wPo1bp7DOTMmy5cgcqlm3A3 9Fxo36cc/s8rZdCm50woX7It63bGnUHiCThuQCi95CHQXIRLuBAHKWElr4GmYfHlazfhp32nQIuS Ou7pvfDqdF8qZy9ew+nn2fDYkGXQefhKjJ1dAZ2QgDsgAT/Sax70fLcabt+5l0bu+Xmkfv0e3Eg2 BX700gzo0Hs6DPm4HjXG96FS1h2tQafOXYGyxVvht6/Ohg59y6Dn6Bq4ejM5ZSYCzk9bo1zjQqCZ eL8MLvKA42o0hZ0OW+ft9vYceLhnFXRGMYo2ON1avdyvtT1jwac4FTsPOiHhdkDi7cgIGP9+FAUr nuo3Ba4lcG30JIZavfzGHJxyx/LjxrI2JfOgbbeJuNa7EJZvPgyXr+vJ+Ch6+5NrtsKpc9cKu4IF 64iAE1NVZGhzR4AIuPhbwGcY4ztqYj08irt92Xpuu6HLUJRiClxVkGnJ6Dnwo1dmQ2c2/YwE3Imp ReF09U9KZsLhk8qjXBIB4OcYcjUelbEe6zUT2uPObja4+F+/Gw//u+snMAplNYvpIgIuptqkshQ1 AjQFXdTVywt37cZt6NB9PLToMx+eGLUeWmEM7MAP5ikLfvHKTfgJerot+87nnm9bnIpu0306rN7i VURLImqf7j6Bm60mIfFOhM6jNkBr1Ib+Xy+MQ3GOyfDB7FUY75zcAYZYH0TASWydZHOzRIA84OZR 7bsOnoTWL0/khPpY30rYuOOwsuCHTpyHDn1mci+5A+olt0SVqBm1G4oCpIMnz+GO5/nQoV8ltMR1 8M4j13E1rNbo4bfCfz+Gm9J+gbHBE6o3oDgMxQEXRaVTIQiBQkagEA5jUOFDYUjxtpo3Jy+BR3tW oNjEIujSf6o2cbbJ6lE8Jejx1zZASwzHebr/xHgNKYDUGvaegG5vVKIuNMY64+lInXGavdPIVTgd PQ7+56/ehZL3qhN9VjB5wAXQyMgEQsAEASJgE5SSfc+MBRvh0R7l0J4dPoDrn21RirFu7R5fobbt OwVte5fxsKMOeHJQu6HLUSlrJnqE631iHclGBGDngVM4IzAe/u23H2NZV/Jwq7YD6hCnMmiHpyO9 +Hol3wndeOF64opKBJy4KiODmysCqfOArxZc8ckDjqdKPt1xBNr0ms5VrTrjlHJnVLZ6uOdcpf7z iyjB2KLPXBTgwOP6huNpQXhvi74L4GcDy/DUo+I6uP7S1VvQG739Nn2qoD0ONDoOX82FR9gaOQu5 aoMDlUdw13Tr7lPhhdfmwJnzySFiIuB43h1KhRDIOgLPDp0J5y7dyHo+UTMYPq4ehRGSJ4IQtZzZ vL/xwlVo330itMI1zg4jV0Nn9GzZMXztMbZ192GvytPWvcegde9Z+PtKrn7V8VX0gJGE2vWeDWu2 7M+mmXlM+yv4pGodtOoxC9oOwoMZsOyt+y/EEK35iFEF/BTVsIaMrYM5K3bC9VsUB5zHiqKsCYHi ROD5YbPgd6PmoEeU6acKeo1ZAN3fmQcvv1mVUXrd0JaOvSZjjGbyd97mq9Vcu3EHnsXD7R/Bnc+P I/l2ZDG9TOu49zzoO8Z79i07Fek3w2dguNFCHn7UEadkO6K3/PArM2HmguLYgBVUD4vW7ob2PfFQ hpfGQa9358D0mnWw71gjnvjlHg6Sr3pMJ1/ygNNBjZ4hBPKAwAUMO9lz5BzsPNSY8eflD9fBjKX7 Mk5nF9py9MwVePCZ94zaPMCT2CzPnL0MPx9chaITdXxqla1zdsCp1va403fvYe8Zv0yi8adMnhLJ uhN6viz298fdy2Hk+LrElj+q4ew85C+/+DzqYwV5PxFwQVYLGUUIZBeBkWW7YeuRK9nNhFI3RmDn QdxUhXGv7DSjTqPYeu586ItCG6rr0x0HodUrU/iJQC3QS/79iNk4AEqmByiXrwnlNWcv2QXj5mzQ fqbUbIIpNZthPIYgjZuzPvDeoHSi/DZ1wVbYj9rccV9EwHEjSukRAglAYPjMnbBh/4UEWNo8TNy5 /wTueJ6Kus5LcVPVSmiLBynsxyP4VFf9ut3QFiUo22CYUqceE+H6Tf3BBUlD76OKNfDcsHIYW7W+ oD4DSuuh92jvMZxxYEsEHAeKlAYhkDAEiIALp8LOnLsM7bpPwEMX6nFn7zp4GI8eLBmD8a2aq+ur Mzj5tkeyfvSlCVCxZCue/Fwc15hZq9C73VhwhdmNSwHsKMS4LyLguBGl9AiBBCBABFwYlXTv/gP0 +Gah9vN8LjLRccQqaIU7e38+aDZs3+8/45YdOMCO4Gs3FI8dRLL+Ufcq+MPI2UVDwB+UrUbPd11h VI5gxae7jkP/92tjtys/BHylG0zf9C3FpwXsLq4QttgrLLME2eH1XaBLSQ0eY09XLhDg5yc7B1Pn IkezPIiAzXDK9l3Dxi6AH/Wo4AcvsNOMOrCwIoxtbd2nGuav2OHLfszMZaj9PI+rX7XAU49+OXA6 HtRQPFPQBU3AHxIBSw2yAUq7YAfnfEqgxoRZTI6wM7kn229n7OkjXtkmAxG3hhqz+oi9nFaCcdZh nGllq7wR0iUCjgBWlm6dXrMBHumB59hiGBFXeGKxv/g3OwGoc59pvrXd+xhq8/MBTKhjKbTBWNjH 8Ji+Y6fPZ8m6/CTLCJjF+2ZyPXjwAL76KjUp/8Xnn6MyWOY79DeiB1zyQZERcG3jMQfn640t0COO 6gHLhMIIuRQarFSbakocci4tLQXGPdwj4YTtkrXqPrwRSmtqoMQmd4G4lPc3uffat4r3lWhGBqq0 mmpKXeLCdEutZ1Xpud+hvaXSAEQiDafsaKD4HMNLaSs+X1JiYci8Zvx3CjsXY/FF8WHLCBjLIj8T iItBnib4h9WzXR8yDmJ53N8QVyxHUL2ye71jGzbbgDh5BiQ2Fl6v2KSdZNIhqZ4lAo4b0Wjpbd9/ Elp2nwltMdyIhROx2F8mK8lONWqJ5+AOUJyAtHbrQdx8NRcPacAQJTyqb8P2Q9EyTcDdOgKeNnUq voOpTVD79u6F0e+9x/++e9edMv3yyy852VZVVUFTU8oTa2pqdP7+HMnYvhhJR7kYAfcnApYhU3h0 dofHOnKB9FiH7HSQUqeovI+RjTBV63SwunRlb0+6z99BY1k0aSkJWJMeS9e1H/EQbG5osIciNm4u Xp7ntGVCDCzQOEnYAAZ5gzLhyM+E4cJwD8rTFH9W5IB6tuvDi5/Qvjz5pKbuuVla+/GeUmFqX2iH /Dk2QJMGccHpRekeot/LCHgj7YKODlxMT5zFcJsXRlaiB1xlCWog+Vpn+jLJxZUKYZN+o+fCo31r oV3/eVC5eEtMlhRWMrop6PHjxsGw4cNQcOMBzJo5C14f9RrcvXMXVq1aBfX19XD6zGmorKyAPbt3 w8SJE/HvSli2dCkcPHgQ9u3bB0sWL4bqOVXQsGULnD59GhbVL+KfLw29Y/KAle1EQcCWx+ghMUVn 7Hozgrcp3ucjmQYcgTVhP6q5H1dV+fqqSB6e6fEungEBH51p0lIRsOgl2VPujHjlNByiRxxqZP7F uQF7Clp8rgk9fc+tttctEZjDH4JX7qsW3RS0Uy/urIRYDiedkDxN8efpCWmZ4mfboa+bAPud/AQy tr7zpWdlpLMr293iqPJ9sP3EzWxnQ+kHIHDj5i145Y0qeLhHJapZ4QYs9ITb4PRyx16T4OYt72aY S1dv4uarafAwim68j+vAxXrpPODqOXOgAgl2xowZsHTJEiTTOXDk6BHYtmMH9mkfwYQJE2Avesbs Gj9+Apw6dQrKy8pg/vz5nHynTJkCjY2NMGP6dO4979y1G+ZWz4PPDD3hovSA/RuxMp2CZiRoTcPm 2gO23wg73yAvUb7X+rfjpQu2i563avnW37Gnpj7Z9Ll/OVxNwFqvLgsE7PFKVb1IWJ5B9WqRrjMj oEtLyFdHjF5MvB6wfhk9RbwN4nS04AmLm7HC6jXbHeywGTsiecD2mlq27Wpu6d+5cw+6v1WJJFyF G6vWoRrWAhiCbUi+Zi9qgH97YQqUvF+D65vJPf82rH51BFxZUY6kehp69uyJHuwZqF+4EBYurIPp 06bCpAkTYd3adTAdyXXPnj3c+71w/jwsqK2FJUjWq9FLrpk3Dy5dvAjz8f+L0GNeWFcHR48dDTPH +Z0IWAmVvAlLmGbmHqZ/DVj2jNi/tWvAuG7sbPAKWQNWrTm633nXnMWiqG20vGnmQYtTys76tZue kkC05K8hYAmDUALLwANOcWTAxrkwAtbUlwp/mexV+WoJOKD9hNnv2fWs88KF9mTSTox7CsMbR5Tv hw0HLgferSJdts52//59/mF/05U5Anfv3oMeb6Mn3LMaWvWugDUNXl1tVg9P9pmEBw5MhVu372ee YQGnoJuCttd679y5w62/d+8e32jV2HgGrl9PnX505swZuHr1qtM2WRtlU9Zie2XPsevEieNw+XJw +xdhKq4p6AJuAHk1zcRrNjCwQen9GjxItxQVAjKBss5p+bLlMGHcJ/DMwInQe9gYeHXYUBgx/FUY NWoUvP3W2zBr1izYuXOng0MTTtvVobfwYemHuAY3HIYOHgz9+w+AgQMHwPBXh+PnVZwC/BC9kXq4 dOmSBz/yms2b032MB+71Dh4v2HMS3LnnJdnNe07BU0Mr4HjjRfMEs3Tn5198yafHjzddgRvSNHkc WcaxCzoOO+Q0issDzgZCxZBmHAQcRxrFgGUzLwMjP5sA2drYqyNHQkn/EvgI18uWLVsGp0+d5FNy 15CUGXGePHkStuCmPbbONgJJdeCAATBs2DAY0L8/jB83HjZu3IBew0m4efMmfIYn8rDTZ9jfzJNY t24dfPTxR9Cnd28Y9doo3PSSOhKPechEwuYN8S4S7/5j/oWjxgvX4Mip/JEvi+j5CjcrHTt9AcZW rISSscvhZ0Oq4dTZ+LXEiYDN20ve7yxUkYO8AxPRgOaIY3Mo8xdffgFvv/s2XzdbvnwFhmiYTxmz naL+XfTBDYuFgCzFnacvvfwylH74YcRWSLcXHgJf4fnT12Hesq0wpmw9tHllPLQvmQ8t+9fD08Pm wYlG74xHHPYXqhAHTUHHUbssjSgeYpR747JPlU427MhGmulgoLMjG/ZlI810ypylZ5i3aa/LMgGC fv36oWc6Vpmb6CGHmWPfq/NmVWm98847MGToUPSA0XuyRBHC8qHfCweBazduwsSaLfB470nQeWA1 tMVTmh7DmOUOr66BVqhBXfLRIlyPTq3HxnmRBxwnmtlOy9lhimIVKELhE4nA332bqFRhIUqxi3Dx BR7baYUa6XbGekQWcFOXHRqkE1/QCWKEinuoyor4qzZ5+QUzgkUmcFuvGl+hftUb2dTP6QQuPM1F s3nJI2iS5zJnu3mnkz4jO7bx5L0xo+HDD0vTSSK2Z14d8SpMQQEFupKHQPmiLdC250zUnF6GJzQt h84oEMJlMjFUqiVKYL43c1VWCkUecFZgzVKiyhCPBpw648yjFT5gZBYudmEgvhAmtagLmZG+Dxf5 sAhSl56hyEOQGIlKFEIMi3J39lr4ilUaUE7fc557BYzlJiLUrVIoJd9lzlKTNklW9Cjv4U7PtbgG +/HYsbjO+yoMGjIIhg4ZAgNwDTeKl2uSb9R7bty4AZ0e74wxmJNh6bKlXMHo7j03vtW2j3ZTR0U2 3vuv37wDt+7chyUb9kDVsm3Q7e050HXkHNSangcdmDgIEm87/H8Hrtq1GtoPqoc5y92NenFaQwQc J5rZTkvopGWRiKD4Th0BRxdf8IpvyMVVCVwwD1gvChEsiKETzNCLPOhEQ9BSRbiPkSCHIgRJK44h 5mEikCKReqqe1Jjku8zZbtph6bNwikmTJ8PL3V6BN996C+MdF8Phw4d4GMZdK1QjLI1s/m6T6rbt 26G8vAJ3Xo+H1197Hfr27Quvv/E67EABBfuiKeps1oQ+7dNNl/Ew+43Q+71qeH7UfOjQrwJa9JmL Xi9qTQ9cjLKY66ETHhLBpTLxw84p7jgcxUL6VELD3uNZMZqmoLMCa5YSFaagHdVJQcUpUPhA8MTU Hqip+EKKzJRazwGeoXLKOsAzDpQtZFOxBjKHUT1gFxfhUAVVDLC2nIrnMvSAxbrKa5mz1KSDkrWJ av++vdD1t11h/MQJcPXaVeUj+fR+7bVoFbHevn0LVq5cCX379IWhuEZ840YqhpPIOLcN6j7uZH8f z959DHUGWg1YiKS7HNohwbJDIR4bhtPMfeYh0c6Bx/pVQ4telXhfNf5dCe37z4U/vFsPJzEMKRsX ecDZQDVbaQYRMObp8TR9OsZqsQudeIdKLEEp/iCVVXyOqVPZa8A68YV014CVZZUwsA+k4CYqPGD2 tTr/EALW5SNO0WsOlfDYJGJnsAac7zJnq1mr0rXJ7OjRo/DMc8/Avv2pUB92JcGDVNlYWVEJL/zu d3D1SmoQka9BwxdffgU3UODiJk7DFuLn7n33EIFM2hw7H+j6jdtw8MR5GFu+Ap4bOQ9altShh7sW Hh+xlnu5nfH/j+FJSz/rNw3mLNkGZXWfwqpNB2DR2l2w50gjNOw5Dpt2HYMHSODZuIiAs4Fqc03T 59FKU8LNFRcqd1oIsGndfug5NjRs5c8nde2UhSvZhDynag7GHPdn7JuXQ+XZ2udvhs+G54aXw/PD ZhfgZxb8elglVCAZpnvdun0XTmLM7oezlsGgcUvgsT6zoG3/Gjx1iXm+S/F4Q9xohbucWyEZs93O TJFr9Kw16WaX0XOMgMfNWZ9RGtl4ePOeE9C/aM4DzgZCBZqm6OnqjiQsUNPJrAJD4MCBAzBo8MDE eL06+GRv+Hcv/A62bE6d7pNrb77x4nX4eb/JcO3m3YL0fplHPmHepzBsXH2k1nj37n2M4b0Jk+au hTenr8GDHMrwFKX5eI7wMlzbXQctB9RDhz6zocc786Dn6AXw4qhyeGPKchj4YQ28M3UZLN2YOthA vpgIy23Ur75x6w6w84nZdQfz+vzzL1Ae8gHcxr/ZxWYUosSd2/m8N3M57rBeyTeFFdJn+eZD0Hv0 vEh1YHLz10xuonvCESh2YYeklE9nZ1LsD2pp7Oi1MaPHhDfGhNxhk+3AgQNh9JgxXLM311cTEvCz Q2flOttI+VUs3gajJi4xeuYaykOOrVoPb01fDa1emQgPd5sFj/aphdYDFiH5LoFWA+uhDQpptB0w H94vWwON5y7zQc9dJE8c/vA87t9PEavqOnLmInR7bwH0/3gJ/P71aug1pg53TJfDC2/Mg/4fLYWX 354HL769AHq9VwPzV+7ixBzlql2zC55G2c3ncVbCMyPB/m1/VDMVut/F71XPG/7+7PAyKK1YFaUo RvcSAZvAFIeAQxxp5MpWO59s2ZxJurpnVd9nkk8Q1tlKV5GnKOd45MhR+M1zz8Nnn+s7SJMmku97 PMIe2Pl37tQJevft7dOSzoWdnICHzIQvrIMljuEa+6aNn8KnGzfCfut4O2bHSTze7sL5c9ykk8dP 8P9fww1wt27d5CfwbMXYx2x577MXbYXXDAj4LhLnaPQefz+qEp59dS688vZcFMxYDD3fnQOvT8Hp 54/qkMgX4earNTBq/ELYvv+MFmJ2/OHWvSdgL677nkTFq23498Hj5+DtKYuhQ3/ckIViHO2HrYSH +9bDoziV3ap/HbTqWQ4t//ARjJyyEj4uXwunzqk3CIbVK1vzvnEbvewC+txGmdDU8CTeK9EErI7l jSDKgViqNh2532H8rXNyj3XMofSMs4lI2BAmi4LIm7UaUDTE2bXN6lPRoccubKEpK89bOPXJniaP S6xDe9KU76xi/elVOuEO5fcWlvmwP95XM5Wa3anv2LmDK1t1w7Cj27dvZyOrnKUpDiom4zmt/+W/ /Bfoj+vA589dyJkNdkaMgJ9BAmaHDLDr7NkmeP311/kxdjOmz8DY5X1w7tw5POpuBsycORO9w3vw 9C9+yb9joV91dQv4+3PyxAlnE9kZJuO5pQF1sk/A1q0NOBX7BZzBU3t242Hxn332Gepun+AkvqB2 AVRUVPDnWIz0SdTnZrMAu3btgouo021fs5CATT3g23cfwA2M6/0MPc+buPbLrns4Vfw5KqOxi00h syto/8BNJL6O3cdCuz7l0Kl/FXQeNDcVooTedMf+5fBwb5zKxnXj9oMXQ/t+c6ETqmW9MW0VLFi9 Ew6dPG+lnw26ynnzyHqGRUjAYkhOuCiHuC5rh7iw/8uKS06UT1hokSckSBCt8JAsHgsoHjPIlUOE KyCPTIQtlIIWuhAmZo5qp3TatqWOIbTDqXxhWAHpunbrxFE0IWO5tD/mV1X0psZ88D680r07bNr0 acy55Cc5u2y1eF7r17/xR/CPP/ivMBMPWr93927Od0LLBMwQYefJXrlyBc5fuICHU1TBmlWr4WxT Ex4EvxRWrljBD3xnfy/EM2lvomTj7FmzoXpuderYO1QhGzN6NNTjmbPskPhKJNjNmzfD6TOnYQYS +FI8CGM8nkbF1vPn4WHx7MD4jehts81oU6dMReWwKTBt2jT0rq+lRcBRavQETicfb7wMB443wpnz V+Hi1Rtw7MwF2H+0EboMLuNT1p1HrMaNWiu4t9sRY4KZp9sJp69/PmAmvDZ5GYp37IYD1gESSd0U GAWzuO8tSgI2FeXQC2LoBSxCRSfETl+MmZW8XCeeFe+xQ5Psyg3Ng90YUdjCSGRDSJfboiAwo3TC bFN6/GrM9eIomjrShFfZZcmW/XG/mHZnxtSt3hvzXtzJ5zU9ewqaeXkr8JCI3zz/HPTu08fxynIZ jqQi4EmTJjlHMo55/30Y/d5ojhcjzV49eqOXfA5PierHCZh5luxUqBEjRnDPlf174sSJeHj8KWAD DHa047y5c2HuvGr0diuhZn4N7N27BybhPXULFsCaNauhek41zMV7Dhw8AFVVlbBhvXcXMPOATaag o1TqpWs34A+vV0BHjO3tMrgKOvadBT8dPAc64g7pdj2mQBv0bFlMcKeRq/H/KMQxHNeUByyGnwys wvCkrXDY8nTZgR/5vL6IuMbMbGVT41dvxK9jnQ4OiSZgUQAjUDRC5+Vp1vK0BGiRks6TTHl3mphZ X17Ma8PpX9XZvVpvMDNhC5W3zzBUClpoCFgWHQnDPRArscXmyQOOzf503r6QZ+bXzOfn7bIrE++C EdrnOPVZKJct1CHa8wF6+akd3rnt0K/fvIVrwDOcKWhmE1PpOn8+NZW6BaeS165Zy/9m6mMV5ZX8 b+bhnsKpZnZA/AIk0hXLl8MDPNOXEfD2bdu4ItlBJOwm9JzZuvLatWv4SVGHDx2G9RvWY5prcJr5 ApJ4HXrbV3E6uha2b98Gx44dg1N4NKR4RZmCNq3jo6fOI/nOhLZDUGYSPVymcsWmldsNQdJFucm2 zOvF/7dmIh0DFkDrvtXQCaehf/vaHLhy7ZZpNlm9r/HCVXj5nfnoxZufysROd3p2JA6CjpzNqm2m iSebgEEhpmEg/iASjkoQI5CAEdnAdU1jAmZk7R6CIFeYbg3Yp/ils0fRArQiH4o1YP64xpuMItYR 7xowTmGjraqDKXxr8Xmw3/SlM7mPEW7PHj3g3NlUR5HJBh+WRjVOcbLrAk6r3sN1zMOHDkH9wlRo C9Nstqc87b/ZdOr5C/Z63pfo9aXsmFs9Fy5iGnFcsqc7fARKVX5YD+/PPwTvztkN71azzx7+eQ8/ o+fi33P3wRj8jJ673/m8h/8urT0Ik5ccifg5Ch/VHcaj9crhywI+sSkbHvD+Y40YD1yOWs+ruKfb HrWeO76KSlgoxtEWp5k7D6iCn/afDgM+XgSDP5wHyzfth9WbDzhhRnHUf6Zp1KzaDT/uPht+jbum LxsMClgdv/B6FfykzyT4CsVXCuFKOAEXAoTp29Cg8n7TTy69J3O4ozc9A5vnU2x6lh2oEMd15swZ XMus5F7bjBnToRzXJetw+nTYsGHAfmOKVNNx3ZFtPGIDmfXrN+A65FTUmp7Ep1WX4UEK0/FUo5qa WuiDWs5sWjUb19btu+HhZ9+AQdMaYFT5Hhip+Iwq3w0jK/BTvhM/u/CzG0bhv4fN2gX9J2+DAZO3 woCp+JnCPvjvoM/UbdBv6i741atVGQ1wsoGFmGY2CHjRut3Qtu9cXONdxw9b6IjeLiPfVqgB3bbX LKhH5SvmJX/xxec4O5DbWQlTPEvGzMVp8UW4C7sWfoehUGynctBVWr4afvTSNJg0v3CEPoiATWs7 7vsKhfgKxY648U14emwTULdXuvFds+zKZAqakSwj3VmzZ/Gp1bLZZbAC9ZhZXPHKlav4euTOnbv4 PctwKpXt8J2Lm4MOHTzE1zPfevNN2I/Slw1btwJbH2UbjeK8bO++orIC2rVpAceP7osz+cC0rl6/ Cc8M9k5BswfYdLONvZwAs1f3WzYMj38K+it4byqe74vTy0yUo80gDCkagjHCuO77REkZvPJGJYp4 XMtGUWJLk6l7dew1CdrhtHknPCrxkZ5V0P/9WnxP1J7tSpTTZLu4W3WbFmnKOjaDNQklmoCDxRWs 6Wlht3G2wWTpF4PgQ7ZwImzMkWWhKy+9+CJfW2RXJlPQF5B0l2M67BAE5lmzHbwnThyHCePHwZEj R2Aaerfr8EjDvRhyswV35LNp6nW4Eegoxh1v3rQJFi9ajLt0q+AWrpdWz5mDG4filylkA46HH34Y WrVulZX0dcifxTXBZ4a6YUjsPjb9zjZOHT58mD8mC4TcunWL48Yu8eQpRtrZuOL2gBlJ9RszH1qg 59iq33wk3dnwwmuVsGDtHtiwnZW5MKZng7D8dMcRaI2nMjGvna1fd8BNYo/0rsJwrcUYduXVqT51 7iJ06jOdh0/99tXZ2aiitNNMNAEHlxpDfZRHDqWNlf7BQvIiw84ojqP4eSsvDqpKa3Dlnw91oLRL F+jifKTY6jjKmcc0mMc7c+YsaN2qlWcdOBMilovzwPJk7Z28QcVla8S2F34Xw4UyudjgQrxWr14N /+dH/wf+01/+BTz//G9g7x4mg5gbEpB3QR8/fhyn6WfAO2+/w+N2V+GghQ0+WLjQSdwctX//Pgwb 2gA78JjFvfv24Dr6Qh7vy76rrcWjMy2d7kzwkZ+Nm4DZQQoDUdf4udcWwCxU2VqK5wDzNfACXgeX MXl76mJojc4V837Z+nVn3KndbsgyaNN7Nuw7lhJMYReLh37htTKue922fy3MXLAhzqrJOK1kE7CJ +IVFwmGCGw1sF25JSapDZ14z2x3MO/dS7OpTl2pDUVyCD56aZIfNW8SiO7s4xUG2jWinc9oT7pSu 8dsupq/cGCXlKbescDGMLk7stLOz2EkkteObYSzGUzvkKR2laH/v186WCNgzwGKE7NZVxm9GASTA zvf95dNPw49+9COuzFQsFyNg5o2//vob0AlVsL797W/Dd77zHWjRsiV649O4ulSuLpmAp0+fBo2N jRjvu5JPv3/88cd8ZmDx4kUY7zsDZmEs73bcJV02ezaM++QTbiY7EnL4sOFw5PARPq0f9xX3FDQT HTl25hJOo3/BRUKSdjEP/umB07m8JjuruAOuYT/OYpT7zoOhH9c6qmasXG9NWQIteldDOxbH3Hc2 hiBdLqjiFgkBK8Q3mIckHEGoCofxCG4I4TicbOTjC3VhMhYRisSiOrtXFKHwiWnITULyYpWKX4ww NWcA+2wX0zcJcfLZI553rBPDSA1QUiaJRJkaKHgEOAJsV4ZKiUQuesDyDEfePPN432l7d/B9nNKs X1QPrdu2ge9973vw4u9fxKnitRjuknvN5DhLyMpXt6AO/uzPvgPf+rNvww9/+EP4yZNPohDFZPT2 U95LnJ5+kO0yAbMQoir0eMePH4/T75th8qTJGDa0jicxDgU0ysrK+Y7xRbihbfmy5RiCVAuHDh3k qlmsbq5dT09+McjGuD3gOOsyH2ntPtwIbftUQHsen4zeL4qFtOy/EH5aMhWuoxa2fVUv2w6PMvUu JOeW/epQonNmPswNzLNoCFgW3+BTlI73i1NDIgwqoQidgEOYqISGgKMIPvhryFq/duwXRCd09tiJ 6MKgrN/1IVbePL1w6UQyrBkDYSrYIVAHT4GMre98Nji2BaTH7wnygNnPKEPq0fgsuPfN2CCbgFhY UM28efD007+Ev/37v4W/+qvvwr/8y7/wzj6pl122FcuXwf/3P/4HvPXW27B+3XpUlbqRU/LlLUqS omTfnT9/gYdmsevO7TtwGuN92SVKaNpx1Sw8i03hM0+S3ZeNAyXi9oCT2m5su/ceOc3XdNsOqkfP F5W6cOq5HU49b+Tr1+41vXYDtOw2nYdZte4zF8qXpE7cKqSrSAhYJX6h94BdyUmBWEIIWBagcDxa VpuqZyVPM1DwQdci7DSEtNx0NAIaIQQcWA6rLL6pX09ZNLKPvjKkyLLB8YoFnCIKo7hJBxEws6t4 1oFFsYp7d+/x4/rYbuSf/vRJ+G/oMe7ff6CQ+pG0bfntb36DIhXuYCJXnq9tsIqA0y5Mlh4kAvYD y2KTW/aeA51GrYdHe1bAu9MW+276Aqeqnxo4DX7caw482b8MLl0tDAER0dDmQcBYYvUacAQCltIQ BSHiEKwQK8W3rqwSHJHs8awBp3YpaT1Co7VsqTkr1405pwZshJKIVsTJIwMqTCUHpid7wJ5NWJbO dJY6wUJI9trVayjuvw2effZZVFc6VggmpWWDuO7461//Gibj1LPtURIB+yElAvZicvX6bXiiz1RU 8FqOu7hr4CXcwc02lsnX22z9t1cVP4KRrRnfQ6WyQruSTcCFhibZQwjEjICKkN555x34YMwHMeeU u+Ts3dRM0OMHP/wBvIme/bVr13NngJBT44VreO5sYZ8HPHfFThgxwe/h5QWwAsh0xoKN0LIPSmO+ tgEe7l4Bg0vn+6xavH4PtO5VltohjSIjj/SohI+zcJ5vpnAQAWeKID1PCOQAAVG2cTNORz/y8I/5 RiD7sqes7XXKXHuSMgSiPew32Z79B/bDQw89BP/1Bz+A0g8+wJ3PeMRiHsJgLly5CS1eKIWPKtfD J3iQPTvMvpA+zKYXUH951ES3rnPQ3Ao2CxZW1KX/VGgxoB464fpvB9zd3LJXJcxauNmx+dTZi9C+ 5xRoiZ4vI9/2TOcaN22t2+ZdIy6EQhIBF0ItkA2EgAECNj9dQDGNwUOGwN/93d/BkEGD4RjGrhbS pTpswbaP7Rh+A8OP/gZ3df/5n38HfvKTn8Cq1as8JyHlsiws/rV2zV74ZM4GGFegn5mLduA5u/Ho b+cS22zktRI1qdv1wdObHAEOlM/sVQ7zV+zg2d24eRd+O6Icp6YX8BhhJrHZGrWtfzec7YDOTWx5 lHITAUdBi+4lBPKKQKoD+eLzL2ErCj78/sUX4Ht/+7fwD//wffgVrqWOHv0eP+JuHe4oZsfh2Z5n Przhz/AQ+I/Hfgzvvvsu//Ts2QvaYDjVf/7ud+HrX/+/4bvf+8/QoWMHHr5z43pq+jkfdua1OjPI /AHG8B7FWN579wvnlKsMimP86EuvlcOjJQt46FEnFl6EU9GDP3SnoHceaoQ2vWajROVSVMhClSwk 6sf6VvHDJArxIgIuxFohmwiBEAQePLjPj70bgccVtmrVEr73d38Lf/KnfwJ/8Zf/Cb7xx38ET//q lymyxvCYfBDbGQzJ+eNv/jH8h//wNfjGH30dvvXtb8F/+ou/gO//4z/Aw48+Cq9068GP8bsqHDxP lW6OwI3b93Hn7woYMX4RXLuJ0/fN4Np/tBH1nGdg7C/G/6Jn2wa1rH/SdwqW33u277Sa9fDIKxh+ xAga73l2yLSMtNSzCS0RcDbRpbQJgSwg4BAqTp+ywxWWLVsGb7/5Dvz+hRfhySeegB//+GH4/vf/ Afbu3pMzz1Im+SGDh8DXkXj/9d/+DX7x1NMoMfk89EIvePR778HC2jo4hVrU9s5nMb42C3AVZZIM 79q1+6BD3zJ47tUyWLXlINwtwF2+cYLPwoh+N6oKRTVquQZ06+4zYXWDPxxvKp521KL7LJyCXotr v9VQu3JbnGbEmhYRcKxwUmKEQH4QuI0HBJw4fhS24WEKK1eugO49unNpR3YSErtYh20qO8gIUbyX /Vu3uctOVyTg0tIPua7zj3/8Y5gyeQocQCnHo3h4wdmms3D79m08i/XL/IBUhLnOWLgJvcLpeKRi NdSvy52Gdr6g/LiMhR7Nh1YoLzl6xlKfGeu3H+F60O2HroC2KFX5BJ79e+de4YUf2YYTAeerJVG+ hECGCMgH2ovJ7dmzB5544kn0QB/C04/SC2E5f+E87ETdY9NrA56g9Itf/AK++SffhP/2gx/CsKFD oemsHZTuTyUfU+OmZUnKfffx5J/RM9HTw41Gj5VUw0tvzIbNu45wda5iu9gg8FeDZ0IrlJ1s3X0a bNt3wlPES9duwuO92Q7phVx+koUgtURPeNycwlWNIwIutlZK5SEEEAF2YtHCOuyUH3sM/vqvv4uH ijwFVdVzoLFJT4gMONZx79y5A9546034h+9/H77xja9Dhw7t4b133oX6+oWwHU8BOnzkMD+Obxuu QdfW1sIbb7zB16G//ad/Cn+E677//Z//O3Tv1o2fDPQFCv/blzhgCBo8UAVGQ+D0uavQbfQiaFGy kBPxS+/UwVr0BPkJR0V0HTh+Fh7rM4uv7f4YVbC69J8GD+yjB7GsL7+Bu5/7zIPH2e5nJF9Gwq36 1sDUeSkt70K8iIALsVbIJkIgBgRu3rwJdbUL4Dd4xN8//OAf4c+/82fwX1HG8vHHO0OPHj1wPXY0 fFT6EXyIcbivj3oNnnvuWXgEp42/850/h//rP/5H+DqS75/j33/yJ38C3/zmN+GbuMnrb/7mb+D7 uOv67//+7+G7//mv+Y7mb3zzG/BneN8P/98f8tON3n77bdi9a6ezxhtDUSiJEAQWr98NHfqVQxvU Re6AClFPDqqGD8tXQcPuY7Bs8yE4i5rXSb/GV2HIESpfPY7yk61xbff9GctxaeQrvrzyUTmKbfSs 5OFJ7HQk9mmPOLTtNQNOni2sE5DEeiACTnqrJPsJAQkB0btkhwPs2rWbE+2zzzwL//7v/xu+9zd/ C3/5//wVkuaf4Uapb6CX+w349p9/G/70238Kf/Xdv4Yf/tM/QQv0aF988UX44P0PeRjRSy+9DE8+ +VN4FHcws41V//I//wUe+rd/hUceaQGdOz8BL/3hD1ydi+k6X7niPREoKC6YKi8+BD4qW8EPHWiH u4RbojfM/n5qSBV0GjQfuo6shIPHGuPLLA8pPTt0BrTF8KIWGIb0+1FlzuwKm2X5Zf+J8EjvudB5 5DoU52AnJDEMFkDXVwtb5YwIOA8NibIkBHKNANukdWDfAajFg+XfHz0G+vbpA7/t+lv45S9/BU91 +QX88ldPw+9+9yIMGjAYxo0dC8uXLsUD6E/BPTwS8e6dO9CIm7m2b93Kv59bPRcqKyrx2L65sGTR EmjYvJkfSn8bTw6iK38I3Lv3GYyYuAwe61/DY18fRoWodrgZqc2gZdCqpBaeGlwGdat34jnAyVsf Pn4G1a36VkDrgYuhXY8pcPyMV5ik8eIVeGrAdDygYR6S7xoeI9yq31yYUsDTz6ylEAHn732hnAmB rCMgb3RiG1luo+zj+XNn4fixY3AAJSH37dkNB5GcTyGJXr50ka8fB4kGsV3MqZ3M6jVG2lyV9WrV ZrD/+DmYOO9TJJ718LvXqnHDEko2voqEhHGzj+HmpOdGzoWNO47mz8A0c2b6z636zoc2fefA3KXq YwVPn70ET/aZDC0sFaw2PWfAIVw3LuSLCLiQa4dsIwQyRIDIMEMAE/D45Wu34Mz5K9xSNsCy1bHW bT0InUrK+LRtam10JTw2ZCl07jsDyus3weSaDcAOLbh9517Bl7LryAr491fKYfBH/oMXROOPnjoH T/SeDD/qMQd+PXRmwQpw2DYTARd80yMDCYHsIkA7krOLb3ZS/wouIfEuWr8XXn5nAbw2ZSWwkCTx Ymuj1ct3oteI68BIwJ1xd3CboXg4/cAl0LrHDJRsLIOO/Srg9cmL4fjp89kxM4ZUz166Do/+YTzG 9E6BqzfCz/Q9cPQMTlNPhTEzV8aQe3aTyA8BX+kG0zd9S/FpAbtx9qvYL37mrXAGrq68pveF48UO q8c8S2rwRN3me8WHZ/PFkEqeXwRYaNG5i1ehatk26P7eAmg/sAbaDloCHfH/YytWe4xjA6vLV2/C kE8wRKnPfGiN739bJOMOQ5diqM5aXB9ehruml/PvnxtRDdXLtgLzpgvtqly6DXczz8ap8yPGph05 dREuXCm8ssgFSDYBN9VAiXMoeyk0GFdPgd+IB9mH8rPJPU4xG6A0NEHr5oYaqMkVS0cqQ4x1Fpav 7vew52I0kSeV6/zitp/SixWBu7jJalb9FnjhzTpo3Y+t7y7EaWU8cAA/bJq5NSpAVS1mx/J51+Z3 HDgJP+s7Ad6YshQ+qVwDnUsqcSp6BUo1ruaayp1wx/Bjgxbx6erRs1bBuUvXYrU7k8TYgONnJVPg zSnLMkmmYJ/NKwHXNh5zgLne2AI94ogeMBJwqc0Wwt9NNSUoPIAeH35KhN9tsuZcxDq30lL/ffiT 8nkkptJSO12L7IUBgM1vymfl6rc7VsXzno5Xcx/35Hj5SnxkqcrfuV8mYUzfxsnxyBkB19jfu4Ma MV2GWwpDBSaq77SYWunocBBwU+XPvvMWiXn6KZvV9tp2uwMc7X01wuDOzkQgRKN6tuw3xs5jN9Yt 1oPpuKlgexgyLBYEmDe779h5+PmwefAoik20HrwSd/uu5YITHYYt59PLrVB68eeDK2ENrv3KFztH 9z6eUHULd6oP/nghhuxUp+JlmWAFSwPXh1n4Uuv+tfD0iBpYvvkwsGfyfd3HU5+mzN+IGwMLf506 HayKj4Cxk3RI1+rQbLLweHaMfITezenMpecZedmE7d7fgCo/KQKS01TmrSNgnbdpd/TO/xVeqco7 0tmOlOTzgBnpacrvkrFLWGK5gjERcbVx0tWJS+SBXre2XEi4pcK0uoCbzl5n8GUNwrTlEqbrxbZh P29Uz6zeI7UnEafUsgERcDrdWvE+w6ZWR01aBh2ZFztoMR5KgF4shtx0fJUR8mpoOxCVsN6aCxev 3ISmC9dg5oJP4cLlGx5ALl+7Ac8Mm81Vs9ihBox8WegOC1discOde02AnYfOwBcockFXdhFIPAHL U9Cit+H1gq11UIU3wyG2POgm9Hw8U9m2Zy0SnuNte9PU5y1VopOWZJN9m0zAuHLL13DF3lhBwFrb FQTchN6VkvTEQYGDiXSvzz4XP8+0qfO8OyPhqZMwHBwPUpO/RXApWFwy9pXNN6BJEX/ofU61NaA3 ivPyVjrG9cxhMcdOe292+wBKPWEInL98HWYu/BSeHlaFJLoA2jL1K/Ri2UarjiPWoSb0PJxynore cBXGzpbD1NrNXDFKvPYfb8K44EpcP04926ZvNTwzvBImVK7k3ibbTU1X9hHIKwH7N2KlMwWN06Bd hPXfsHUz2yMx9IBd70fwQsWpb9HLCctbJljh36JH5ZCYnJ7oTRl4wO4UrcID1pZfUU6tF6e6V/28 0pMLKp/Y9rUesEu8DeJ0dIDXGZcHbOyZRsKOPODsd3nFk8ORk+fhzclL8EhCPP1nGBPbqMENVXXo yS6FR/rWQnsk5raDl2HYURlOSx/yFPxz3CFdtng7rvtWws8GlsG02o1wzGAn9AOclr5x6x7cuF04 n5t3HuTlzOs4WlIREDDbMYQEI6z3umuk7jqpb92Udf4R14Adj9EiYNVarCpvX0VZxKNdy5U8NuV9 GrJXr02qN2F5PDlnZkA90NCtY8qYeKblhYGKEpcwHATglPkLAxh5V3nGa8BC2/BNybMW56zDe9fi G/A5eTOgMXbcY3ZnC5y19jjedEqjKBG4ffc+LFy3B158C2UXR5RB93fmQvtBOLWMkoyd2fQ0X9dd CO27T4ZPdxz2YHAJd0jPQoEL5lGLh2bogNp37Bz8amgZPD9sFjw/fHbqg1PZzsf+TvUbu0/8XXzO /jvo94DfnhteAT3fqU7k4RP5IeBCeBVMvdVCsJVsSAYC8sxIMqwmK4sAgYtXrsN1VDhjko3Dxi3B qem50BpFNzqxjVqohNUadZFffrsW9mOM7O079+EOfqJedXjecA8kultI+rfw+UL5HDtzCX5eMhXu J1Bikwg4aiuk+wkBQoAQKGAETjRegEGl86F9vyqcgsYYYb5Ray10GLgA+pcuhMFI0H94oxqOnDwX qRSLNuyHgaULIj2Ti5svXb0Fzw6ZSQScC7DjzCMpwgw6O3Nhf3Ae+RH4yEW542xnlBYhkA8Ealbv gsf74/owknALPBe3Rb+FGMI0Hx7tOxfPzZ0Db01ZDtdvmh+gwQi4/4e1+ShKYJ7ncZc3EXDBVYvG oGxNPWeSru5ZzUYr4w1AUeokLfsjCHxEsUV1b1r2ZZqprg3lUKwkS0WgZIsfgTv3HsCCVTtR5Wou XxvuX1qPO6Tn89Aldmxf+5I5MH/VLmMgCpWAzyEBP4O6zw8kKU7jguXxxsRPQatFM9QbrJQbsawd M8biG1hZgRt8pMrUbapxv/cKLii/121WEkgpW/a7O7L9ohuywIfKBvc73JzEdgSXWJuMWJwt24nN BUWCBT/iqjdP1UjiH54QIHEt17FRCAPTiJWI6Svr3UBwJI99AWVdjAiggMfFKzeAbdY60XgR3p6O 4UoDK1N60BiC1L73DFixcbdRyXUE3NTYCIcPpXZZM8GQPbt34aYutYjHwYMH8bzo1MERt27dhHPn ok2DqwxlHvAzbAqaCNioHuO7KSDcRCmywXIWPSlht3EUoYlAkQexdAH2uWkIggue+73fO15vLu0X 8fKELVkCG2J8saasjIicsgppcIKSY7KDwo0yLbfc6iQRFCUBRxErMar33HnOR5uuwenz1+J71yil okDgcwwjWrJhN/zm1TJoN2gBV896elgl7DhwPLR8OgKeU1WF50v35s/v37cfRo4YCVeRZHfv3o3H XR7g3x86dBAO7D8Ac+fOheo5c4AR8fXr1+HIkSNw5fJl2L59G5w+fZrfu3fPHjh+PNwe22DuARMB h9Zf7DcYiWawXCWPRiYzo3SiiFJYJdUJK0T9XjloEMgxW/bzYkghUfw7B093Clpng6esKhIV0gsU olA8G6Xc/sYni6gIghm6urYTUYiViOnry6ERXonxzdi2/xT0HlMLv31zETTsPRljypRUMSHAVLLG Vm+Cnw1bAP/7lQroU7oIjzS8GlhEHQGvWbUKSj8qhV27dsGyJUthwvjxcLapCbZu2wajR4+GpUuX QlVlBSfY6uq5UFdXBzNnTIe1a9bCyhUrYObMmbB69WqYhf9n9zKSHvvxWDh/3uyEJiLgfLVMyWMS JQMz8YADxTcCvFrf2myePODY7PcQsCo+WFgD1tRFFALWyjaKdkiDglDZ0bDQINtuwf7QdhRCwIHl sOz3CK9k+P7cZWt9a/ZC19eq4N9fnAIdes+Ejdu9MZ8ZZkGPFyECN2/dhXnLGuBn/adDWzzI4aOK DYH6zzoCrpk3D8l0HfTu1RtWrlwB8+fPh0X19VCBpPvxR2Nh6pQpMAe93tu3b0NFRQUcP3YMFtTW cqKtW7AAZs+ezT3m8vIyTrwL8Lt96Enfu2em/0xT0HlsnFHWgD0endSp69ZQfUIT3AFUiCVoNgmF rwGj3q99uIFJ2hovMlv2i2vAfiy8m7DUa8CCZxniAaecYY0QRQzlFpupX9zE8k7ZmrSkA608sMI+ MUpD8KpyBB2ike4rtB093if6TIYWPWbDj7tVYWc6C3YeOJVucvRcM0TgyvU76A1/Cj8dUAYz6zZp EdAR8IH9++H6tevoza6EixcvwUGcdj554gQSaQ0sQ4/22rVrsKBuAaxfv55PSbMp50O4Zsw+hw8f 5lPOt2/d4h701atXob5+Ie4X2WJcE7YH/IDigI0xy+6NhbRjNrslpdSbMQJHTl+EF0fNhod+8zG0 GVAH/9p1PLw2oS4UEeZZsLU31hmytbbPPvuMP3P//n24hh0gux48eIAeSEqs4e7dO3Dv/j3YwzpK 9GLYxTbZnMBO9sb1a3Dz5k1Pnux7U+8l1Fi6IScIMFWssXM2oNDGPDh4XL0xqlB3QZMHnJMmEiET IuAIYNGtSUOAjfQHltZCmx7T4ZFeeKwcnufKlI7avDQeFqzd4ysOE9ZnhMgIlv19+84dPk04aNAg +HTjpzBr1mz+TG3tApg2bRpfq6usqIT3338fFZNuQ03tfCjD6cGVK1fyqUJ2sfTYWt/JkyegCdf7 mAfDvBlG5mwtj3lAzPOhK1kI3MYzhz/7XH0QAxFw/HWZ+DCk+CHJf4phQhNhv5uWIK50TPPL133F Vs59R8+htu94+JdnPuAqRw93mwW/wHU8Fmaium4hObLpvwY8Q9MOATl79ixfe2PX2E8+4WEkNfPn wTFcn6tbsBAWLlwIn4wdC6tXrYYdO7bDmtVroRzX7y7j9CG7GJmX4fMs3c2bNvF1Praet2TxYjw5 qgamT5/OvWy6igcBRsADClCIg01BMyEOmoIulLamO2c3G/bF6W2HpaX6PewZucxR788GZmKahWZP tsubQfobdx2Hnu9Wpzzf3nOgw9DlKLa/Gv7XCxNh2Mc12pQZAW/cuBG2bt3qEOjRo0dh3Lhx/JmN n34KI0aMgr179/J/Dx82HBYvWgIrli+DIUMGY7zmLe45Mw/47bfe5vcwD3g6esv1SNRsw83MWbP4 2l5ZWRkScxn0L+kfS4xnBnDRozEjQB5wzIBicsn3gFlsKRdzCBdK0J1KU1pqb/yxBCGQwH3fIVja DV/y8TdWPTm7aZ16Yxt9UnlEP61HEOywSEve1NOA5fCc8SuRm1bQgu0AjiCQodrBa4ytp+xeERIH poj2OJvYeFuwRT1SJ2T5jh8MKKcyFtjAlvhfS3WK4+esgzYvT4DWvSvwyDk8jH34CmjZdx6eglMO V67f0prBxBHY1PDnn3/unPPKQjxWYfgIu27fvgMffPChsxbMCHTL5i3QeOYMTJo0id/DwkRq0cNl sZ3sYumtW7sWduPGGfb5FAn+Ok45b0JveMeOHfw75j3TVTwIEAHHX5fJJuAoQgkBIUFuyJIlMCEI RrCjDnHmjsfDqkNeUoe7qy/3kHj+uxBTGyjmobzPQJiDCWMIO3jZlKPvUu0mFsprIpDhG1hExFYp QiIaGtEeNrBw6oC1CSTZki7CYETA065rVTl1BBz0TPyvZHCK9+4/gPXbjsCoT1BWsPtEeHrwTLh0 9UauzaD8miECNAUdf6UnmoB9ggc2Poo4Ta04gkhIdkiJ4jvRw7M9bk4kYVOozu8uGYfaYj0Tep9I 6lbZHXLEstSoBgYaAlYqbTmCFG5okKfsTp5CqJE00BCJsRTxChTbcOpPGNQo60KTn/W8b81XIODg cvrFOLQiKGHxxfG/q74UmZD+rTtmsZI5MIeyKHIECtUDJiGOfDU8j6eamtZNTTkqRCO0XprqXvXz Sk83jIAhRbwNtm0WQWXHA2aJp6a5S3EjjB2q6qmeNAjYZJChLk9YPQheveQBBxFlkNCFLX3JSFiU wPRMRcsDF2HgZT8jinEE2pKvtk/5EgI5RoA84PgBT7QHzOlGEG5wtYVVqk26dVdDAma8jp26s95s T3GGEjB/0NU9FjxVOy1xDVMmilDRD1X+QTalQ8C6sgvtUbcGbCxkEoWApXq38ZM9X+ffhh5wavBi 1bE9la/CK9XwcJCjHOLE/5ZSioRAASBAHnD8lZB4Ao4fkuSn2KDzfpNfNCoBIUAI5AkBIuD4gScC jh/T/KZo4pHn10LKnRAgBBKIQP36fTD4owUFZ/k13Avx7NBZFAdccDUTYFCxiTMkCXuylRAgBJKH ACPgZ4fNhh0HGwvqs2LzYXii13gi4EQ0qSgeYpR77cKn80wigCMjCQFCoDkjcObCdXh1/HIoeb8W +uOH//8D4WN/Z/1u/1Zi3WM/x56Vf+P/ltK1n1P9JuY74MOF8HHFWmDx7km7Ej0F7W78CRC3wBpx 7/OLWbAKMz25RinEoUtfbAmMlPHEI3UIjxviY+/AbcB73Qgia2OQEN/LYpNLra256hOIJGGRpLVK spcQIAQIgWaAQOIJWAw10YX2KIUfwkQxWOVLO2B1QhxRhCVswrd3O4fazHfb4kcQlnBiaaXQKjt0 xg7FaQbtl4pICBAChEBiEUg4AbvCCTqBhzAxi0BhCIGAdUIckYUlUgzMQ1iakFg9WhlOaIsrWWnH NLuk6qpdGduU2OZJhhMChAAhULwIFA0Ba8UZPF6iQs5RJ9Ch8IB1QhxxecCixKMjKGGHFHGJRRTX 0MWlCm1UqxBWvO2YSkYIEAKEQOIQKB4C5o6lu57qiFvovtd4t+JzsgKUUogjIF+nNURcA+bPMcLF wwTkKWr3sIFU6iqbiIAT9x6SwYQAIdAMEUg0ASemvmhndGKqigwlBAgBQiBXCBAB5wJpIuBcoEx5 EAKEACGQKASIgBNVXWQsIUAIEAKEQLEgQARcLDVJ5SAECAFCgBBIFAJEwImqLjKWECAECAFCoFgQ IAIulpqkchAChAAhQAgkCgEi4ERVFxlLCBAChAAhUCwIEAEXS01SOQgBQoAQIAQShQARcKKqi4wl BAgBQoAQKBYEiICLpSapHIQAIUAIEAKJQoAIOFHVRcYSAoQAIUAIFAsCRMDFUpNUDkKAECAECIFE IUAEnKjqImMJAUKAECAEigUBIuBiqUkqByFACBAChECiECACTlR1kbGEACFACBACxYJAfgj4SjeY vulbik8L2H23WKBNdjn4OcOlDckuBFlPCBAChEABI5BgAm6CmhIkCTy0vkuXEqipqYGapgJAOpdH D4p5NcRQ/rhszzSduMtVAM2CTCAECAFCQEYgrwRc23jMsed6Ywv0iKN6wEjCpTXAeZcRUE2pRcil YPtuTTUl1nddoETH0Njhl5RY95VgevjvFLGr0yktLQXuHDbVQAm/rwv/N/ca7QGBNRhQ5e9+56Zv AyHeb+fThOVyTMc8S/EfvryilB/vLS21cUnZ4E/PKiPH1sbD6xWrbDXFQMbOLn9G5RJat4yxsh1I 9cfKyTBP1aG3vSifV+CoKpdRG6S+iRAgBJodAkVEwNhx2lOmtgfFiFUgXdYRKmdVGcFYP/DOMiQd RhL8FpXX6fHe1PmzPJSDAcleOx8VAfOWKuUVZrdTfqG8mAg02KMVKT1nkCGAJqYhlsHBRGGXsg6C PPZ0yyURsJOvrh3INnhwYeMrq71o6oUPTBxsLBwVaRq1wWbX9eSnwPVdvwZf61qflcyzmXZWDE5w okfGdIUxR+ItQD7qr4gIWJiCtbxE0fNQeTVO9amIh/3opCN4oB6CsabBRVYX0tLl7yFUD2mo8zEj 4AjlF8trlVFF6KxYUW2V09HXgQI71w12B0oioUWoV9FuYxvkqXMnvxpnRoWbaGOmxNFbLuM2GG9f okmtHrpK5FPftSuE0lF9V0iLs46MgYe+hoTHPqYJiHnVj4m9k40VZtvWdPGJ1ZiAxEzsw7rqGhej meSXUdmPwJgxoa1WnUM6tqXzjGH58krA/o1YGU5B22vAqg4yCJAQAmaejtbbswhZ9LZcp0iYxg0i WoF4lPkI+Xu8eN1aaVj5FaSmI2Cvl2fgFSo84MC9XBK2fjv8AwuP56+pV8/AIWxN2rbB0AN2PWOF bXJdhuVt+KLGcxsSsESGIgEfGfNQiizx85DVGXOvgH/3kEOGqvsAsFN8yL2H2yt16h6vxfrNTQtJ Xs6LETB6Oqn83YGCKn8xHU/XLAwC+BhA6Ew96eBAhPfpmGfXrjYO6jy74r2etGQiNkjjITs/VcVi enY9iAMX0V7XBrW9drJh9eekY9eVhZdd/+q6tlJn5cZyyG1Gh7GTF3vcoIy2DT6IfO3K325Vbc2H hVHbwDaNbdAePwbikcZLWtwEjIC4a4rWZi3VRq0wAsZ0TNc7ZXJQ5a/zKln9qfLBb90NZ2yNWujk XbJXk4Gy/FEIWLJJ3BmttpWD7pnqV9mgWit22m/YwMKgXmWMjWxIYw04dG3ewNaw99Z+6bUdUlgC zu8pD5inZ/UoDgFjhyimzzorx2n1eKXe+1haWudW8oB1BOwpl5SXQ0ACyYn32/mz/yvxkb1oTTpO eRkxuAWHeou0ldj4iNclZuM05LpjmAmAOvjq6kdlr5xmQP055bbr6qExOJRyCVaFtducRKzYeMtq C2EYG5ZR27YMyqNqa9zuoBkWpd1sYGm9C1IdBLZ9w3cyPwRsaBzdRgjkFIGC8lbdksdNwCxlm7Bs Aj4yZox3Klr0MjReo8/zUZCJOK2pJmBpLU/XQfo8ZtszT3nr+jXBVAcqE7mqvCkPWJhud/LU2BhA wA6HOmn48VXNourK4ftezjtVqeppZE/9acoieb52G3E8cWlmxEdmYv5Wfjqb9WV0PdnAtuUpj7rd GhEwn7VRtQ01RqL3G9r2DTsuImBDoOi2ZoBAgRJwfMh714BTU3LWNGvQ6F7yOEyXc32EIOTheq7R CNhDkAIwoZty7LzDvDPRY7YJLcD7VE9FC2vXYWkovFV52tnOQ+2FK/JK0wNmgyXPTIJY76pG6PG+ I3jAYc+FNXiTGRlFW1MOGiyvmGNr4AEbt/2wMli/EwEbAkW3EQLOUoC4DJAoWII3YWnXt6SO2F1L E9eGw9eAU+vEludqTXVqPTveMarJRZW/joB9635CWcR0uuIMgL0G7OxFEjxK9fqrbi043G4nP0X7 8Xha0nS07XmJa8Aqez3JSvWnLItcVqt+1HVtpc7S7ZreGrCujIH52YVCW8XZA/2eBG9bkwk4qG0o MeITJO7Mi7gvIt1uoPkScKbeTibPZ/JsujWdpOfiEBUxLW+kumjAOGFSBzOFtqDv83n88Ye1yCTo XU/Ncn65AD/MQ86aDf6BZNayynLCiSdg5UYglUACAuney5Sz1DuUjYUUNOFGnvhetqvWEnWwNy/5 Nh/JYhBChRuLP3jKphYciSQIwnYFRxAmsctsJH4hN2gFRiaiKo4YiqquQ+tfwMiux4B6sE126g5J 2KisBjhm+f2m5AMQEL2ZzDe4hUOd6/zCLcrwjrwRMPNEDcLnMixeLh5PNgFHEkgQQ4lSu4rVohyS pKOUhyjOkBLj0Ih9sA5dJWDBalW3y1es8bTLJoQKucyhDKMKEgRJR5jEk54OF7GMOozEcCAbq4h4 +AUyNPXkpG8i5el6wEFldYVaQgRecvGGN4s8rKltcQdvTsudTI8sTuGJONPSVV0u8shps8HMEk3A vnAeobN2uC9UTEOG3FBIwcorqtgGz80z7akWpGhCbWvPZGeA+EOY2IMuLW04VEhYlkl6YTYxGPT5 q0RFNGIooq3pYOQ8HyAM4jQRkYBde4zqSmVnrt92ll9QGEY+7IklTx0BWnHPUhyxnaUn1ErGRt4h K/6uCNnx7ap2M0lPxCQMFxPvU3dP2LNRBFDC0gorh/y7Kj2TPOIUEolqcwb3J5qAtQIZqjhXjwcV 4AHLXqNujVBF9pIHK8fMBgp0SB6e1rPWlC2K2IXtxadLwDrbIolfWAMRJUah9ZeK7/bJgToEHEG8 Q65fuR48L5eagPV15dXTlgeFGby3aT3q33RiLnThyVAWMLDIKUw8wpnm1W3ewXTChA4CxUJ8W1Tr UUTBimqVO2hWhofYJiIh7tUTn8qexQ/eYwt7uCFb1vqtuI6sIIkwEQzVtLey/BLeYel6hEJwc5lP jUzY7csh8wlSqNuF3QZcGwWRCitNWRAlaGOf3F5U5eJ5yvaqhE5UQiKqdprWm5O9h5JNwNyLcg9b ENcFZYEEBqFWOELAVyUQoRazcDtXndiHxwvUyFUGCVLo1oBVZQsTHFGvAUtepTD4UA4WBNlKk/TC bJLrxNWyVouKGNe1RmgkqB4DhUGc9qEhYKlthaqiifKf2Xu31SlLIRymQheexGQPyVBYQS124Q1f CRN+UIuF6D1gNQELO7Y9xMm+t8OyUjuZXbEFzMOZ4hb/tpCRduY6eAWEzKg8cGX5VR6pSbos3EeY llcJZaRCnCTJTzFMSB5YeDaveUUqWFpyGJOyPLr2IpKt2OB8BKwQS1EKiRS4lCmWMfEEnOv+i/Ij BBKNgG4KOkTowltmr4CBXlhBI+4hd+qGeevFQiJOQTOCsTWq2f8FkrJJsR49R+4722Sh8qAFeU4z EYwAsRPJ+/cKPUiCERJRGYl0pFzJ1IyATGg+QQp9bHFYXuLvOuGKwJjtoClon92p+uFiLwohESfs Le7g3Rg7ACLgGMGkpAiBgkcghIB1QhfKctnekOgxWUSiEo8QPTCd2ERgX+nxviTvVPmgMAXtFEAR ryxNJT/Epp6dQFO8H6ep6x3JTcFLtglN57nJ32vtt4wLW+vUTXlL6XpmGkw8YBsbpz4DxD1CPWAh vEpXHl17MfaAFfYJgzjf1L6ETyG9o0TAQm3waUiK8yyk9km2xI1AGAEzPylEbCBsDVJ3gIDJGnBY 3uo1RYMpaAtHUQfbhVYgVcuT8vA595iFsBdnbVE8oEIT1yuRUNgat6r8yrXRgHQ9a8BdFQc7SJ6k cm+ALQit2NwUJEoie7e6+tQJcSgHgL4paD0BpyYtUNISBx5jFAeJxP06ZZpe8gnYJKQnDCUTMQaT e8Lyod8JAULAuxO7SPAolrjUIqmOxBQj0QTs2zjDNt+gwEZK/KLUCeNRbmYSq0je0SyJMpht0ElM nZOhhEB+EQibas2vddFzT2gITPSC0hNxI5BoAuZgSDGr7k5aa5eyiSCETMAqKUTygONue5QeIUAI aBAoRtEJqmw/AkVGwCoBBzdMyZaF9MhFiiQeJMpABEzvDyEQPwK6Nen4c/KmmCsvPFf5mOCVCdbK 3cmFH+ZjAks+7yl6ApYPh1eCrRPVEL1nIuB8tlPKOyYEdBtoHnrIOouV7Zp1wnTcjUfKzUMqQQS0 03MvbgJSnXvLipORMIhCZCFwg5NPbMI991eFiRv/awPvbtQK20ilFKqQcbEEQrT5eMhSsZFKk55P VMMyPx2s7c1ceoGMcCEXO41M8Iyp6RdkMsVPwHyWmq0J2x88iKFJqguJgJVrvkTABdmAyagICASF q1jbfj27hIXdp+qzaBWCCLo8dGbKRGNvPw7N2y8eESzi4b8/8JxdFhsrqmRp7PERS0CYjto+fT6O SpV0JGFwiFeAV5ou1qnRkl9SUwwnCquvdPGM0LyTeGvyCTiJqJPNhEAeEAgTUeAmiR2tE1tpIKgR cK/OA/blpzj/Vy++IYuBWB68ILDhjQeVxCyscgafR2yTjkuSOnEJx08eI4UjOfkE2OdgLpCxzj4r I70dCtEO27iQEDQzLISGq6wvdfm9dW2OZx5ek5xmSQScU7gpM0IgjwgEeMCOk6UgYEbKoRKJ9k7g jDxgRXynLm+BVLhtpmutdnqhHhvLQBbh0HiCYpUGeMB6kZGAfEQvk1lkC4KElVfCzWSwI9ezRypT 6QGH15dXbjMNPPP4uuQiayLgXKBMeRACBYJAkIiCzgPmVMTEDSzv0hXUUCsmieILXVHSMRMPWJe3 al0ySMTDvwYavAbsVJdEgKlJApSvdDxtV4zD9YJdrBxRjLDn5HwEwtOJVhiLdhh6wDLWou3qKWh1 /SvbmGCDKNRigmeBvDpZMYMIOCuwUqKEQDNFwOexahSimik8VGxCQESACJjaAyFACMSKgOiZqY7c izUzSowQSDACRMAJrjwynRAoRAQKTUSi0OwpxDoLs4kwDEMovd+JgNPDjZ4iBAiBTBAI20SkSjud Z+R0dDuBw/JTncmbSfmjPhtH2VmecaUT1X66X4kAETA1DEKgGSGg3CAji1REEblgm4fsDUlyDC/i qsov7DQlecd1Kn3c7IQhPuJOYu8BCFb4jXD8Hjv/tit7wCIdUzGKFE/ZG62sTVaMgDH/lC0hAiV2 e2Lr4REETpxNTxL+pni5WAsnN3nqwIuhamNd7MIgzejdSqeoRMDpoEbPEAJJREAbhiSLVASLXDih JfZh9RYWvhCZoJAkjyeqC3MSv08RrHxMoEPWPAwKP4yoraP0nLhWKS8x5MrZkasMsxEIX9ylrAlh Uoly2OlHEzhRiGkY4MXyCD4LV8BQG94VszBIEt+THNpMBJxDsCkrQiCfCOiFFmTxBlnkQi3E4UtP 8PwYyZkKO+hEJQKf53kJ5/haU8QuCaH3a3vDWgIOOHhenq5Vik6EiH/o8nVES3SiFQoxDV1YkhAa pqoPHYaBgiJOXnEIg+SzxRd+3kTAhV9HZCEhEA8CQR6pRTgeD8q+X+cthYlERPCAlSIVnucVHrA1 vcpsrkfvlzu+zCu39KyV4iK6NWDVkYJh94atp4YQcKDwhVwfurSElqEcEOkwDLQ9C8Ig8bTgokuF CLjoqpQKRAjoETBZkzVdc0zxneAFGq4Bc+skAtCJWwSKOtiEi16grFUtrtN68gojVRE6g3sDRTnC CFjCL/DwAwO8dDMSOgzDbPcIZug8cGHkpE6PDZz8YiX0jqYQIAKmlkAIEAKEACFACOQBASLgPIBO WRIChAAhQAgQAkTA1AYIAUKAECAECIE8IEAEnAfQKUtCgBAgBAgBQiA/BHylG0zf9C3FpwXsvkuV EoZAQ2kX6FLaEHZbhN+boKYE0yypgZrY045gRoJvjb9OkgtGMcsWxlW2uNJJbishyxkCCSZgizS6 IHF0KYGaGiSPppgqtaEUYuU3nVm5yicUlgYoVRVYti8de1XPRE1HvL8hxnoOxUVzQyHYkJbtqVAe WayB75L1KEhFSDzfEo0RTM37rWFhS3k3MKoBVryypVTWtetDXqEUnpwVj+0pe0Ccs60Clm57jFqE PN+fVwKubTzmFP96Ywv0iKN6wEjCpTXAeZd1ijWlSMaMkEvB9g+bakqs77pAiY6hm2qghD/XJUW8 QocvPl9amiJm9p2Xr9hgIJVnWH7u72zQ4BK96jltPh5Cssvs9YqVdsjltNDn3hsrPyuUlbbzHRvc IMDyv9mjurLqysiryc7LSjcoHeX96dQzlqmkxGoH6OU34b+D2oldzxwe514BX5UNdp3gb6WldpsL aYea+shen5DqDMfYMbM8I+wM8cBeUdZRG/rD4n59spMKiUZHKQqVqbBTjiTfKBZelR+zWHk2cYjs I4uHDZCF9ITw2DHBOLjw2S+FFvnwkOzThhZpwnrEs5ZV2KnaRiRJSQ1+4TKWqELW1SsFmrJFVM6S VLQY/WL9c2Uyj2paPW9zYx5yJTPt9ieqlzWHk7SKiICxU7VZ0ekMseMVSNdPaDYDSV6V5nlGHqks BOK3OmmbuAPzY0Tg2JPy4IOf0+fDn2MduDAScMrnyUcYMGg9N8EDlsjdM9CQflOWVVdGsecISMfF WHhAHnBErWdGotYzfHAQ8rxjQwC+qjTsunSXBxqgwRrQqbEy8+btzjHzDsmrjcwRtojA6Sh14hkB spM+OUeHgJGwXTUMqEd1LFl8wq89bNV7QH5yzC/PQhAF0ck+BslCqglYbT/PL6p9AtYi7loxDo/I CQ6QWJ6qSyt2opeUlLW2U6plYTKWKX1sv2CKnI9XXewh5wG1alnqZ0G1zPO3psxF9HUREbDQmWHH WYpEJ3poKY9H5wVb09lSx9yEHqrHaVaSk0uSYfnp0gt8zslT9PZtT1yyz2qY+vSkcjoNOToB6/II xMzOzzPDUOPMVvCfrbrzvGO6KWjTetYNKpzn1fXsK4tjv7+tObMmYl6h9unqw9vDxEbAjtqTRcSc t1JeiE1AeulCSTbRNlEh0egIX4jeoiO/GCLf6PCvOr8j6L17uMjxVr26zW6/zzSi0QULEcXQEbAu Hb3ohU5e0h3siARsVB6VSpeDkwYPD+G7JGks+ym0Cac1KqfQZa83NaOSyt4rwGETuEe1LMX+qTqy Lz4N3TzEO/JKwP6NWBlOQdtrwHYnnsZaI/dUQj1gzhR8+rtBnI4Oyy/AA9avOQfkI3h2Ke6ypsYj 2cGejE7A4jS9TJZKL1+8ycST1t4fQH5e3nL/FULArCyih+p4wFp8gwg4Pfu0yyO6MqXzveAt8Y5f 7PgErzXMw2RZuwcvKPSUhSlop19VEWVQGTweoJif/uAGpfRkBIK2y21WNtE71tvn8RpVgwDJgw3M W4WX7nl+b4CkpJRWuIyloQfMmddalpDdZW5ravo5dcn2CV4yDrPGiKScTntPwDPFTcCMWpw1R2uz lmKjlm9d0uOhuWvInrVBzlvCtLdV2WH5qdaUU0lZ67D2pjLRTjkfjX3izmhVeqr115TZaRBwgM26 MjrvgzRACFs395C9OI0ueMth+DkDHIWHyuzS2ezx9J0ZkogErMFKXx9Z6jkkj9TjZQhkrFsDVstO RiRg1j87R/1ZxwwKzo9YcmV+rNvWrAFnRMD8YAfrCELnEIeAskl2iLKNQWvoKhvV5Qk5KEIASvm8 /bs0kOH8qMA/qoylm71/3Td1SIbCg7U2WMknWnlkQ52jGMkDzlIvQMkSAoQAIUAIEAKEQH48YMKd ECAECAFCgBBo5ggQATfzBkDFJwQIAUIgbgRIaMQMUSLgMJx0O3DDnnN+9wqGsBhR/4YrXINl8ali mmEbqYzzF26Mkma27jW1O0r+LM2M68nUMIP7otpukGRWb8mlmEbcYhRRbfdshBLWWdMFOO7ypGuH /FxcdsWVTlzl0qWTFDsl+5NNwCohA7ZhyQo5EjclKTfZaEQTbIz8m7PSFfsQ43ml2F7OHSmxC8/F OnFU97IFQtIti1IUI0QAIqpYhk64xLOzN0K9RM0/lnpiO6HTEeuQsDS13a0XV6wj230UT18lbmHv WuUiG644gnIzkVKcIoLghmFHKQqDpDb1oG0edSQ7plkhBILFVG1M8p1zbFBucWe0LCgS5dxku24D zzcOEQthaSifdzYupeJ0Te0KF9/AjVBj3PCuSIIfEQVLVDHuuvziqIecvGsGmSSbgGVhCUNhCnWY iSWaIIMmhbCEiTioxT5kQQ3vLlpRTMPJnhGW4BXrRDYCy6INezIQgAgIFfKJZYSFbUWtF59HayCo kmk9CTvNI4l1qMRNDMKsWB45CT0S23NEMY3wcCRLIEIlGqENr1GpKSl6KvF5vkMbP0JsqKiYpBIC UYlN2AMQcSey6bNKoQprQCOmp8TMLp5WNMO6wUBMRF0nCk9eIsD0xDdSAx9b6ESNqV7wI4pgiU+Q RYNVLPVgQIy5uiXZBMxicdkhAo7KkU6YQiOooQlJ8Xmitq6lIgQmTHwjlZbs9eK/a1KJKr1fmYBS d+IzTFzEvCx6UQwDAQhPqFOIWIZ1bxN67J4jInRCFxbAZkIn3hAhraCKbgo6VAzDMiYkVjgSlrow MUEMRivykcU3XxdqwuM27VAgRzBDIyihENfwiFyECW4YesApr9fyxi373M5XUE5S2h4g9qGbgg6x W4+d6CEGiGJw7zVApENB5rIIiP75AG1lyWu2pTMZmarKpBdiMcFUIGMLZ5PwJtEmu/nrBEriqIcs vmKRk044Abudpy2gIU/VqqQeXa9REc8pQxjSsWsFKTzp+KedHe1qnQJHZA9YHZsaKIrh8ZClght4 cc4TGg9Y9Noj1Ys8ADFZU820nkIIWCvWYYMgYqlLS4A4HwQsyjUyU8IEJ0K9LUEz2Vhww5iAXXlE j3ISm4YOIVHPgEB+n9N81qTjD5XZNPCAw2KZjT1sleiHhEW4+IbXA/bLUDp0CWO64uAD47N99ktx yG6bC5kJ0cygxFIPkWkyew8kmoDD1ttM1k1daeaUfKXvCuvYuRcbIKLBE1QQMPfeFWu/QofOhD+i rGeryqJa+zYSgJBIL1AsQ+PxyfrHxmWRCdgE40zrKYyAWS0KB3vYoixKLCXsVO0jLwQse0N2b6mS k5TudYT4ldKTatEIpeCGQAzedV5FJ2etbcqk4xFu0NiuFfsII2A0I4pQhUz2gaIYOkztoutIM0Qk RbXmK9sVpUy6depAARVZ8EMoi05QJUyQRb0GrJNE9RJ6WD1kj1KjpZxoAo5WVLqbECAECgaBAH3j grGRDCEEsowAEXCWAabkCQFCgBAgBAgBFQJEwGm0Cz6lqD89wUnR9L40TEjsI/nCJF/5JraiitDw uMUhtOuRBY5d+ji4p2jpiph+2gUOWpbMSz4Bm2zQyRJ4iUw2CXhl20Zn01hIOJZuXTmRFR+j0XGL WcRompNUVIGOyDa4x+75Ho2w0SxytuIDucpHyNO3OzmjAkR4ON2yFnhbTTQByxtgZHEDY/ENWZiC 7WgNEmWwO2b5OUU6tqOs3MSkEgIJEcmwm6xx2fABpRiHou0r0wwroyd96bxltpNbFkXRbNgK2tQU tAGsATequaFPVniVR1XMOunJytfTZjBsqgbDulI2egUxYhH3iNC/5OpWY3ENNCgXYhYuYeJRdXiC Dg9JsXY6y4ILQacM2aEsblyvQqDD7oxVYiKa8mrrRVzDloQwxA1QKpt9Ma9CyFXY5iH39zyJZIQR of27jIkFpPrc5TAhF7Oyhgp0RBBeydX7mGgC5iBJHbqz81YKsQkWrJA8IUYcTmwxHkfoHEOH6lSs t9d5ULIogyY8J5ItqpYQqWyiiEWKoJSz59o0ZWz8WCnP0g0Q3wgMDZPqVA7/8QmdiHbzmF/8dHF3 lzu7jVW7nIV6VoaTSc+kJ8KSq1fZIB9dGIyBkEbQubYZi1kw09MVoYgoLmKLSrjHB7piIlrxDhW0 QZ6VQ/Tes4tdDPXiFYE2eOovTyIZiLdznG8QLpoZCDUBi2crq+ojvKymAh2mbdXgbYrlliIjYFek IopgBQ8TEgQ9vLrCFukyuO3zZ52OWRa0UKejE6jw5OOcbRsukhGlbIFiF0ITMheakMVPoolv2GWO T4SD2WN5r9YAyFWZEjS2lQQcEgceEtpkJsISy3saSyJaIQeFuIZOCIEbEreYhS9NIaQkRBgkiriI Y7eyvAFCE2EEbEtlOmFdKfsDhTccG1wy9oTrcFnQr+EB9u5hyQUhkhG2e10sF5MPlYKHdQRsKjqi w8gsPlglOBOx3mN5E91EipaAtcIJmgPdbW/aFvQIPMBdXqOUvEcnb40H7ApUBBCAnKZY8SbeqjBY CBTjsNPVpan5XSyjHO9re7g68Y2oHnDYfjebcBvQ++WR3Mz7ZtPQuthe1QyGMwASgA4hYDMRlpjf 2EyS03rA6oPnzeQcgw+tF80N3LQUFgNr5L2Hi4ukPGBzm7Vwq6ZibRtDPWCWaop4leIVukwDPOCc iWSYTkHbZZDqTRQrMReCCRcESZeAA0VbMnnXDJ8tXgLm/TBOH1trkPYaI1egsvU2rE7Xv94neL1i Jyx5wPJzQeno1oBDbcFyeNc5UzVrWjbtvYoGYiI0ESZ+Eiq+EbIGbA+ERNINFTqx1qnlqXDPum4W PGBma6hthi9irm7TrQH7lKwYRaCykUomMMwDZmWJIvzAyx5GwJI9jjCI9L1nDViS13Q94AjCIbqK EaZi/Yc8qA8wEG22yyx7iFHEKcT0ciWSIROdT0zFqkelOAgvtCWbaa/187pX10cUQZC0CVjTVnP1 PiafgHOFVL7yUXlm+bKF8iUECAELgfCQnGKEykO4YdPRxQhAzGUiAo4Z0HSTozjVdJGj5wiB/CAQ KqWZH7OylysRbuzYEgHbkMrruulCHVc66eZPzxECiUVAde5vYguTVcNJ8CKr8OYs8WQTMNs4VACH qOvibFXrvv7zgq1dvHLIixw/i00i8ECEnDUZyqjZIxC2EUcGyPj+gGndQhJUMC6PQUuJMy2D7GK/ JZf26/LKpQ0xA5h4Ag6L11XGqMZ5iLpn97AQZyvtKnaJVzoZSdgpzTceGR5e7yfymFsGJVecCLB4 WyvERdwApNxwpRCskDfXuM+lzu5Vp+M/ei5Q5EPa0uvf5KQQ2dDlbdci242bjtCHJCih2lykPrXH 3sBmnWkstKa8i2koWnZ6Ai1egQwxWe/0vGpmwx1shZ565Bx7qdrcprEhSjuX2o6zuU0hJhImlBK1 00g8AQeFC5nHtiJsmt254gHwqiPkdHkExoiKccSlVuiM9Z3umLqkxZxGbYh0fw4QCBCtUJ/9qxBI YGYKHodHACEgVMjDqbr7kMK76uJppF3SkQUVWIdspc07USlmVz7L1xHNUAlKSLaowrWChCHc+8MF JuxwJScaWAhx4kUwrFO/+pbQ3oxCvEIEMhSzHk45OYHi52tIllZBnF3LmrwD44V14Vi2DVExMQnP s9p9JLEWg1e6qAk4J4eoB3jA+vjVlBfcgGFSvgGEqM7EHWLrHlpbNmjOdEsQArpQDa3ohkg04gYc DwG757MapcM5A+NfRUOdtE0JOA1BhZAwJ71ohuW9iQMDaQDizCgI4hl6rKXzbK20AkU4nPwEBS3n OfX5uGGiHl741TZ5QsNCBFH87Y7hZnn/1iDGHZRgPTO50YC2EETAgQInPM1omJjWfRRMTXui4iZg i8DkWOC4D1FXxuRyp5ppDNsfVx6RV45EtFoPXGBxdXps2ltK27T26b7mhYDgBbKCu0IIXsnEQIEE nwcsdHaSJyGmH+QBu95Z+gQcKqgQQsBaD9huIWLZdGkJrSkoLlXnAedMTCPIW+UTHF/jSl46wRKl /Yo3ySbcehxwcceXeaaWzrdT1oA2Y+fja0dhHnBAO1dirJ2RsQpl/56FteZkE3Dz6j6ptIRAxgh4 RvFCb6RbA1YJdHinoL3eRiZrwNjjG05BpyGkEUbA1oDE9mbtdUCloITUEUcVHYkiMOFUuEQqugMf xHV9nTiHKnwqXYEWn7iINLPxkCSnmbLJuy6uXldVCXYYCpxIdWmCiar8qroPE0qJ+oISAUdFjO4n BAgBQiCpCFAsb0HVHBFwQVUHGUMIEAKEACHQXBAgAm4uNU3lbPYIuOINJHjR7BtDhgAktS0VmoAJ EXCGDZEeJwSSh0AR6BinsyFGfiadNOzK9qwpC2vS+WoMmZQlI5sT0Jbyhk04sETA4RjRHYRAcSBg dUTORhJxS2gaogNGIhyInGqDizLMRLpXjCNlm3nYBilmsqkYBqs0negFr1CGB+7QtdO2N+vUd3Xj VZ37hLipWIRBrPwLRRzEbuDGoiJBbUkYpGQi+sJ2YXfFukil4W7c0ophsI1qksiM6UlVTlvT5Jmt DoAIOFvIUrqEQKEh4HgCCq9FFpwIC82wyM3tuHShTN7v7RAXXZynUuggTTEMb2iRIHohEoQVj2qT dWpM4sap8n/Ve6KWU09Lu6rDhD2UQhjCzua8ioMIeKgEWZSiIkFtKQUmPCTtsk+FNqnbA/ve3a3s in6ovlO2EV1+irqKbEcW32Mi4CyCS0kTAgWFQGCn6RWc0ItluCUSSVQnUqATOVARsF7oICYxjNAp 6HoYY8VdOYQpnPvrqUvdFLQjWOGepaw8U1lHDBZ5dUU7TAUi5AGBcV1IjVNX58qY5hACjkX0RcQ4 BFdt3LUGZyPRmBzsGCcCLqgekowhBLKIQJjXYnVW3MPQCSQI5nk6Pd06W4DHoxVa0EEgpqWL6xWf 9eQdxQPmLMiVnNgUtSMDKaXtikko4pJN1h11ZRC0j5USoSqP1QCPQJIS695K3x6EpEPAXo82TdEX ceZDoQctD4hkbXNR7MP3t659q/LM4itJBJxFcClpQqCgEAgg4CjrqnaZ5I5ZJ1KgFp5QCC1gwqo0 0hXDSDmTrifqE41geHRVH04he5W+egzxgFN8llq3Tn2kdWWNZ8bzETwvU4EIWQnMRBwkTJDDHSAp pB0NBnMZi75oyNCknYlkLC8X2GQcSXwmSy8yEXCWgKVkCQFCQIGAiWdYIMA5EooFYk+sZuRgejVW e4s0MSLgIq1YKhYhUJAIJIWAk2JnQVYyGWWKABGwKVJ0HyFACCQWgUITYEgskGR4rAgQAccKJyVG CBQ4AlE9O91aZz6KGdX2KDamk3Y6z0Sxie4tegSIgIu+iqmAhEAKgagbrWIRnGC7TR+yNkJZR9EF CSs4G6UkYRBT22VxEKfubbJUCI5Y4KSO4MNLuTnHwB5qZ4RAVASIgKMiRvcTAklGQApXCQxzSbG2 Q0ye0BL7+7BwJfzd3pGaV7EJx16NbKSmPMqzce36Jw84yW9CQdhOBFwQ1UBGEAI5QkAgDROxDS8B ++Nd9eIZVnlCYl1zJjbh2KEQ9RAGGnpMgsVAclR7lE2RIUAEXGQVSsUhBAIRCPCAdXKJGQlOFIrY hOytSp67M9Aw8OhF+U1RTptaHiEQFQEi4KiI0f2EQJIRkIhIK2yvmmaNKIzAkwgjYLwlm2ITTlVZ dihFPSQ7VZiYiIEkuVmQ7flBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hT roQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQ AvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4Gbe AKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAI EALNHAEi4GbeAKj4hAAhQAgQAvlBgAg4P7hTroQAIUAIEALNHIHEE3Dj2eNAH8KA2gC1AWoD1Aby 3QaijieIgInAaQBDbYDaALUBagMxtAEi4BhAzPcoivKnkTy1AWoD1AaS1waIgImAaSRLbYDaALUB agN5aANEwHkAnUaqyRupUp1RnVEboDYQdxsgAiYCppEvtQFqA9QGqA3koQ0QAecB9LhHUZQejcyp DVAboDaQvDZABEwETCNfagPUBqgNUBvIQxsgAs4D6DRSTd5IleqM6ozaALWBuNsAETARMI18qQ1Q G6A2QG0gD20gKgH//1EPQ6bi7jjMAAAAAElFTkSuQmCC --_004_CB473DBF1888Cbasavarajpatilnokiacom_-- From internet-drafts@ietf.org Thu Jan 26 15:40:02 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480AF11E8087; Thu, 26 Jan 2012 15:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DseM--Ah1OD1; Thu, 26 Jan 2012 15:40:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767EA11E8072; Thu, 26 Jan 2012 15:40:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120126234001.9689.81684.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2012 15:40:01 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 23:40:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Workin= g Group of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Pages : 34 Date : 2012-01-26 Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed for enabling the use of the primary user owned white space spectrum for secondary users, without causing interference, by querying a database which knows the channel availability at any given location and time. A number of possible use cases of this spectrum and derived requirements are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq= mts-02.txt From scott.probasco@nokia.com Thu Jan 26 15:43:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C6E11E808A for ; Thu, 26 Jan 2012 15:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dib0qExTiWAQ for ; Thu, 26 Jan 2012 15:43:20 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4101621F85E7 for ; Thu, 26 Jan 2012 15:42:58 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0QNgs74010972 for ; Fri, 27 Jan 2012 01:42:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 01:42:53 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 00:42:53 +0100 From: To: Thread-Topic: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AQHM3IQ4n1t+3SSARU+3UJjogvpO2Q== Date: Thu, 26 Jan 2012 23:42:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.161.232] Content-Type: multipart/alternative; boundary="_000_CB474119FA3Cscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jan 2012 23:42:53.0977 (UTC) FILETIME=[392A5090:01CCDC84] X-Nokia-AV: Clean Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 23:43:21 -0000 --_000_CB474119FA3Cscottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Revision 2 of the PS, Use cases and requirements I-D has been posted. Pleas= e see: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt This version only includes changes requested by the co-chair in his email o= f January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l Specifically: " 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D= .6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pr= oceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agre= e on the format the location would be represented in. The data format part = is still open, but as this piece does not really belong to requirements but= rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete " And " Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. " Regards, Scott & Raj --_000_CB474119FA3Cscottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4615F3064560E54A92F56A12FC3B81DE@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi,

Revision 2 of the= PS, Use cases and requirements I-D has been posted. Please see:

This version only= includes changes requested by the co-chair in his email of January 12 = ;http://www.ietf.org/mail-archive/web/paws/current/msg00516.html =
Specifically:
"
2. requirements. In the last f2f
we agreed to modify requirement D.1 to include the suggestions from sl= ide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge wi= th D.6 and D.9
slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf&= nbsp;also contain suggestions on how to revise this requirement.
Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pro= ceedings/82/slides/paws-1.pdf
We seem to have agreed with the reformulation suggested to D.3 in slid= e 12 ofhtt= p://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree= on the format the location would be represented in. The data format part is still open, but as this piece d= oes not really belong to requirements but rather the data model spec, we ar= e not in a hurry to decide it.
Delete d.4
D.5: augment with lower/upper frequencies and time of availability, as= suggested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf
D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf.
D.7: change to single and multiple locations. Clarify that in case of = multiple locations the channel availability for each location should be sen= t by the db.
D.8: delete
"
"


Regards,
Scott & Raj
--_000_CB474119FA3Cscottprobasconokiacom_-- From nbravin@earthlink.net Thu Jan 26 22:08:24 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781EE21F8565 for ; Thu, 26 Jan 2012 22:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIN4iLm-+rbh for ; Thu, 26 Jan 2012 22:08:24 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id C5B8A21F8562 for ; Thu, 26 Jan 2012 22:08:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HYwVHYLjU2k0gGInu6U+qzClZSnAOpQDZzFGEj+ppQA2ZIulC+9FTKki+5Cqqswc; h=Received:From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Rqez0-0002LF-7O; Fri, 27 Jan 2012 01:08:22 -0500 From: Nancy Bravin Content-Type: multipart/alternative; boundary=Apple-Mail-4--702533371 Date: Thu, 26 Jan 2012 22:08:21 -0800 Message-Id: To: scott.probasco@nokia.com Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86a44fc09c8ef9d270fb5c1c97707f068f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 06:08:24 -0000 --Apple-Mail-4--702533371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Scott, Raj, and all, Abstract Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. I would change (licensed or unlicensed) to: (licensed, licensed exempt = or unlicensed) as some countries have 3 categories. Also, license exempt is mentioned in section 4.4 SIncerely, Nancy= --Apple-Mail-4--702533371 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear Scott, Raj, and all,

Abstract

   Portions of the radio spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as "white space".  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to "unlock" existing spectrum for new use.
I would change (licensed or unlicensed) to: (licensed, licensed exempt or unlicensed) as some countries have 3 categories.
 Also, license exempt is mentioned in section 4.4


SIncerely, Nancy
--Apple-Mail-4--702533371-- From nbravin@earthlink.net Thu Jan 26 22:23:48 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D8121F8575 for ; Thu, 26 Jan 2012 22:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szdtSCPGNlrn for ; Thu, 26 Jan 2012 22:23:48 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 655A921F8574 for ; Thu, 26 Jan 2012 22:23:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hciuVIrIoQ7jsuEeL0yMdH3NQQ+SwvRpOmkcTQ3m19dB5QBeDREbC0ygKLYiUq7y; h=Received:From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RqfDv-0000cU-Iz; Fri, 27 Jan 2012 01:23:47 -0500 From: Nancy Bravin Content-Type: multipart/alternative; boundary=Apple-Mail-6--701607968 Date: Thu, 26 Jan 2012 22:23:46 -0800 Message-Id: To: scott.probasco@nokia.com Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8609462d24ff27f65f2ba7671b070ad1c9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] paws edit to rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 06:23:49 -0000 --Apple-Mail-6--701607968 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Scott, Raj and all,=20 One more.. Page 25 1. Radio/air interface agnostic - The radio/air interface technology used by the white space device in available spectrum can be 802.11af, 802.16, 802.22, LTE , etc. However the messaging interface between the white space device and the database should be agnostic to the air interface while being cognizant of the characteristics of various air-interface technologies and the need to include relevant attributes in the query to the database. I propose to change to " IEEE802.11af, IEEE802.15.4m, IEEE802.16, = IEEE802.22, LTE, etc." Sincerely, Nancy= --Apple-Mail-6--701607968 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear Scott, Raj and all, 

One more..

Page 25

 1.  Radio/air interface agnostic - The radio/air interface technology
       used by the white space device in available spectrum can be
       802.11af, 802.16, 802.22, LTE , etc.  However the messaging
       interface between the white space device and the database should
       be agnostic to the air interface while being cognizant of the
       characteristics of various air-interface technologies and the
       need to include relevant attributes in the query to the database.

I propose to change  to " IEEE802.11af, IEEE802.15.4m, IEEE802.16, IEEE802.22, LTE, etc."

Sincerely, Nancy
--Apple-Mail-6--701607968-- From jussi.kahtava@nokia.com Fri Jan 27 00:18:23 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547BE21F8518 for ; Fri, 27 Jan 2012 00:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3H5JtxjiPVS for ; Fri, 27 Jan 2012 00:18:22 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2A10B21F8510 for ; Fri, 27 Jan 2012 00:18:21 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0R8IHLw018787; Fri, 27 Jan 2012 10:18:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 10:18:16 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.72]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 09:18:16 +0100 From: To: , Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: AQHM3Lob/HdBzSA0uUKLQjjyZhLd6JYf3nsw Date: Fri, 27 Jan 2012 08:18:15 +0000 Message-ID: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IhkKw2eagAfsl5KMO/FSdK4TyhW+i1WRYrUwHAvnM9t0KuTxCPTcX+vu35wPHLIZXbOYnO/OBBNTs4P2cTjktMtYd+eLHon34A5WCVPjciVredhjuj8ocbfPNA92BwTtLAlU+d30LS0nv2FWp2Lk9dFknnsUZm27pC1C8fD22ZUU9kPI+sfeNBxpsTEeStcxtoyCDb+kOuCGpUk1G9xVkuqz6ok7uPFFNH3m4srB2CDS x-headerinfofordlp: None x-originating-ip: [172.26.105.132] Content-Type: multipart/alternative; boundary="_000_23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9008AM1MPN1021mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 08:18:17.0007 (UTC) FILETIME=[38BA3BF0:01CCDCCC] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 08:18:23 -0000 --_000_23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9008AM1MPN1021mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Nancy, My understanding is that 'unlicensed' is used in North America and 'licence= -exempt' in the UK. They do refer to the same thing, I think, so one could = say (licensed, unlicensed/licence-exempt). Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Nancy Bravin Sent: 27 January 2012 06:08 To: Probasco Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: [paws] re proposed edits on rev 2 Dear Scott, Raj, and all, Abstract Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. I would change (licensed or unlicensed) to: (licensed, licensed exempt or u= nlicensed) as some countries have 3 categories. Also, license exempt is mentioned in section 4.4 SIncerely, Nancy --_000_23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9008AM1MPN1021mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Nancy,

 <= /p>

My understanding is that = ‘unlicensed’ is used in North America and ‘licence-exempt= ’ in the UK. They do refer to the same thing, I think, so one could s= ay (licensed, unlicensed/licence-exempt).

 <= /p>

Kind regards,<= /span>

Jussi

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Nancy Bravin
Sent: 27 January 2012 06:08
To: Probasco Scott (Nokia-CIC/Dallas)
Cc: paws@ietf.org
Subject: [paws] re proposed edits on rev 2

 

Dear Scott, Raj, and all,

 

Abstract
 
   Portions of the radio spect=
rum that are allocated to a licensed,
   primary user but are unused=
 or unoccupied at specific locations and
   times are defined as "=
white space".  The concept of allowing
   secondary transmissions (li=
censed or unlicensed) in white space is a
   technique to "unlock&q=
uot; existing spectrum for new use.

I would change (licens= ed or unlicensed) to: (licensed, licensed exempt or unlicensed) as some cou= ntries have 3 categories.

 Also, license ex= empt is mentioned in section 4.4

 

 

SIncerely, Nancy

--_000_23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9008AM1MPN1021mg_-- From teco@inf-net.nl Fri Jan 27 01:07:25 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451C021F84FB for ; Fri, 27 Jan 2012 01:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRk9NzyZgJoX for ; Fri, 27 Jan 2012 01:07:24 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B07821F84F5 for ; Fri, 27 Jan 2012 01:07:23 -0800 (PST) Received: by eekc1 with SMTP id c1so473824eek.31 for ; Fri, 27 Jan 2012 01:07:22 -0800 (PST) Received: by 10.14.9.193 with SMTP id 41mr1884173eet.64.1327655241575; Fri, 27 Jan 2012 01:07:21 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id r2sm26730436eef.7.2012.01.27.01.07.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 01:07:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> Date: Fri, 27 Jan 2012 10:07:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> To: X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 09:07:25 -0000 I suggest we keep our documents agnostic on exact specifications for=20 this kind of terminology. The Rapid deployed network for emergency=20 scenario says "free or freed spectrum". We can do a lot more with the protocol than just TVWS, or TVWS in country xx. Teco Op 27 jan. 2012, om 09:18 heeft = het volgende geschreven: > Dear Nancy, > =20 > My understanding is that =91unlicensed=92 is used in North America and = =91licence-exempt=92 in the UK. They do refer to the same thing, I = think, so one could say (licensed, unlicensed/licence-exempt). > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Nancy Bravin > Sent: 27 January 2012 06:08 > To: Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: [paws] re proposed edits on rev 2 > =20 > Dear Scott, Raj, and all, > =20 > Abstract > =20 > Portions of the radio spectrum that are allocated to a licensed, > primary user but are unused or unoccupied at specific locations and > times are defined as "white space". The concept of allowing > secondary transmissions (licensed or unlicensed) in white space is = a > technique to "unlock" existing spectrum for new use. > I would change (licensed or unlicensed) to: (licensed, licensed exempt = or unlicensed) as some countries have 3 categories. > Also, license exempt is mentioned in section 4.4 > =20 > =20 > SIncerely, Nancy > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Fri Jan 27 01:14:00 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39121F853A for ; Fri, 27 Jan 2012 01:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC5ZwHTnMMls for ; Fri, 27 Jan 2012 01:13:59 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51DA121F851E for ; Fri, 27 Jan 2012 01:13:59 -0800 (PST) Received: by eekc1 with SMTP id c1so475980eek.31 for ; Fri, 27 Jan 2012 01:13:58 -0800 (PST) Received: by 10.14.9.193 with SMTP id 41mr1891522eet.64.1327655638499; Fri, 27 Jan 2012 01:13:58 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id r2sm26793267eef.7.2012.01.27.01.13.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 01:13:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 27 Jan 2012 10:13:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 09:14:00 -0000 Hi Scott, IMHO the first 2 use cases "TVWS database discovery" and "Device=20 registration with trusted Database" are not real use cases, but aspects of the protocol. Text says "prerequisite to other use cases". They could move to the Problem Statement section and combine=20 text. There is already a "5.2. Database discovery". The other section would need a "5.x Device registration with trusted Database". Teco Op 27 jan. 2012, om 00:42 heeft = het volgende geschreven: > Hi, >=20 > Revision 2 of the PS, Use cases and requirements I-D has been posted. = Please see: > = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-= rqmts-02.txt >=20 > This version only includes changes requested by the co-chair in his = email of January 12 = http://www.ietf.org/mail-archive/web/paws/current/msg00516.html=20 > Specifically: > " >> 2. requirements. In the last f2f >> we agreed to modify requirement D.1 to include the suggestions from = slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and = merge with D.6 and D.9 >> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf = also contain suggestions on how to revise this requirement. >> Agreed to revise requirement D.2 as suggested in slide 11 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of = http://www.ietf.org/proceedings/82/slides/paws-1.pdf >> We seem to have agreed with the reformulation suggested to D.3 in = slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we = did not agree on the format the location would be represented in. The = data format part is still open, but as this piece does not really belong = to requirements but rather the data model spec, we are not in a hurry to = decide it. >> Delete d.4 >> D.5: augment with lower/upper frequencies and time of availability, = as suggested on slide 10 = ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >> D.6: change power to eirp, as suggested in slide 13 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >> D.7: change to single and multiple locations. Clarify that in case of = multiple locations the channel availability for each location should be = sent by the db. >> D.8: delete > " >>=20 > And > " >> Operational requirements: slides 22-24 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions = on rewording, I propose the editor considers them. > " >=20 >=20 > Regards, > Scott & Raj > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Fri Jan 27 02:16:39 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1D921F8543 for ; Fri, 27 Jan 2012 02:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.256 X-Spam-Level: X-Spam-Status: No, score=-3.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHW+90V2qFC2 for ; Fri, 27 Jan 2012 02:16:39 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id B8A5821F8542 for ; Fri, 27 Jan 2012 02:16:38 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 27 Jan 2012 10:16:36 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Fri, 27 Jan 2012 10:16:36 +0000 From: To: , , Date: Fri, 27 Jan 2012 10:16:34 +0000 Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: Aczc0xiPHJgqjdr8SRqcyLb3v0luyQAAohOg Message-ID: <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> In-Reply-To: <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:16:40 -0000 Teco, Jussi, Nancy, (Scott, Raj) I agree with your sentiment but in addition to the use of the term licence-= exempt I also have a problem with primary and secondary. Primary and second= ary (and tertiary) services have a particular meaning in ITU in relation to= spectrum allocations, and we are giving the words a different meaning here= in relation to users. When this PAWS protocol is later applied to non-TV b= ands, it might be radar (say) that is the primary use and fixed links or mo= bile (say) that is the secondary use, in ITU regulations. This will then co= nflict with calling white space operation secondary. How about this re-writ= e of the abstract, considering "use" instead of "user" and avoiding "primar= y" and "secondary": Portions of the radio spectrum that are allocated to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional=20 transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the allocated use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently allocated use, by querying a database which knows the channel availability at any given location and time. A number of possible use cases of white space spectrum and derived=20 requirements are also described. The parts of the Introduction etc from which this Abstract was originally d= erived will also need to be updated to match. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Tec= o Boot Sent: 27 January 2012 09:07 To: jussi.kahtava@nokia.com Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 I suggest we keep our documents agnostic on exact specifications for this k= ind of terminology. The Rapid deployed network for emergency scenario says = "free or freed spectrum". We can do a lot more with the protocol than just = TVWS, or TVWS in country xx. Teco Op 27 jan. 2012, om 09:18 heeft het volgende geschreven: > Dear Nancy, > =20 > My understanding is that 'unlicensed' is used in North America and 'licen= ce-exempt' in the UK. They do refer to the same thing, I think, so one coul= d say (licensed, unlicensed/licence-exempt). > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Nancy Bravin > Sent: 27 January 2012 06:08 > To: Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: [paws] re proposed edits on rev 2 > =20 > Dear Scott, Raj, and all, > =20 > Abstract > =20 > Portions of the radio spectrum that are allocated to a licensed, > primary user but are unused or unoccupied at specific locations and > times are defined as "white space". The concept of allowing > secondary transmissions (licensed or unlicensed) in white space is a > technique to "unlock" existing spectrum for new use. > I would change (licensed or unlicensed) to: (licensed, licensed exempt or= unlicensed) as some countries have 3 categories. > Also, license exempt is mentioned in section 4.4 > =20 > =20 > SIncerely, Nancy > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From jussi.kahtava@nokia.com Fri Jan 27 02:34:02 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A963321F856F for ; Fri, 27 Jan 2012 02:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHzMKbNVWncS for ; Fri, 27 Jan 2012 02:34:02 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE5721F8559 for ; Fri, 27 Jan 2012 02:34:01 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RAXSnQ028198; Fri, 27 Jan 2012 12:33:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 12:33:36 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.72]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 11:33:36 +0100 From: To: , , Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: AQHM3Lob/HdBzSA0uUKLQjjyZhLd6JYf3nsw///9cYCAABNZAIAAE4iw Date: Fri, 27 Jan 2012 10:33:35 +0000 Message-ID: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E4A9@008-AM1MPN1-021.mgdnok.nokia.com> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.26.105.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 10:33:36.0497 (UTC) FILETIME=[20521610:01CCDCDF] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:34:02 -0000 Hello Andy and others, Andy is on the right track here, but we can easily end up with a never-endi= ng round of improvements to the draft text :-) One additional problem that will come from Andy's text proposal is the diff= erence between spectrum 'allocation' and spectrum 'assigment'. ITU allocate= s spectrum to primary and secondary use, as Andy mentioned. Then it is the = regional and national authorities that 'assign' spectrum to specific uses. = The allocation to primary and secondary does not mean that both radio commu= nication services would actually have an assignment to use that spectrum. S= o, to the extent that we remove primary and secondary from the draft, I wou= ld propose replacing 'allocated' with 'assigned'. Kind regards, Jussi -----Original Message----- From: ext andy.sago@bt.com [mailto:andy.sago@bt.com]=20 Sent: 27 January 2012 10:17 To: teco@inf-net.nl; Kahtava Jussi (Nokia-CIC/Southwood); nbravin@earthlink= .net Cc: paws@ietf.org Subject: RE: [paws] re proposed edits on rev 2 Teco, Jussi, Nancy, (Scott, Raj) I agree with your sentiment but in addition to the use of the term licence-= exempt I also have a problem with primary and secondary. Primary and second= ary (and tertiary) services have a particular meaning in ITU in relation to= spectrum allocations, and we are giving the words a different meaning here= in relation to users. When this PAWS protocol is later applied to non-TV b= ands, it might be radar (say) that is the primary use and fixed links or mo= bile (say) that is the secondary use, in ITU regulations. This will then co= nflict with calling white space operation secondary. How about this re-writ= e of the abstract, considering "use" instead of "user" and avoiding "primar= y" and "secondary": Portions of the radio spectrum that are allocated to a particular use but a= re unused or unoccupied at specific locations and times are defined as "whi= te space". The concept of allowing additional transmissions (which may or m= ay not be licensed) in white space is a technique to "unlock" existing spec= trum for new use. An obvious requirement is that these additional transmiss= ions do not interfere with the allocated use of the spectrum. One approach = to using the white space spectrum at a given time and location is to verify= with a database for available channels. This document describes the concept of TV White Spaces. It also describes t= he problems that need to be addressed to enable white space spectrum for ad= ditional uses, without causing interference to currently allocated use, by = querying a database which knows the channel availability at any given locat= ion and time. A number of possible use cases of white space spectrum and de= rived requirements are also described. The parts of the Introduction etc from which this Abstract was originally d= erived will also need to be updated to match. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Tec= o Boot Sent: 27 January 2012 09:07 To: jussi.kahtava@nokia.com Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 I suggest we keep our documents agnostic on exact specifications for this k= ind of terminology. The Rapid deployed network for emergency scenario says = "free or freed spectrum". We can do a lot more with the protocol than just = TVWS, or TVWS in country xx. Teco Op 27 jan. 2012, om 09:18 heeft het volgende geschreven: > Dear Nancy, > =20 > My understanding is that 'unlicensed' is used in North America and 'licen= ce-exempt' in the UK. They do refer to the same thing, I think, so one coul= d say (licensed, unlicensed/licence-exempt). > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Nancy Bravin > Sent: 27 January 2012 06:08 > To: Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: [paws] re proposed edits on rev 2 > =20 > Dear Scott, Raj, and all, > =20 > Abstract > =20 > Portions of the radio spectrum that are allocated to a licensed, > primary user but are unused or unoccupied at specific locations and > times are defined as "white space". The concept of allowing > secondary transmissions (licensed or unlicensed) in white space is a > technique to "unlock" existing spectrum for new use. > I would change (licensed or unlicensed) to: (licensed, licensed exempt or= unlicensed) as some countries have 3 categories. > Also, license exempt is mentioned in section 4.4 > =20 > =20 > SIncerely, Nancy > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Fri Jan 27 02:34:55 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E1E21F856F for ; Fri, 27 Jan 2012 02:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpuWM+geO6o9 for ; Fri, 27 Jan 2012 02:34:54 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id CAFFC21F8559 for ; Fri, 27 Jan 2012 02:34:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dKJaSnjOeR798Hhey19I4KcnYnrFhC6W9XJuUOpGtqJ1HqpyU2ykW1qMoicKXfJH; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Rqj8t-00086k-V8; Fri, 27 Jan 2012 05:34:52 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> Date: Fri, 27 Jan 2012 02:34:50 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8697fe96e8cbbbae0b4a9d521a77d47882350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:34:55 -0000 Hi Andy,=20 How about we compromise? I understand the issues with license exempt. = but many countries in the world use the phrase "lightly licensed" , and many are emerging countries where things need = to be clear, so if we change it to ( licensed, unlicensed, or lightly = licensed) most of the world will understand the meaning and we will not have a misunderstanding around what license exempt implies = in any county or the ITU? What we are doing is making the wording understandable on a global = basis, and at the same time not interfering with the ITU's meanings in = this respect, we can all agree on .=20 Thanks for your assistance. Sincerely, Nancy On Jan 27, 2012, at 2:16 AM, wrote: > Teco, Jussi, Nancy, (Scott, Raj) >=20 > I agree with your sentiment but in addition to the use of the term = licence-exempt I also have a problem with primary and secondary. Primary = and secondary (and tertiary) services have a particular meaning in ITU = in relation to spectrum allocations, and we are giving the words a = different meaning here in relation to users. When this PAWS protocol is = later applied to non-TV bands, it might be radar (say) that is the = primary use and fixed links or mobile (say) that is the secondary use, = in ITU regulations. This will then conflict with calling white space = operation secondary. How about this re-write of the abstract, = considering "use" instead of "user" and avoiding "primary" and = "secondary": >=20 > Portions of the radio spectrum that are allocated to a particular use > but are unused or unoccupied at specific locations and times are > defined as "white space". The concept of allowing additional=20 > transmissions (which may or may not be licensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these additional transmissions do not interfere > with the allocated use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with a > database for available channels. >=20 > This document describes the concept of TV White Spaces. It also > describes the problems that need to be addressed to enable white > space spectrum for additional uses, without causing interference to > currently allocated use, by querying a database which knows the > channel availability at any given location and time. A number of > possible use cases of white space spectrum and derived=20 > requirements are also described. >=20 > The parts of the Introduction etc from which this Abstract was = originally derived will also need to be updated to match. >=20 > Regards >=20 > Andy >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Teco Boot > Sent: 27 January 2012 09:07 > To: jussi.kahtava@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] re proposed edits on rev 2 >=20 > I suggest we keep our documents agnostic on exact specifications for = this kind of terminology. The Rapid deployed network for emergency = scenario says "free or freed spectrum". We can do a lot more with the = protocol than just TVWS, or TVWS in country xx. >=20 > Teco >=20 >=20 > Op 27 jan. 2012, om 09:18 heeft = het volgende geschreven: >=20 >> Dear Nancy, >>=20 >> My understanding is that 'unlicensed' is used in North America and = 'licence-exempt' in the UK. They do refer to the same thing, I think, so = one could say (licensed, unlicensed/licence-exempt). >>=20 >> Kind regards, >> Jussi >>=20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20= >> Of ext Nancy Bravin >> Sent: 27 January 2012 06:08 >> To: Probasco Scott (Nokia-CIC/Dallas) >> Cc: paws@ietf.org >> Subject: [paws] re proposed edits on rev 2 >>=20 >> Dear Scott, Raj, and all, >>=20 >> Abstract >>=20 >> Portions of the radio spectrum that are allocated to a licensed, >> primary user but are unused or unoccupied at specific locations and >> times are defined as "white space". The concept of allowing >> secondary transmissions (licensed or unlicensed) in white space is = a >> technique to "unlock" existing spectrum for new use. >> I would change (licensed or unlicensed) to: (licensed, licensed = exempt or unlicensed) as some countries have 3 categories. >> Also, license exempt is mentioned in section 4.4 >>=20 >>=20 >> SIncerely, Nancy >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Fri Jan 27 02:45:33 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C298221F852E for ; Fri, 27 Jan 2012 02:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPt5fmFnhuOK for ; Fri, 27 Jan 2012 02:45:33 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 909CB21F8528 for ; Fri, 27 Jan 2012 02:45:32 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 27 Jan 2012 10:45:25 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 27 Jan 2012 10:45:25 +0000 From: To: , Date: Fri, 27 Jan 2012 10:45:24 +0000 Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: AQHM3Lob/HdBzSA0uUKLQjjyZhLd6JYf3nsw///9cYCAABNZAIAAE4iwgAACp4A= Message-ID: <619CDADDCCD2B44380834BE8BF6F714140650323B0@EMV62-UKRD.domain1.systemhost.net> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> <23293D9BB25E0B48A038B78C7D1D0D5C01E5E4A9@008-AM1MPN1-021.mgdnok.nokia.com> In-Reply-To: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E4A9@008-AM1MPN1-021.mgdnok.nokia.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:45:33 -0000 Jussi (Also answering Nancy's response received with very similar timing) Thanks for your intervention, I misused the word allocation, my apologies. = Assigned is the correct term and should replace "allocated " in three place= s to give: Portions of the radio spectrum that are assigned to a particular use but ar= e unused or unoccupied at specific locations and times are defined as "whit= e space". The concept of allowing additional transmissions (which may or ma= y not be licensed) in white space is a technique to "unlock" existing spect= rum for new use. An obvious requirement is that these additional transmissi= ons do not interfere with the assigned use of the spectrum. One approach to= using the white space spectrum at a given time and location is to verify w= ith a database for available channels. This document describes the concept of TV White Spaces. It also describes t= he problems that need to be addressed to enable white space spectrum for ad= ditional uses, without causing interference to currently assigned use, by q= uerying a database which knows the channel availability at any given locati= on and time. A number of possible use cases of white space spectrum and der= ived requirements are also described. I don't propose to take up Nancy's suggestion of including licences/licence= exempt/lightly licensed as this is a matter for regulators and will vary a= round the world. In my version I no longer refer to the existing licensing = status of the spectrum as I don't believe this is relevant and it is certai= nly difficult to describe all potential scenarios. The only mention of lice= nsing is in relation to the white space usage where I put "...additional tr= ansmissions (which may or may not be licensed)...". Regards Andy -----Original Message----- From: jussi.kahtava@nokia.com [mailto:jussi.kahtava@nokia.com]=20 Sent: 27 January 2012 10:34 To: Sago,AJ,Andy,COD R; teco@inf-net.nl; nbravin@earthlink.net Cc: paws@ietf.org Subject: RE: [paws] re proposed edits on rev 2 Hello Andy and others, Andy is on the right track here, but we can easily end up with a never-endi= ng round of improvements to the draft text :-) One additional problem that will come from Andy's text proposal is the diff= erence between spectrum 'allocation' and spectrum 'assigment'. ITU allocate= s spectrum to primary and secondary use, as Andy mentioned. Then it is the = regional and national authorities that 'assign' spectrum to specific uses. = The allocation to primary and secondary does not mean that both radio commu= nication services would actually have an assignment to use that spectrum. S= o, to the extent that we remove primary and secondary from the draft, I wou= ld propose replacing 'allocated' with 'assigned'. Kind regards, Jussi -----Original Message----- From: ext andy.sago@bt.com [mailto:andy.sago@bt.com] Sent: 27 January 2012 10:17 To: teco@inf-net.nl; Kahtava Jussi (Nokia-CIC/Southwood); nbravin@earthlink= .net Cc: paws@ietf.org Subject: RE: [paws] re proposed edits on rev 2 Teco, Jussi, Nancy, (Scott, Raj) I agree with your sentiment but in addition to the use of the term licence-= exempt I also have a problem with primary and secondary. Primary and second= ary (and tertiary) services have a particular meaning in ITU in relation to= spectrum allocations, and we are giving the words a different meaning here= in relation to users. When this PAWS protocol is later applied to non-TV b= ands, it might be radar (say) that is the primary use and fixed links or mo= bile (say) that is the secondary use, in ITU regulations. This will then co= nflict with calling white space operation secondary. How about this re-writ= e of the abstract, considering "use" instead of "user" and avoiding "primar= y" and "secondary": Portions of the radio spectrum that are allocated to a particular use but a= re unused or unoccupied at specific locations and times are defined as "whi= te space". The concept of allowing additional transmissions (which may or m= ay not be licensed) in white space is a technique to "unlock" existing spec= trum for new use. An obvious requirement is that these additional transmiss= ions do not interfere with the allocated use of the spectrum. One approach = to using the white space spectrum at a given time and location is to verify= with a database for available channels. This document describes the concept of TV White Spaces. It also describes t= he problems that need to be addressed to enable white space spectrum for ad= ditional uses, without causing interference to currently allocated use, by = querying a database which knows the channel availability at any given locat= ion and time. A number of possible use cases of white space spectrum and de= rived requirements are also described. The parts of the Introduction etc from which this Abstract was originally d= erived will also need to be updated to match. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Tec= o Boot Sent: 27 January 2012 09:07 To: jussi.kahtava@nokia.com Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 I suggest we keep our documents agnostic on exact specifications for this k= ind of terminology. The Rapid deployed network for emergency scenario says = "free or freed spectrum". We can do a lot more with the protocol than just = TVWS, or TVWS in country xx. Teco Op 27 jan. 2012, om 09:18 heeft het volgende geschreven: > Dear Nancy, > =20 > My understanding is that 'unlicensed' is used in North America and 'licen= ce-exempt' in the UK. They do refer to the same thing, I think, so one coul= d say (licensed, unlicensed/licence-exempt). > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of ext Nancy Bravin > Sent: 27 January 2012 06:08 > To: Probasco Scott (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: [paws] re proposed edits on rev 2 > =20 > Dear Scott, Raj, and all, > =20 > Abstract > =20 > Portions of the radio spectrum that are allocated to a licensed, > primary user but are unused or unoccupied at specific locations and > times are defined as "white space". The concept of allowing > secondary transmissions (licensed or unlicensed) in white space is a > technique to "unlock" existing spectrum for new use. > I would change (licensed or unlicensed) to: (licensed, licensed exempt or= unlicensed) as some countries have 3 categories. > Also, license exempt is mentioned in section 4.4 > =20 > =20 > SIncerely, Nancy > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Fri Jan 27 02:52:38 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92CB21F84E1 for ; Fri, 27 Jan 2012 02:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOFzcTozd4od for ; Fri, 27 Jan 2012 02:52:37 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 81A7221F84EB for ; Fri, 27 Jan 2012 02:52:37 -0800 (PST) Received: by eaai13 with SMTP id i13so501425eaa.31 for ; Fri, 27 Jan 2012 02:52:36 -0800 (PST) Received: by 10.213.15.139 with SMTP id k11mr1037291eba.70.1327661556461; Fri, 27 Jan 2012 02:52:36 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id s16sm27795982eef.2.2012.01.27.02.52.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 02:52:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Teco Boot In-Reply-To: Date: Fri, 27 Jan 2012 11:52:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6446F9F0-9EB3-4169-B6F8-51D948A55763@inf-net.nl> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E5E2F9@008-AM1MPN1-021.mgdnok.nokia.com> <1869698E-483D-442A-9467-F53EB21762BB@inf-net.nl> <619CDADDCCD2B44380834BE8BF6F71414065032356@EMV62-UKRD.domain1.systemhost.net> To: Nancy Bravin , andy.sago@bt.com, scott.probasco@nokia.com, "jussi.kahtava@nokia.com>" , paws@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 10:52:39 -0000 Whatever we write down, we don't set up the rules. We define a protocol. There are examples of priority access and "licenced" preemptible = secondairy access. = http://transition.fcc.gov/pshs/public-safety-spectrum/700-MHz/partnership.= html Wifi 5GHz DFS is an example of "unlicened" preemptible secondairy = access. I'm sure there will be shifts in what can be done and what will be done. We can help to enlarge possibilities and usage of it. Teco Op 27 jan. 2012, om 11:34 heeft Nancy Bravin het volgende geschreven: > Hi Andy,=20 > How about we compromise? I understand the issues with license exempt. = but many countries in the world use the phrase > "lightly licensed" , and many are emerging countries where things need = to be clear, so if we change it to ( licensed, unlicensed, or lightly = licensed) most of the world will understand the meaning and > we will not have a misunderstanding around what license exempt implies = in any county or the ITU? > What we are doing is making the wording understandable on a global = basis, and at the same time not interfering with the ITU's meanings in = this respect, we can all agree on .=20 > Thanks for your assistance. Sincerely, Nancy >=20 > On Jan 27, 2012, at 2:16 AM, wrote: >=20 >> Teco, Jussi, Nancy, (Scott, Raj) >>=20 >> I agree with your sentiment but in addition to the use of the term = licence-exempt I also have a problem with primary and secondary. Primary = and secondary (and tertiary) services have a particular meaning in ITU = in relation to spectrum allocations, and we are giving the words a = different meaning here in relation to users. When this PAWS protocol is = later applied to non-TV bands, it might be radar (say) that is the = primary use and fixed links or mobile (say) that is the secondary use, = in ITU regulations. This will then conflict with calling white space = operation secondary. How about this re-write of the abstract, = considering "use" instead of "user" and avoiding "primary" and = "secondary": >>=20 >> Portions of the radio spectrum that are allocated to a particular use >> but are unused or unoccupied at specific locations and times are >> defined as "white space". The concept of allowing additional=20 >> transmissions (which may or may not be licensed) in white space is a >> technique to "unlock" existing spectrum for new use. An obvious >> requirement is that these additional transmissions do not interfere >> with the allocated use of the spectrum. One approach to using the >> white space spectrum at a given time and location is to verify with a >> database for available channels. >>=20 >> This document describes the concept of TV White Spaces. It also >> describes the problems that need to be addressed to enable white >> space spectrum for additional uses, without causing interference to >> currently allocated use, by querying a database which knows the >> channel availability at any given location and time. A number of >> possible use cases of white space spectrum and derived=20 >> requirements are also described. >>=20 >> The parts of the Introduction etc from which this Abstract was = originally derived will also need to be updated to match. >>=20 >> Regards >>=20 >> Andy >>=20 >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Teco Boot >> Sent: 27 January 2012 09:07 >> To: jussi.kahtava@nokia.com >> Cc: paws@ietf.org >> Subject: Re: [paws] re proposed edits on rev 2 >>=20 >> I suggest we keep our documents agnostic on exact specifications for = this kind of terminology. The Rapid deployed network for emergency = scenario says "free or freed spectrum". We can do a lot more with the = protocol than just TVWS, or TVWS in country xx. >>=20 >> Teco >>=20 >>=20 >> Op 27 jan. 2012, om 09:18 heeft = het volgende geschreven: >>=20 >>> Dear Nancy, >>>=20 >>> My understanding is that 'unlicensed' is used in North America and = 'licence-exempt' in the UK. They do refer to the same thing, I think, so = one could say (licensed, unlicensed/licence-exempt). >>>=20 >>> Kind regards, >>> Jussi >>>=20 >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20= >>> Of ext Nancy Bravin >>> Sent: 27 January 2012 06:08 >>> To: Probasco Scott (Nokia-CIC/Dallas) >>> Cc: paws@ietf.org >>> Subject: [paws] re proposed edits on rev 2 >>>=20 >>> Dear Scott, Raj, and all, >>>=20 >>> Abstract >>>=20 >>> Portions of the radio spectrum that are allocated to a licensed, >>> primary user but are unused or unoccupied at specific locations and >>> times are defined as "white space". The concept of allowing >>> secondary transmissions (licensed or unlicensed) in white space is = a >>> technique to "unlock" existing spectrum for new use. >>> I would change (licensed or unlicensed) to: (licensed, licensed = exempt or unlicensed) as some countries have 3 categories. >>> Also, license exempt is mentioned in section 4.4 >>>=20 >>>=20 >>> SIncerely, Nancy >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 From peter@spectrumbridge.com Fri Jan 27 05:11:50 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA321F8537 for ; Fri, 27 Jan 2012 05:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GgaS+1-88h1 for ; Fri, 27 Jan 2012 05:11:49 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13F21F8533 for ; Fri, 27 Jan 2012 05:11:48 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 27 Jan 2012 08:12:18 -0500 From: Peter Stanforth To: Nancy Bravin , "scott.probasco@nokia.com" Date: Fri, 27 Jan 2012 08:11:50 -0500 Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: Aczc9UtH4/UBf6psTziTnwPXOazlOA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB480BFC1E5A0peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 13:11:50 -0000 --_000_CB480BFC1E5A0peterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If this is a protocol for accessing white space why do we care. Besides The terms exclusive and non exclusive are much more appropriate. A " license" implies exclusivity, where as "unlicensed or license exempt" i= mply non exclusivity. The term licensed and unlicensed get juxtaposed too often to imply "paid fo= r" and "free". The PAWS protocol should include enough information such that the access to= the spectrum could be paid for. There is nothing that says White Space acc= ess has to be free. From: Nancy Bravin > Date: Fri, 27 Jan 2012 01:08:21 -0500 To: "scott.probasco@nokia.com" > Cc: "paws@ietf.org" > Subject: [paws] re proposed edits on rev 2 Dear Scott, Raj, and all, Abstract Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. I would change (licensed or unlicensed) to: (licensed, licensed exempt or u= nlicensed) as some countries have 3 categories. Also, license exempt is mentioned in section 4.4 SIncerely, Nancy --_000_CB480BFC1E5A0peterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
If this is a protocol fo= r accessing white space why do we care.
Besides The terms exclusi= ve and non exclusive are much more appropriate.
A " license" impl= ies exclusivity, where as "unlicensed or license exempt" imply non exclusiv= ity.
The term licensed and unlicensed get juxtaposed too often to= imply "paid for" and "free".
The PAWS protocol should include en= ough information such that the access to the spectrum could be paid for. Th= ere is nothing that says White Space access has to be free.

<= /div>

Dear Scott, Ra= j, and all,

Abstract

   Portions of the radio=
 spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as "white space".  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to "unlock" existing spectrum for new use.
=
I would change (lic= ensed or unlicensed) to: (licensed, licensed exempt or unlicensed) as some = countries have 3 categories.
 Also, license exempt is mentioned in section 4.= 4

<= br>
SIn= cerely, Nancy
--_000_CB480BFC1E5A0peterspectrumbridgecom_-- From teco@inf-net.nl Fri Jan 27 05:32:30 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DFD21F84C4 for ; Fri, 27 Jan 2012 05:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1T9FOL4vXhJ for ; Fri, 27 Jan 2012 05:32:29 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D04F321F84B9 for ; Fri, 27 Jan 2012 05:32:28 -0800 (PST) Received: by eaai13 with SMTP id i13so553248eaa.31 for ; Fri, 27 Jan 2012 05:32:27 -0800 (PST) Received: by 10.213.10.81 with SMTP id o17mr390186ebo.148.1327671147249; Fri, 27 Jan 2012 05:32:27 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id t11sm2417812eea.10.2012.01.27.05.32.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 05:32:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_55996E91-756E-4FBE-A904-C0B26B24B183" From: Teco Boot In-Reply-To: Date: Fri, 27 Jan 2012 14:32:24 +0100 Message-Id: <45101845-97A2-41CA-8947-24C1C15990AC@inf-net.nl> References: To: paws@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 13:32:30 -0000 --Apple-Mail=_55996E91-756E-4FBE-A904-C0B26B24B183 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Maintainers of the document, please check my text on "free" and "freed" = in use case 4.7. I'm not native english speaker. I meant "free" as "unused", and "freed" as "now unused". On terminology: there are endless possibilities: "paid, unused", "free = of charge but licensed", "licensed, but non-exclusive" etc etc. Teco Op 27 jan. 2012, om 14:11 heeft Peter Stanforth het volgende geschreven: > If this is a protocol for accessing white space why do we care. > Besides The terms exclusive and non exclusive are much more = appropriate. > A " license" implies exclusivity, where as "unlicensed or license = exempt" imply non exclusivity. > The term licensed and unlicensed get juxtaposed too often to imply = "paid for" and "free". > The PAWS protocol should include enough information such that the = access to the spectrum could be paid for. There is nothing that says = White Space access has to be free. >=20 > From: Nancy Bravin > Date: Fri, 27 Jan 2012 01:08:21 -0500 > To: "scott.probasco@nokia.com" > Cc: "paws@ietf.org" > Subject: [paws] re proposed edits on rev 2 >=20 > Dear Scott, Raj, and all, >=20 > Abstract >=20 > Portions of the radio spectrum that are allocated to a licensed, > primary user but are unused or unoccupied at specific locations and > times are defined as "white space". The concept of allowing > secondary transmissions (licensed or unlicensed) in white space is = a > technique to "unlock" existing spectrum for new use. > I would change (licensed or unlicensed) to: (licensed, licensed exempt = or unlicensed) as some countries have 3 categories. > Also, license exempt is mentioned in section 4.4 >=20 >=20 > SIncerely, Nancy > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_55996E91-756E-4FBE-A904-C0B26B24B183 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I = meant "free" as "unused", and "freed" as "now = unused".

On terminology: there are = endless possibilities: "paid, unused", "free of charge but = licensed", "licensed, but non-exclusive" etc = etc.

Teco

Op 27 jan. = 2012, om 14:11 heeft Peter Stanforth het volgende geschreven:

If this is a protocol for = accessing white space why do we care.
Besides The terms = exclusive and non exclusive are much more appropriate.
A " = license" implies exclusivity, where as "unlicensed or license exempt" = imply non exclusivity.
The term licensed and unlicensed get = juxtaposed too often to imply "paid for" and "free".
The PAWS = protocol should include enough information such that the access to the = spectrum could be paid for. There is nothing that says White Space = access has to be free.

From: = Nancy Bravin <nbravin@earthlink.net>
Date: Fri, 27 Jan 2012 01:08:21 = -0500
To: "scott.probasco@nokia.com" = <scott.probasco@nokia.com><= br>Cc: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] re proposed edits on = rev 2

Dear = Scott, Raj, and all,

Abstract

   Portions of the =
radio spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as "white space".  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to "unlock" existing spectrum for new =
use.
I would change (licensed or unlicensed) to: (licensed, = licensed exempt or unlicensed) as some countries have 3 = categories.
 Also, license exempt is mentioned in section = 4.4


SIncerely, Nancy
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail=_55996E91-756E-4FBE-A904-C0B26B24B183-- From scott.probasco@nokia.com Fri Jan 27 06:26:23 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E25621F85A4 for ; Fri, 27 Jan 2012 06:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eC2-R7UaMJeV for ; Fri, 27 Jan 2012 06:26:22 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1A17621F859E for ; Fri, 27 Jan 2012 06:26:21 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0REPmNe006128; Fri, 27 Jan 2012 16:26:18 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 16:26:00 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 15:25:59 +0100 From: To: , Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: AQHM3LoW2opnfu8w4keChWGX2uEgX5YgID4A//+wIIA= Date: Fri, 27 Jan 2012 14:25:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.50.108] Content-Type: multipart/alternative; boundary="_000_CB480E1CFACAscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 14:26:00.0702 (UTC) FILETIME=[97B6E9E0:01CCDCFF] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 14:26:23 -0000 --_000_CB480E1CFACAscottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, I agree with your point, there is nothing that says that white space access= has to be free. >From a terminology perspective, if we equate "license" with "exclusivity" d= on't we risk confusion whereby "exclusivity" implies that white space use o= f the spectrum is precluded? Kind Regards, Scott From: "ext com>" = > Date: Fri, 27 Jan 2012 08:11:50 -0500 To: Nancy Bravin >, Sco= tt > Cc: "paws@ietf.org" > Subject: Re: [paws] re proposed edits on rev 2 If this is a protocol for accessing white space why do we care. Besides The terms exclusive and non exclusive are much more appropriate. A " license" implies exclusivity, where as "unlicensed or license exempt" i= mply non exclusivity. The term licensed and unlicensed get juxtaposed too often to imply "paid fo= r" and "free". The PAWS protocol should include enough information such that the access to= the spectrum could be paid for. There is nothing that says White Space acc= ess has to be free. From: Nancy Bravin > Date: Fri, 27 Jan 2012 01:08:21 -0500 To: "scott.probasco@nokia.com" > Cc: "paws@ietf.org" > Subject: [paws] re proposed edits on rev 2 Dear Scott, Raj, and all, Abstract Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. I would change (licensed or unlicensed) to: (licensed, licensed exempt or u= nlicensed) as some countries have 3 categories. Also, license exempt is mentioned in section 4.4 SIncerely, Nancy --_000_CB480E1CFACAscottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Peter,

I agree with your point, there is nothing that says that white space a= ccess has to be free.

From a terminology perspective, if we equate "license" with = "exclusivity" don't we risk confusion whereby "exclusivity&q= uot; implies that white space use of the spectrum is precluded?

Kind Regards,
Scott

From: "ext com>" <<= a href=3D"mailto:peter@spectrumbridge.com">peter@spectrumbridge.com>=
Date: Fri, 27 Jan 2012 08:11:50 -05= 00
To: Nancy Bravin <nbravin@earthlink.net>, Scott <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] re proposed edi= ts on rev 2

If this is a protocol for accessing white space why do we care.
Besides The terms exclusive and non exclusive are much more appropriat= e.
A " license" implies exclusivity, where as "unlicensed = or license exempt" imply non exclusivity.
The term licensed and unlicensed get juxtaposed too often to imply &qu= ot;paid for" and "free".
The PAWS protocol should include enough information such that the acce= ss to the spectrum could be paid for. There is nothing that says White Spac= e access has to be free.

From: Nancy Bravin <nbravin@earthlink.net>
Date: Fri, 27 Jan 2012 01:08:21 -05= 00
To: "scott.probasco@nokia.com" <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] re proposed edits o= n rev 2

Dear Scott, Raj, and all, 

Abstract

   Portions of the radio=
 spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as "white space".  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to "unlock" existing spectrum for new use.


I would change (lic=
ensed or unlicensed) to: (licensed, licensed exempt or unlicensed) as some =
countries have 3 categories.


 Also, license=
 exempt is mentioned in section 4.4


SIncerely, Nancy
 --_000_CB480E1CFACAscottprobasconokiacom_-- From scott.probasco@nokia.com Fri Jan 27 06:26:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840D821F8599 for ; Fri, 27 Jan 2012 06:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5oAxHfqdV0a for ; Fri, 27 Jan 2012 06:26:35 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8032D21F859E for ; Fri, 27 Jan 2012 06:26:35 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0REQNLF025914; Fri, 27 Jan 2012 16:26:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 16:26:22 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 15:26:22 +0100 From: To: , Thread-Topic: [paws] re proposed edits on rev 2 Thread-Index: AQHM3LoW2opnfu8w4keChWGX2uEgX5YgID4AgAAFvwD//6p7gA== Date: Fri, 27 Jan 2012 14:26:21 +0000 Message-ID: In-Reply-To: <45101845-97A2-41CA-8947-24C1C15990AC@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.50.108] Content-Type: multipart/alternative; boundary="_000_CB480B60FAB1scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 14:26:22.0888 (UTC) FILETIME=[A4F03A80:01CCDCFF] X-Nokia-AV: Clean Subject: Re: [paws] re proposed edits on rev 2 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 14:26:36 -0000 --_000_CB480B60FAB1scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Teco, In section 4.7 there are probably several alternative word choices which wo= uld work well. A couple are free -> unused freed -> cleared Kind Regards, Scott From: ext Teco Boot > Date: Fri, 27 Jan 2012 14:32:24 +0100 To: "paws@ietf.org" > Cc: Nancy Bravin >, Sco= tt >, "ext com>" = > Subject: Re: [paws] re proposed edits on rev 2 Maintainers of the document, please check my text on "free" and "freed" in = use case 4.7. I'm not native english speaker. I meant "free" as "unused", and "freed" as "now unused". On terminology: there are endless possibilities: "paid, unused", "free of c= harge but licensed", "licensed, but non-exclusive" etc etc. Teco Op 27 jan. 2012, om 14:11 heeft Peter Stanforth het volgende geschreven: If this is a protocol for accessing white space why do we care. Besides The terms exclusive and non exclusive are much more appropriate. A " license" implies exclusivity, where as "unlicensed or license exempt" i= mply non exclusivity. The term licensed and unlicensed get juxtaposed too often to imply "paid fo= r" and "free". The PAWS protocol should include enough information such that the access to= the spectrum could be paid for. There is nothing that says White Space acc= ess has to be free. From: Nancy Bravin > Date: Fri, 27 Jan 2012 01:08:21 -0500 To: "scott.probasco@nokia.com" > Cc: "paws@ietf.org" > Subject: [paws] re proposed edits on rev 2 Dear Scott, Raj, and all, Abstract Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. I would change (licensed or unlicensed) to: (licensed, licensed exempt or u= nlicensed) as some countries have 3 categories. Also, license exempt is mentioned in section 4.4 SIncerely, Nancy _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CB480B60FAB1scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Teco,

In section 4.7 there are probably several alternative word choices whi= ch would work well. A couple are
     free -> unused
     freed -> cleared

Kind Regards,
Scott

From: ext Teco Boot <teco@inf-net.nl>
Date: Fri, 27 Jan 2012 14:32:24 = 3;0100
To: "paws@ietf.org" <paws@i= etf.org>
Cc: Nancy Bravin <nbravin@earthlink.net>, Scott <scott.probasco@nokia.com>, &quo= t;ext com>" <peter@s= pectrumbridge.com>
Subject: Re: [paws] re proposed edi= ts on rev 2

Maintainers of the document, please check my text on "free" = and "freed" in use case 4.7. I'm not native english speaker.
I meant "free" as "unused", and "freed" = as "now unused".

On terminology: there are endless possibilities: "paid, unus= ed", "free of charge but licensed", "licensed, but non-= exclusive" etc etc.

Teco

Op 27 jan. 2012, om 14:11 heeft Peter Stanforth het volgende geschreve= n:

If this is a protocol for accessing white space why do we care.
Besides The terms exclusive and non exclusive are much more appropriat= e.
A " license" implies exclusivity, where as "unlicensed = or license exempt" imply non exclusivity.
The term licensed and unlicensed get juxtaposed too often to imply &qu= ot;paid for" and "free".
The PAWS protocol should include enough information such that the acce= ss to the spectrum could be paid for. There is nothing that says White Spac= e access has to be free.

From: Nancy Bravin <nbravin@earthlink.net>
Date: Fri, 27 Jan 2012 01:08:21 -05= 00
To: "scott.probasco@nokia.com" <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] re proposed edits o= n rev 2

Dear Scott, Raj, and all, 

Abstract

   Portions of the radio=
 spectrum that are allocated to a licensed,
   primary user but are unused or unoccupied at specific locations and
   times are defined as "white space".  The concept of allowing
   secondary transmissions (licensed or unlicensed) in white space is a
   technique to "unlock" existing spectrum for new use.


I would change (lic=
ensed or unlicensed) to: (licensed, licensed exempt or unlicensed) as some =
countries have 3 categories.


 Also, license=
 exempt is mentioned in section 4.4


SIncerely, Nancy
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws

--_000_CB480B60FAB1scottprobasconokiacom_-- From scott.probasco@nokia.com Fri Jan 27 06:39:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5392E21F857D for ; Fri, 27 Jan 2012 06:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z335QROGt-E for ; Fri, 27 Jan 2012 06:39:00 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 640C421F85A8 for ; Fri, 27 Jan 2012 06:39:00 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0REcwad008026; Fri, 27 Jan 2012 16:38:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 16:38:58 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 15:38:57 +0100 From: To: Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AQHM3IQ4n1t+3SSARU+3UJjogvpO2ZYf3jEA///2OIA= Date: Fri, 27 Jan 2012 14:38:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.50.108] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 14:38:58.0590 (UTC) FILETIME=[675F33E0:01CCDD01] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 14:39:01 -0000 Hi Teco, I agree with you that "TVWS database discovery" and "Device registration with trusted Database" are aspects of the protocol, perhaps services, rather than use cases. However since these topics are describing capability required from the protocol, placing them in a section titled "Problem Statement" could also be unclear. If we change the title of section 4 to "Use cases and protocol services" would this be acceptable? Kind Regards, Scott On 1/27/12 3:13 AM, "ext Teco Boot" wrote: >Hi Scott, > >IMHO the first 2 use cases "TVWS database discovery" and "Device >registration with trusted Database" are not real use cases, but >aspects of the protocol. Text says "prerequisite to other use cases". > >They could move to the Problem Statement section and combine >text. There is already a "5.2. Database discovery". The other section >would need a "5.x Device registration with trusted Database". > >Teco > > > >Op 27 jan. 2012, om 00:42 heeft > het volgende geschreven: > >> Hi, >>=20 >> Revision 2 of the PS, Use cases and requirements I-D has been posted. >>Please see: >>=20 >>http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases >>-rqmts-02.txt >>=20 >> This version only includes changes requested by the co-chair in his >>email of January 12 >>http://www.ietf.org/mail-archive/web/paws/current/msg00516.html >> Specifically: >> " >>> 2. requirements. In the last f2f >>> we agreed to modify requirement D.1 to include the suggestions from >>>slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and >>>merge with D.6 and D.9 >>> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>also contain suggestions on how to revise this requirement. >>> Agreed to revise requirement D.2 as suggested in slide 11 of >>>http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of >>>http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>> We seem to have agreed with the reformulation suggested to D.3 in >>>slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we >>>did not agree on the format the location would be represented in. The >>>data format part is still open, but as this piece does not really >>>belong to requirements but rather the data model spec, we are not in a >>>hurry to decide it. >>> Delete d.4 >>> D.5: augment with lower/upper frequencies and time of availability, as >>>suggested on slide 10 >>>ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >>> D.6: change power to eirp, as suggested in slide 13 of >>>http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >>> D.7: change to single and multiple locations. Clarify that in case of >>>multiple locations the channel availability for each location should be >>>sent by the db. >>> D.8: delete >> " >>>=20 >> And >> " >>> Operational requirements: slides 22-24 of >>>http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain >>>suggestions on rewording, I propose the editor considers them. >> " >>=20 >>=20 >> Regards, >> Scott & Raj >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > From teco@inf-net.nl Fri Jan 27 07:13:34 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE62D21F85AC for ; Fri, 27 Jan 2012 07:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUDseyxWZW+O for ; Fri, 27 Jan 2012 07:13:33 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E20921F8513 for ; Fri, 27 Jan 2012 07:13:32 -0800 (PST) Received: by eaai12 with SMTP id i12so25659eaa.31 for ; Fri, 27 Jan 2012 07:13:31 -0800 (PST) Received: by 10.213.19.140 with SMTP id a12mr1260934ebb.58.1327677211729; Fri, 27 Jan 2012 07:13:31 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id y12sm30314457eeb.11.2012.01.27.07.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 Jan 2012 07:13:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 27 Jan 2012 16:13:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 15:13:35 -0000 Hi Scott, I'm fine with your proposal. Make section 4 multi-level and reword "use case" in the two protocol=20 service sections? Thanks, Teco Op 27 jan. 2012, om 15:38 heeft = het volgende geschreven: > Hi Teco, >=20 > I agree with you that "TVWS database discovery" and "Device = registration > with trusted Database" are aspects of the protocol, perhaps services, > rather than use cases. However since these topics are describing > capability required from the protocol, placing them in a section = titled > "Problem Statement" could also be unclear. >=20 > If we change the title of section 4 to "Use cases and protocol = services" > would this be acceptable? >=20 > Kind Regards, > Scott >=20 >=20 >=20 > On 1/27/12 3:13 AM, "ext Teco Boot" wrote: >=20 >> Hi Scott, >>=20 >> IMHO the first 2 use cases "TVWS database discovery" and "Device >> registration with trusted Database" are not real use cases, but >> aspects of the protocol. Text says "prerequisite to other use cases". >>=20 >> They could move to the Problem Statement section and combine >> text. There is already a "5.2. Database discovery". The other = section >> would need a "5.x Device registration with trusted Database". >>=20 >> Teco >>=20 >>=20 >>=20 >> Op 27 jan. 2012, om 00:42 heeft >> het volgende geschreven: >>=20 >>> Hi, >>>=20 >>> Revision 2 of the PS, Use cases and requirements I-D has been = posted. >>> Please see: >>>=20 >>> = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases >>> -rqmts-02.txt >>>=20 >>> This version only includes changes requested by the co-chair in his >>> email of January 12 >>> http://www.ietf.org/mail-archive/web/paws/current/msg00516.html >>> Specifically: >>> " >>>> 2. requirements. In the last f2f >>>> we agreed to modify requirement D.1 to include the suggestions from >>>> slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf = and >>>> merge with D.6 and D.9 >>>> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>> also contain suggestions on how to revise this requirement. >>>> Agreed to revise requirement D.2 as suggested in slide 11 of >>>> http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of >>>> http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>> We seem to have agreed with the reformulation suggested to D.3 in >>>> slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, = but we >>>> did not agree on the format the location would be represented in. = The >>>> data format part is still open, but as this piece does not really >>>> belong to requirements but rather the data model spec, we are not = in a >>>> hurry to decide it. >>>> Delete d.4 >>>> D.5: augment with lower/upper frequencies and time of availability, = as >>>> suggested on slide 10 >>>> ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>> D.6: change power to eirp, as suggested in slide 13 of >>>> http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >>>> D.7: change to single and multiple locations. Clarify that in case = of >>>> multiple locations the channel availability for each location = should be >>>> sent by the db. >>>> D.8: delete >>> " >>>>=20 >>> And >>> " >>>> Operational requirements: slides 22-24 of >>>> http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain >>>> suggestions on rewording, I propose the editor considers them. >>> " >>>=20 >>>=20 >>> Regards, >>> Scott & Raj >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 From stpeter@stpeter.im Fri Jan 27 08:02:06 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613B721F85E6 for ; Fri, 27 Jan 2012 08:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4YseP3UzRGD for ; Fri, 27 Jan 2012 08:02:02 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6E23421F85E1 for ; Fri, 27 Jan 2012 08:02:02 -0800 (PST) Received: from dhcp-64-101-72-231.cisco.com (unknown [64.101.72.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4D91D4005B; Fri, 27 Jan 2012 09:11:53 -0700 (MST) Message-ID: <4F22C618.40005@stpeter.im> Date: Fri, 27 Jan 2012 08:43:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Gabor.Bajko@nokia.com References: <4F0E09A2.1080407@stpeter.im> <1ECAFF543A2FED4EA2BEB6CACE08E47601DA368F@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DA368F@008-AM1MPN1-006.mgdnok.nokia.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] WG activity X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:02:06 -0000 Given the burst of activity over the last few weeks and the editors' intention to get their document in shape for WGLC soon, I'm no longer concerned. :) Good progress! On 1/11/12 5:47 PM, Gabor.Bajko@nokia.com wrote: > I wanted to give folks some time to prepare what they committed for in the last f2f, but maybe this is a little too much time as it is perceived as inactivity. > Anyway, I'll send a reminder of what we need to do tomorrow, then we take it from there. > > - Gabor > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter Saint-Andre > Sent: Wednesday, January 11, 2012 2:14 PM > To: paws@ietf.org > Subject: [paws] WG activity > > > > It's been almost two months since the last message was posted to this list. Has interest waned? Are there open issues with the use cases and requirements? If not, is it time to start working on the protocol? > > Please note that the deadline for requesting a WG session at IETF 83 in Paris is January 30. It would be good to get a sense of agenda topics before then, so discussion is very much encouraged. > > Thanks! > > Peter > > -- > Peter Saint-Andre > http://stpeter.im/ > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From stpeter@stpeter.im Fri Jan 27 08:02:07 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EFA21F85E6 for ; Fri, 27 Jan 2012 08:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5DFXTxxYu4z for ; Fri, 27 Jan 2012 08:02:03 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBD221F85E3 for ; Fri, 27 Jan 2012 08:02:03 -0800 (PST) Received: from dhcp-64-101-72-231.cisco.com (unknown [64.101.72.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CB4A640075; Fri, 27 Jan 2012 09:11:54 -0700 (MST) Message-ID: <4F22C6D3.6040903@stpeter.im> Date: Fri, 27 Jan 2012 08:46:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Security Requirements (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:02:08 -0000 On 1/19/12 9:02 AM, Basavaraj.Patil@nokia.com wrote: > > Hi Gabor, > > Peter's comment : "I think it would be better to consider the various > threat levels and then decide how to provide reasonable protection against > them in a comprehensive way." makes sense. > It is unnecessary to specify requirements such as the need for OCSP in > case certificate based authentication is used etc. > Rather, lets specify a broader set of security requirements based on the > threat model and let the solution(s) decide what would be the best > approach for dealing with such security needs. Typically, IETF protocols specify a baseline (e.g., minimum TLS version, rules for cert checking) so that we can ensure basic interoperability. Is there a reason why we would not do the same here? Peter -- Peter Saint-Andre https://stpeter.im/ From stephen.farrell@cs.tcd.ie Fri Jan 27 08:15:54 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9417821F85FD for ; Fri, 27 Jan 2012 08:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.741 X-Spam-Level: X-Spam-Status: No, score=-102.741 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xFwkg-YInCa for ; Fri, 27 Jan 2012 08:15:53 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 82F7A21F850C for ; Fri, 27 Jan 2012 08:15:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D02B6153B00; Fri, 27 Jan 2012 16:15:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1327680951; bh=Md/miIfbsqgul1 IAM9/cKlctMhWBPkus2HMS/70nKEs=; b=bZWDxBYIxy64ehz0wlbXJBcZmZOt8H FaC1UbZ18kIltW3FMhjUp/ekQg2YKkZBN5cs22Gffj+HT8uyUy7ElJUi0AcvfT/x uB84vSo/1TTgqs7SQS6bIgf2aZgMFcQVFbwtUBTBJNkQQwdZ8+NsaEJ6QNXdsyJH YVPReUb1xPg0yqSPNp3au/8+fHr0r/+Ie4qf+6XiHrX1O/j4jVnkMuUV6PGWqKAH Tss8a8ZTrIHzJZuW2RbUomivGGTQyYGepq0GAfsHwKO0AI6z478Vy5sKTFu/UDUP z/nzZ/TYvzGIgQiXIANpxiKVkF8f69bt5Agky+mZYQyAOz67HLvYOvNA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id iauTzhzxsxsX; Fri, 27 Jan 2012 16:15:51 +0000 (GMT) Received: from [10.1.1.138] (wifi.ist.utl.pt [193.136.128.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A3D0C153AFF; Fri, 27 Jan 2012 16:15:50 +0000 (GMT) Message-ID: <4F22CDB7.4070604@cs.tcd.ie> Date: Fri, 27 Jan 2012 16:15:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <4F22C6D3.6040903@stpeter.im> In-Reply-To: <4F22C6D3.6040903@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Security Requirements (was: next steps for the wg) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:15:54 -0000 On 01/27/2012 03:46 PM, Peter Saint-Andre wrote: > On 1/19/12 9:02 AM, Basavaraj.Patil@nokia.com wrote: >> >> Hi Gabor, >> >> Peter's comment : "I think it would be better to consider the various >> threat levels and then decide how to provide reasonable protection against >> them in a comprehensive way." makes sense. >> It is unnecessary to specify requirements such as the need for OCSP in >> case certificate based authentication is used etc. >> Rather, lets specify a broader set of security requirements based on the >> threat model and let the solution(s) decide what would be the best >> approach for dealing with such security needs. > > Typically, IETF protocols specify a baseline (e.g., minimum TLS version, > rules for cert checking) so that we can ensure basic interoperability. > Is there a reason why we would not do the same here? I do hope not:-) Also, not sure if the WG are treating privacy and security in one go, but the charter does say; "Robust privacy and security mechanisms are needed..." So I also hope that gets considered. I don't see it in the current reqs. draft but have not read that fully. Cheers, S > > Peter > From Basavaraj.Patil@nokia.com Fri Jan 27 11:39:13 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D9421F861D for ; Fri, 27 Jan 2012 11:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pejf4K2n+uFd for ; Fri, 27 Jan 2012 11:39:12 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8C34121F850F for ; Fri, 27 Jan 2012 11:39:05 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RJd2gu000613 for ; Fri, 27 Jan 2012 21:39:04 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 21:39:02 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 20:39:01 +0100 From: To: Thread-Topic: Threat model Thread-Index: AQHM3StRJwsi78gZm0WinGjlBlOxJg== Date: Fri, 27 Jan 2012 19:39:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <1C1271D355E2D44AB909F17B02A571AE@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 19:39:02.0309 (UTC) FILETIME=[526CB550:01CCDD2B] X-Nokia-AV: Clean Subject: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:39:13 -0000 Hello, While discussing the requirements we concluded that it would be useful to have a threat model for PAWS. Below is an initial writeup of the threat model. This threat model can be included in the Security considerations section of the Use-case and Requirements I-D. Security requirements can be derived from this threat model. Comments welcome. -Raj Threat model for the PAWS protocol ---------------------------------- Assumptions: ............ o It is assumed that an attacker has full access to the network medium between the master device and the white space database. The attacker may be able to eavesdrop on any communications between these entities. The link between the master device and the white space database can be wired or wireless and provides IP connectivity. o It is assumed that the master device or the white space database have NOT been compromised from a security standpoint. Threat 1: Obtain master device authentication/authorization secrets The master device needs to authenticate itself with the white space database prior to requesting channel information. The attacker may try to get access to the secrets of the master device which can be used maliciously. The effect of such an attack being successful would result in a malicious client replaying the stolen authentication/authorization secrets to a white space database. Threat 2: Spoofed white space database A master device discovers a white space database(s) thru which it can query for channel information. The master device needs to ensure that the white space database with which it communicates with is an authentic entity. The white space database needs to provide its identity to the master device which can confirm the validity/authenticty of the database. An attacker may attempt to spoof a white space database and provide responses to a master device which are malicious and result in the master device causing interference to the primary user of the spectrum. Threat 3: Modifying a query request An attacker may modify the query request sent by a master device to a white space database. The attacker may change the location of the device or the capabilities in terms of its transmit power or antenna height etc. which could result in the database responding with incorrect information about available channels or max transmit power allowed. The result of such an attack is that the master device would cause intereference to the primary user of the spectrum. It could also result in a denial of service to the master device by indicating that no channels are available. Threat 4: Modifying a query response An attacker could modify the query response sent by the white space database to a master device. The channel information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using channels that are not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. Alternatively the attacker may indicate no channel availability at a location resulting in a denial of service to the master device. Threat 5: Using query response information An attacker may be a master device which is not certified for use by the relevant regulatory body. The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. The result of such an attack is unauthorized use of channels by a master device which is not certified to operate. From jmh@joelhalpern.com Fri Jan 27 11:49:50 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7789721F864C for ; Fri, 27 Jan 2012 11:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.049 X-Spam-Level: X-Spam-Status: No, score=-102.049 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRvWPQcauw6L for ; Fri, 27 Jan 2012 11:49:49 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D926521F863F for ; Fri, 27 Jan 2012 11:49:49 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 59D11CD149 for ; Fri, 27 Jan 2012 11:49:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 31AE91C08F9; Fri, 27 Jan 2012 11:49:48 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 578D41C0891; Fri, 27 Jan 2012 11:49:47 -0800 (PST) Message-ID: <4F22FFD2.5090204@joelhalpern.com> Date: Fri, 27 Jan 2012 14:49:38 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 19:49:50 -0000 Most of this looks good. The last one does not seem to make sense to me. I presume I am missing something. What follows is why I am confused, with apologies if I have overlooked something. Given the nature of the system, the number of ways for a non-cooperative client to get the information about what the compliant clients are allowed to do seems myriad. And the number of ways a non-compliant client can mis-behave is also myriad. So I do not actually understand the threat. I can imagine privacy-driven confidentiality with regard to requests. I hope we don't have to go there, but that would be a threat that I would think was more of an issue than receving a copy of a response. Yours, Joel M. Halpern On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: > > Hello, > > While discussing the requirements we concluded that it would be useful to > have a threat model for PAWS. Below is an initial writeup of the threat > model. This threat model can be included in the Security considerations > section of the Use-case and Requirements I-D. Security requirements can be > derived from this threat model. > Comments welcome. > > -Raj > > > Threat model for the PAWS protocol > ---------------------------------- > > Assumptions: > ............ > > o It is assumed that an attacker has full access to the network medium > between the master device and the white space database. The attacker > may be able to eavesdrop on any communications between these > entities. The link between the master device and the white space > database can be wired or wireless and provides IP connectivity. > > o It is assumed that the master device or the white space database > have NOT been compromised from a security standpoint. > > Threat 1: Obtain master device authentication/authorization secrets > The master device needs to authenticate itself with the white > space database prior to requesting channel information. The > attacker may try to get access to the secrets of the master > device which can be used maliciously. The effect of such an > attack being successful would result in a malicious client > replaying the stolen authentication/authorization secrets to a > white space database. > > Threat 2: Spoofed white space database > A master device discovers a white space database(s) thru which > it can query for channel information. The master device needs > to ensure that the white space database with which it > communicates with is an authentic entity. The white space > database needs to provide its identity to the master device > which can confirm the validity/authenticty of the database. An > attacker may attempt to spoof a white space database and > provide responses to a master device which are malicious and > result in the master device causing interference to the primary > user of the spectrum. > > Threat 3: Modifying a query request > An attacker may modify the query request sent by a master > device to a white space database. The attacker may change the > location of the device or the capabilities in terms of its > transmit power or antenna height etc. which could result in the > database responding with incorrect information about available > channels or max transmit power allowed. The result of such an > attack is that the master device would cause intereference to > the primary user of the spectrum. It could also result in a > denial of service to the master device by indicating that no > channels are available. > > Threat 4: Modifying a query response > An attacker could modify the query response sent by the white > space database to a master device. The channel information or > transmit power allowed type of parameters carried in the > response could be modified by the attacker resulting in the > master device using channels that are not available at a > location or transmitting at a greater power level than allowed > resulting in interference to the primary user of that > spectrum. Alternatively the attacker may indicate no channel > availability at a location resulting in a denial of service to > the master device. > > Threat 5: Using query response information > An attacker may be a master device which is not certified for > use by the relevant regulatory body. The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. The result > of such an attack is unauthorized use of channels by a master > device which is not certified to operate. > > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From Basavaraj.Patil@nokia.com Fri Jan 27 12:01:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF3621F8684 for ; Fri, 27 Jan 2012 12:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J6dG0nZ00yG for ; Fri, 27 Jan 2012 12:01:20 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 485D121F8671 for ; Fri, 27 Jan 2012 12:01:18 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RK1GXF032359; Fri, 27 Jan 2012 22:01:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 22:01:16 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 21:01:15 +0100 From: To: Thread-Topic: [paws] Threat model Thread-Index: AQHM3SzX7z1G5jgDO0GoIcs3y0bfS5YgLSUA Date: Fri, 27 Jan 2012 20:01:14 +0000 Message-ID: In-Reply-To: <4F22FFD2.5090204@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <0C5AE2CCD3B38E40B57F558FD9F682AB@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 20:01:16.0127 (UTC) FILETIME=[6D712EF0:01CCDD2E] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:01:21 -0000 Joel, A white space database MUST respond with available channel information only to a certified master device. Threat 5 is about master devices which have not been approved/certified by a regulatory body in a specific country. What threat 5 essentially implies in terms of security requirements is the need for the data to be encrypted. The response message MUST be encrypted by the white space database so that a MiTM cannot read the data and use that information. -Raj On 1/27/12 1:49 PM, "ext Joel M. Halpern" wrote: >Most of this looks good. >The last one does not seem to make sense to me. >I presume I am missing something. What follows is why I am confused, >with apologies if I have overlooked something. > >Given the nature of the system, the number of ways for a non-cooperative >client to get the information about what the compliant clients are >allowed to do seems myriad. And the number of ways a non-compliant >client can mis-behave is also myriad. >So I do not actually understand the threat. > >I can imagine privacy-driven confidentiality with regard to requests. I >hope we don't have to go there, but that would be a threat that I would >think was more of an issue than receving a copy of a response. > >Yours, >Joel M. Halpern > >On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: >> >> Hello, >> >> While discussing the requirements we concluded that it would be useful >>to >> have a threat model for PAWS. Below is an initial writeup of the threat >> model. This threat model can be included in the Security considerations >> section of the Use-case and Requirements I-D. Security requirements can >>be >> derived from this threat model. >> Comments welcome. >> >> -Raj >> >> >> Threat model for the PAWS protocol >> ---------------------------------- >> >> Assumptions: >> ............ >> >> o It is assumed that an attacker has full access to the network medium >> between the master device and the white space database. The attacker >> may be able to eavesdrop on any communications between these >> entities. The link between the master device and the white space >> database can be wired or wireless and provides IP connectivity. >> >> o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >> Threat 1: Obtain master device authentication/authorization secrets >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >> >> Threat 2: Spoofed white space database >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. >> >> Threat 3: Modifying a query request >> An attacker may modify the query request sent by a master >> device to a white space database. The attacker may change the >> location of the device or the capabilities in terms of its >> transmit power or antenna height etc. which could result in the >> database responding with incorrect information about available >> channels or max transmit power allowed. The result of such an >> attack is that the master device would cause intereference to >> the primary user of the spectrum. It could also result in a >> denial of service to the master device by indicating that no >> channels are available. >> >> Threat 4: Modifying a query response >> An attacker could modify the query response sent by the white >> space database to a master device. The channel information or >> transmit power allowed type of parameters carried in the >> response could be modified by the attacker resulting in the >> master device using channels that are not available at a >> location or transmitting at a greater power level than allowed >> resulting in interference to the primary user of that >> spectrum. Alternatively the attacker may indicate no channel >> availability at a location resulting in a denial of service to >> the master device. >> >> Threat 5: Using query response information >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >> >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From jmh@joelhalpern.com Fri Jan 27 12:08:17 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775B321F8597 for ; Fri, 27 Jan 2012 12:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.053 X-Spam-Level: X-Spam-Status: No, score=-102.053 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk3pfzUHfya7 for ; Fri, 27 Jan 2012 12:08:16 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D615821F8579 for ; Fri, 27 Jan 2012 12:08:16 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id C5462CD16E for ; Fri, 27 Jan 2012 12:08:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A81A21C08F9; Fri, 27 Jan 2012 12:08:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C09881C0891; Fri, 27 Jan 2012 12:08:15 -0800 (PST) Message-ID: <4F230427.7000408@joelhalpern.com> Date: Fri, 27 Jan 2012 15:08:07 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:08:17 -0000 can you please elaborate on the resultant harm if a non-authorized user receives a copy of the data? Depending upon what that threat is, I can imagine a number of additional issues that would need to be elucidates. Note that if this is because the regulations say that the database must only respond to requests from authorized master, that does not actually lead to a requirement to prevent eavesdropping. The database is still only responding to requests from authorized participants. Yours, Joel On 1/27/2012 3:01 PM, Basavaraj.Patil@nokia.com wrote: > > Joel, > > A white space database MUST respond with available channel information > only to a certified master device. > Threat 5 is about master devices which have not been approved/certified by > a regulatory body in a specific country. > > What threat 5 essentially implies in terms of security requirements is the > need for the data to be encrypted. The response message MUST be encrypted > by the white space database so that a MiTM cannot read the data and use > that information. > > -Raj > > On 1/27/12 1:49 PM, "ext Joel M. Halpern" wrote: > >> Most of this looks good. >> The last one does not seem to make sense to me. >> I presume I am missing something. What follows is why I am confused, >> with apologies if I have overlooked something. >> >> Given the nature of the system, the number of ways for a non-cooperative >> client to get the information about what the compliant clients are >> allowed to do seems myriad. And the number of ways a non-compliant >> client can mis-behave is also myriad. >> So I do not actually understand the threat. >> >> I can imagine privacy-driven confidentiality with regard to requests. I >> hope we don't have to go there, but that would be a threat that I would >> think was more of an issue than receving a copy of a response. >> >> Yours, >> Joel M. Halpern >> >> On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> Hello, >>> >>> While discussing the requirements we concluded that it would be useful >>> to >>> have a threat model for PAWS. Below is an initial writeup of the threat >>> model. This threat model can be included in the Security considerations >>> section of the Use-case and Requirements I-D. Security requirements can >>> be >>> derived from this threat model. >>> Comments welcome. >>> >>> -Raj >>> >>> >>> Threat model for the PAWS protocol >>> ---------------------------------- >>> >>> Assumptions: >>> ............ >>> >>> o It is assumed that an attacker has full access to the network medium >>> between the master device and the white space database. The attacker >>> may be able to eavesdrop on any communications between these >>> entities. The link between the master device and the white space >>> database can be wired or wireless and provides IP connectivity. >>> >>> o It is assumed that the master device or the white space database >>> have NOT been compromised from a security standpoint. >>> >>> Threat 1: Obtain master device authentication/authorization secrets >>> The master device needs to authenticate itself with the white >>> space database prior to requesting channel information. The >>> attacker may try to get access to the secrets of the master >>> device which can be used maliciously. The effect of such an >>> attack being successful would result in a malicious client >>> replaying the stolen authentication/authorization secrets to a >>> white space database. >>> >>> Threat 2: Spoofed white space database >>> A master device discovers a white space database(s) thru which >>> it can query for channel information. The master device needs >>> to ensure that the white space database with which it >>> communicates with is an authentic entity. The white space >>> database needs to provide its identity to the master device >>> which can confirm the validity/authenticty of the database. An >>> attacker may attempt to spoof a white space database and >>> provide responses to a master device which are malicious and >>> result in the master device causing interference to the primary >>> user of the spectrum. >>> >>> Threat 3: Modifying a query request >>> An attacker may modify the query request sent by a master >>> device to a white space database. The attacker may change the >>> location of the device or the capabilities in terms of its >>> transmit power or antenna height etc. which could result in the >>> database responding with incorrect information about available >>> channels or max transmit power allowed. The result of such an >>> attack is that the master device would cause intereference to >>> the primary user of the spectrum. It could also result in a >>> denial of service to the master device by indicating that no >>> channels are available. >>> >>> Threat 4: Modifying a query response >>> An attacker could modify the query response sent by the white >>> space database to a master device. The channel information or >>> transmit power allowed type of parameters carried in the >>> response could be modified by the attacker resulting in the >>> master device using channels that are not available at a >>> location or transmitting at a greater power level than allowed >>> resulting in interference to the primary user of that >>> spectrum. Alternatively the attacker may indicate no channel >>> availability at a location resulting in a denial of service to >>> the master device. >>> >>> Threat 5: Using query response information >>> An attacker may be a master device which is not certified for >>> use by the relevant regulatory body. The attacker may listen to >>> the communication between a valid master device and white space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. The result >>> of such an attack is unauthorized use of channels by a master >>> device which is not certified to operate. >>> >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> > > From scott.probasco@nokia.com Fri Jan 27 12:08:19 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDC021F8597 for ; Fri, 27 Jan 2012 12:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.858 X-Spam-Level: X-Spam-Status: No, score=-2.858 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOoHdw-IGW3x for ; Fri, 27 Jan 2012 12:08:19 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B59F421F8579 for ; Fri, 27 Jan 2012 12:08:18 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RK7dSb009005; Fri, 27 Jan 2012 22:08:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 22:08:04 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 21:08:03 +0100 From: To: , Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AQHM3IQ4n1t+3SSARU+3UJjogvpO2ZYf3jEA///2OICAAG49gP//7bUA Date: Fri, 27 Jan 2012 20:08:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.50.108] Content-Type: text/plain; charset="us-ascii" Content-ID: <3796527184B56C45AE0177B13E0E98DE@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 20:08:04.0245 (UTC) FILETIME=[60B30C50:01CCDD2F] X-Nokia-AV: Clean Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:08:19 -0000 Thanks Teco, I will include this change. Kind Regards, Scott On 1/27/12 9:13 AM, "ext Teco Boot" wrote: >Hi Scott, > >I'm fine with your proposal. >Make section 4 multi-level and reword "use case" in the two protocol >service sections? > >Thanks, Teco > > >Op 27 jan. 2012, om 15:38 heeft > het volgende geschreven: > >> Hi Teco, >>=20 >> I agree with you that "TVWS database discovery" and "Device registration >> with trusted Database" are aspects of the protocol, perhaps services, >> rather than use cases. However since these topics are describing >> capability required from the protocol, placing them in a section titled >> "Problem Statement" could also be unclear. >>=20 >> If we change the title of section 4 to "Use cases and protocol services" >> would this be acceptable? >>=20 >> Kind Regards, >> Scott >>=20 >>=20 >>=20 >> On 1/27/12 3:13 AM, "ext Teco Boot" wrote: >>=20 >>> Hi Scott, >>>=20 >>> IMHO the first 2 use cases "TVWS database discovery" and "Device >>> registration with trusted Database" are not real use cases, but >>> aspects of the protocol. Text says "prerequisite to other use cases". >>>=20 >>> They could move to the Problem Statement section and combine >>> text. There is already a "5.2. Database discovery". The other section >>> would need a "5.x Device registration with trusted Database". >>>=20 >>> Teco >>>=20 >>>=20 >>>=20 >>> Op 27 jan. 2012, om 00:42 heeft >>> het volgende geschreven: >>>=20 >>>> Hi, >>>>=20 >>>> Revision 2 of the PS, Use cases and requirements I-D has been posted. >>>> Please see: >>>>=20 >>>>=20 >>>>http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecas >>>>es >>>> -rqmts-02.txt >>>>=20 >>>> This version only includes changes requested by the co-chair in his >>>> email of January 12 >>>> http://www.ietf.org/mail-archive/web/paws/current/msg00516.html >>>> Specifically: >>>> " >>>>> 2. requirements. In the last f2f >>>>> we agreed to modify requirement D.1 to include the suggestions from >>>>> slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and >>>>> merge with D.6 and D.9 >>>>> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>>> also contain suggestions on how to revise this requirement. >>>>> Agreed to revise requirement D.2 as suggested in slide 11 of >>>>> http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of >>>>> http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>>> We seem to have agreed with the reformulation suggested to D.3 in >>>>> slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but >>>>>we >>>>> did not agree on the format the location would be represented in. The >>>>> data format part is still open, but as this piece does not really >>>>> belong to requirements but rather the data model spec, we are not in >>>>>a >>>>> hurry to decide it. >>>>> Delete d.4 >>>>> D.5: augment with lower/upper frequencies and time of availability, >>>>>as >>>>> suggested on slide 10 >>>>> ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>>> D.6: change power to eirp, as suggested in slide 13 of >>>>> http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >>>>> D.7: change to single and multiple locations. Clarify that in case of >>>>> multiple locations the channel availability for each location should >>>>>be >>>>> sent by the db. >>>>> D.8: delete >>>> " >>>>>=20 >>>> And >>>> " >>>>> Operational requirements: slides 22-24 of >>>>> http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain >>>>> suggestions on rewording, I propose the editor considers them. >>>> " >>>>=20 >>>>=20 >>>> Regards, >>>> Scott & Raj >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>=20 >>=20 > From stpeter@stpeter.im Fri Jan 27 12:30:39 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14CA21F86CA for ; Fri, 27 Jan 2012 12:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH7k9VsvRLZO for ; Fri, 27 Jan 2012 12:30:39 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBAC21F86C9 for ; Fri, 27 Jan 2012 12:30:39 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C95444005A; Fri, 27 Jan 2012 13:40:30 -0700 (MST) Message-ID: <4F23096C.3080004@stpeter.im> Date: Fri, 27 Jan 2012 13:30:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 20:30:39 -0000 On 1/27/12 12:39 PM, Basavaraj.Patil@nokia.com wrote: > > Hello, > > While discussing the requirements we concluded that it would be useful to > have a threat model for PAWS. Below is an initial writeup of the threat > model. This threat model can be included in the Security considerations > section of the Use-case and Requirements I-D. Security requirements can be > derived from this threat model. > Comments welcome. As always, it can be helpful to revisit RFC 3552 and look at some other protocol specifications that describe threat models (e.g., RFC 3833). Peter -- Peter Saint-Andre https://stpeter.im/ From Basavaraj.Patil@nokia.com Fri Jan 27 13:48:53 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4731921F8673 for ; Fri, 27 Jan 2012 13:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIgMi7RPw6+m for ; Fri, 27 Jan 2012 13:48:52 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 265B121F8669 for ; Fri, 27 Jan 2012 13:48:51 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RLmkJx023785; Fri, 27 Jan 2012 23:48:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 23:48:46 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 22:48:46 +0100 From: To: Thread-Topic: [paws] Threat model Thread-Index: AQHM3SzX7z1G5jgDO0GoIcs3y0bfS5YgLSUAgABmgoD//7eMAA== Date: Fri, 27 Jan 2012 21:48:46 +0000 Message-ID: In-Reply-To: <4F230427.7000408@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <9EB66F8D30826A4691C5BCF13FCE818F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 21:48:46.0950 (UTC) FILETIME=[726EA860:01CCDD3D] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:48:53 -0000 Resultant harm from an eavesdropper capable of behaving as a master device is causing interference to the primary owner of the spectrum by transmitting at power levels greater than what is authorized for example. Of course a malicious device could do that without necessarily eavesdropping on the link between an authorized/valid master device and database. But the information about available channels and allowed xmit power limits for example can be used to fine-tune the attack. An unauthorized master device may offer service to other devices using the available channel information for example. This is another resultant harm. It is indeed the case that the database is responding to a valid/authorized master device but the response message is being eavesdropped upon and hence IMO it does raise the requirement for avoiding eavesdropping. -Raj On 1/27/12 2:08 PM, "ext Joel M. Halpern" wrote: >can you please elaborate on the resultant harm if a non-authorized user >receives a copy of the data? Depending upon what that threat is, I can >imagine a number of additional issues that would need to be elucidates. > >Note that if this is because the regulations say that the database must >only respond to requests from authorized master, that does not actually >lead to a requirement to prevent eavesdropping. The database is still >only responding to requests from authorized participants. > >Yours, >Joel > >On 1/27/2012 3:01 PM, Basavaraj.Patil@nokia.com wrote: >> >> Joel, >> >> A white space database MUST respond with available channel information >> only to a certified master device. >> Threat 5 is about master devices which have not been approved/certified >>by >> a regulatory body in a specific country. >> >> What threat 5 essentially implies in terms of security requirements is >>the >> need for the data to be encrypted. The response message MUST be >>encrypted >> by the white space database so that a MiTM cannot read the data and use >> that information. >> >> -Raj >> >> On 1/27/12 1:49 PM, "ext Joel M. Halpern" wrote: >> >>> Most of this looks good. >>> The last one does not seem to make sense to me. >>> I presume I am missing something. What follows is why I am confused, >>> with apologies if I have overlooked something. >>> >>> Given the nature of the system, the number of ways for a >>>non-cooperative >>> client to get the information about what the compliant clients are >>> allowed to do seems myriad. And the number of ways a non-compliant >>> client can mis-behave is also myriad. >>> So I do not actually understand the threat. >>> >>> I can imagine privacy-driven confidentiality with regard to requests. >>>I >>> hope we don't have to go there, but that would be a threat that I would >>> think was more of an issue than receving a copy of a response. >>> >>> Yours, >>> Joel M. Halpern >>> >>> On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> Hello, >>>> >>>> While discussing the requirements we concluded that it would be useful >>>> to >>>> have a threat model for PAWS. Below is an initial writeup of the >>>>threat >>>> model. This threat model can be included in the Security >>>>considerations >>>> section of the Use-case and Requirements I-D. Security requirements >>>>can >>>> be >>>> derived from this threat model. >>>> Comments welcome. >>>> >>>> -Raj >>>> >>>> >>>> Threat model for the PAWS protocol >>>> ---------------------------------- >>>> >>>> Assumptions: >>>> ............ >>>> >>>> o It is assumed that an attacker has full access to the network medium >>>> between the master device and the white space database. The >>>>attacker >>>> may be able to eavesdrop on any communications between these >>>> entities. The link between the master device and the white space >>>> database can be wired or wireless and provides IP connectivity. >>>> >>>> o It is assumed that the master device or the white space database >>>> have NOT been compromised from a security standpoint. >>>> >>>> Threat 1: Obtain master device authentication/authorization secrets >>>> The master device needs to authenticate itself with the white >>>> space database prior to requesting channel information. The >>>> attacker may try to get access to the secrets of the master >>>> device which can be used maliciously. The effect of such an >>>> attack being successful would result in a malicious client >>>> replaying the stolen authentication/authorization secrets to >>>>a >>>> white space database. >>>> >>>> Threat 2: Spoofed white space database >>>> A master device discovers a white space database(s) thru >>>>which >>>> it can query for channel information. The master device needs >>>> to ensure that the white space database with which it >>>> communicates with is an authentic entity. The white space >>>> database needs to provide its identity to the master device >>>> which can confirm the validity/authenticty of the database. >>>>An >>>> attacker may attempt to spoof a white space database and >>>> provide responses to a master device which are malicious and >>>> result in the master device causing interference to the >>>>primary >>>> user of the spectrum. >>>> >>>> Threat 3: Modifying a query request >>>> An attacker may modify the query request sent by a master >>>> device to a white space database. The attacker may change the >>>> location of the device or the capabilities in terms of its >>>> transmit power or antenna height etc. which could result in >>>>the >>>> database responding with incorrect information about >>>>available >>>> channels or max transmit power allowed. The result of such an >>>> attack is that the master device would cause intereference to >>>> the primary user of the spectrum. It could also result in a >>>> denial of service to the master device by indicating that no >>>> channels are available. >>>> >>>> Threat 4: Modifying a query response >>>> An attacker could modify the query response sent by the white >>>> space database to a master device. The channel information or >>>> transmit power allowed type of parameters carried in the >>>> response could be modified by the attacker resulting in the >>>> master device using channels that are not available at a >>>> location or transmitting at a greater power level than >>>>allowed >>>> resulting in interference to the primary user of that >>>> spectrum. Alternatively the attacker may indicate no channel >>>> availability at a location resulting in a denial of service >>>>to >>>> the master device. >>>> >>>> Threat 5: Using query response information >>>> An attacker may be a master device which is not certified for >>>> use by the relevant regulatory body. The attacker may listen >>>>to >>>> the communication between a valid master device and white >>>>space >>>> database and utilize the information about available channels >>>> in the response message by utilizing those channels. The >>>>result >>>> of such an attack is unauthorized use of channels by a master >>>> device which is not certified to operate. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >> >> From Basavaraj.Patil@nokia.com Fri Jan 27 13:57:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FE121F85EA for ; Fri, 27 Jan 2012 13:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCgnq7yqVFM8 for ; Fri, 27 Jan 2012 13:57:09 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id C210B21F84E4 for ; Fri, 27 Jan 2012 13:57:08 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RLv69p005381; Fri, 27 Jan 2012 23:57:06 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 23:57:06 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 22:57:05 +0100 From: To: Thread-Topic: [paws] Threat model Thread-Index: AQHM3TLe6y/Eh1Zai0aFrAeP0NKR+ZYgTXsA Date: Fri, 27 Jan 2012 21:57:05 +0000 Message-ID: In-Reply-To: <4F23096C.3080004@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <76C19AA100275E4283430DFC005F75F6@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 21:57:06.0469 (UTC) FILETIME=[9C2B3550:01CCDD3E] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:57:09 -0000 Thanks for the pointers. The proposed threat model for PAWS is specifically dealing with the following aspect mentioned in Sec 3 of RFC3522: " By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate. This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine. Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are. " The intent is to derive a set of requirements that are applicable for the protocol between the master device and the white space database. Most of the actual security work itself will be done in the solution specifications. -Raj On 1/27/12 2:30 PM, "ext Peter Saint-Andre" wrote: > > >On 1/27/12 12:39 PM, Basavaraj.Patil@nokia.com wrote: >>=20 >> Hello, >>=20 >> While discussing the requirements we concluded that it would be useful >>to >> have a threat model for PAWS. Below is an initial writeup of the threat >> model. This threat model can be included in the Security considerations >> section of the Use-case and Requirements I-D. Security requirements can >>be >> derived from this threat model. >> Comments welcome. > >As always, it can be helpful to revisit RFC 3552 and look at some other >protocol specifications that describe threat models (e.g., RFC 3833). > >Peter > >--=20 >Peter Saint-Andre >https://stpeter.im/ > > From jmh@joelhalpern.com Fri Jan 27 13:58:39 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01FE21F8573 for ; Fri, 27 Jan 2012 13:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.056 X-Spam-Level: X-Spam-Status: No, score=-102.056 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBgVZD3KmfYN for ; Fri, 27 Jan 2012 13:58:39 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE8121F853C for ; Fri, 27 Jan 2012 13:58:39 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id C2E76CD349 for ; Fri, 27 Jan 2012 13:58:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5762C1BDE936; Fri, 27 Jan 2012 13:58:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 849421BDE938; Fri, 27 Jan 2012 13:58:35 -0800 (PST) Message-ID: <4F231DFF.3060107@joelhalpern.com> Date: Fri, 27 Jan 2012 16:58:23 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 21:58:39 -0000 It looks like we are creating a requirement where there isn't one. And if we can avoid mandating encryption, that would seem to make life simpler for all concerned. In fact, for an actual attacker, I think the information from the response is almsot useless. After all, their goal is to interfere with actual use. The numbers from the response presumably icnlude guard regions and safety margins. The attacker is far more likely to be able to actually measure activity, observe multiple locations, and decide what trouble he wants to cause. None of that requires eavesdropping. I would really prefer we as a group not invent requirements that do not respond to meaningful threats. Yours, Joel On 1/27/2012 4:48 PM, Basavaraj.Patil@nokia.com wrote: > > Resultant harm from an eavesdropper capable of behaving as a master device > is causing interference to the primary owner of the spectrum by > transmitting at power levels greater than what is authorized for example. > Of course a malicious device could do that without necessarily > eavesdropping on the link between an authorized/valid master device and > database. But the information about available channels and allowed xmit > power limits for example can be used to fine-tune the attack. > > An unauthorized master device may offer service to other devices using the > available channel information for example. This is another resultant harm. > > It is indeed the case that the database is responding to a > valid/authorized master device but the response message is being > eavesdropped upon and hence IMO it does raise the requirement for avoiding > eavesdropping. > > -Raj > > On 1/27/12 2:08 PM, "ext Joel M. Halpern" wrote: > >> can you please elaborate on the resultant harm if a non-authorized user >> receives a copy of the data? Depending upon what that threat is, I can >> imagine a number of additional issues that would need to be elucidates. >> >> Note that if this is because the regulations say that the database must >> only respond to requests from authorized master, that does not actually >> lead to a requirement to prevent eavesdropping. The database is still >> only responding to requests from authorized participants. >> >> Yours, >> Joel >> >> On 1/27/2012 3:01 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> Joel, >>> >>> A white space database MUST respond with available channel information >>> only to a certified master device. >>> Threat 5 is about master devices which have not been approved/certified >>> by >>> a regulatory body in a specific country. >>> >>> What threat 5 essentially implies in terms of security requirements is >>> the >>> need for the data to be encrypted. The response message MUST be >>> encrypted >>> by the white space database so that a MiTM cannot read the data and use >>> that information. >>> >>> -Raj >>> >>> On 1/27/12 1:49 PM, "ext Joel M. Halpern" wrote: >>> >>>> Most of this looks good. >>>> The last one does not seem to make sense to me. >>>> I presume I am missing something. What follows is why I am confused, >>>> with apologies if I have overlooked something. >>>> >>>> Given the nature of the system, the number of ways for a >>>> non-cooperative >>>> client to get the information about what the compliant clients are >>>> allowed to do seems myriad. And the number of ways a non-compliant >>>> client can mis-behave is also myriad. >>>> So I do not actually understand the threat. >>>> >>>> I can imagine privacy-driven confidentiality with regard to requests. >>>> I >>>> hope we don't have to go there, but that would be a threat that I would >>>> think was more of an issue than receving a copy of a response. >>>> >>>> Yours, >>>> Joel M. Halpern >>>> >>>> On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> Hello, >>>>> >>>>> While discussing the requirements we concluded that it would be useful >>>>> to >>>>> have a threat model for PAWS. Below is an initial writeup of the >>>>> threat >>>>> model. This threat model can be included in the Security >>>>> considerations >>>>> section of the Use-case and Requirements I-D. Security requirements >>>>> can >>>>> be >>>>> derived from this threat model. >>>>> Comments welcome. >>>>> >>>>> -Raj >>>>> >>>>> >>>>> Threat model for the PAWS protocol >>>>> ---------------------------------- >>>>> >>>>> Assumptions: >>>>> ............ >>>>> >>>>> o It is assumed that an attacker has full access to the network medium >>>>> between the master device and the white space database. The >>>>> attacker >>>>> may be able to eavesdrop on any communications between these >>>>> entities. The link between the master device and the white space >>>>> database can be wired or wireless and provides IP connectivity. >>>>> >>>>> o It is assumed that the master device or the white space database >>>>> have NOT been compromised from a security standpoint. >>>>> >>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>> The master device needs to authenticate itself with the white >>>>> space database prior to requesting channel information. The >>>>> attacker may try to get access to the secrets of the master >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets to >>>>> a >>>>> white space database. >>>>> >>>>> Threat 2: Spoofed white space database >>>>> A master device discovers a white space database(s) thru >>>>> which >>>>> it can query for channel information. The master device needs >>>>> to ensure that the white space database with which it >>>>> communicates with is an authentic entity. The white space >>>>> database needs to provide its identity to the master device >>>>> which can confirm the validity/authenticty of the database. >>>>> An >>>>> attacker may attempt to spoof a white space database and >>>>> provide responses to a master device which are malicious and >>>>> result in the master device causing interference to the >>>>> primary >>>>> user of the spectrum. >>>>> >>>>> Threat 3: Modifying a query request >>>>> An attacker may modify the query request sent by a master >>>>> device to a white space database. The attacker may change the >>>>> location of the device or the capabilities in terms of its >>>>> transmit power or antenna height etc. which could result in >>>>> the >>>>> database responding with incorrect information about >>>>> available >>>>> channels or max transmit power allowed. The result of such an >>>>> attack is that the master device would cause intereference to >>>>> the primary user of the spectrum. It could also result in a >>>>> denial of service to the master device by indicating that no >>>>> channels are available. >>>>> >>>>> Threat 4: Modifying a query response >>>>> An attacker could modify the query response sent by the white >>>>> space database to a master device. The channel information or >>>>> transmit power allowed type of parameters carried in the >>>>> response could be modified by the attacker resulting in the >>>>> master device using channels that are not available at a >>>>> location or transmitting at a greater power level than >>>>> allowed >>>>> resulting in interference to the primary user of that >>>>> spectrum. Alternatively the attacker may indicate no channel >>>>> availability at a location resulting in a denial of service >>>>> to >>>>> the master device. >>>>> >>>>> Threat 5: Using query response information >>>>> An attacker may be a master device which is not certified for >>>>> use by the relevant regulatory body. The attacker may listen >>>>> to >>>>> the communication between a valid master device and white >>>>> space >>>>> database and utilize the information about available channels >>>>> in the response message by utilizing those channels. The >>>>> result >>>>> of such an attack is unauthorized use of channels by a master >>>>> device which is not certified to operate. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>> >>> > > From Basavaraj.Patil@nokia.com Fri Jan 27 14:00:16 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3429221F8622 for ; Fri, 27 Jan 2012 14:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sipf2Kj6mgRJ for ; Fri, 27 Jan 2012 14:00:15 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59521F85CE for ; Fri, 27 Jan 2012 14:00:14 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RM0CsW029915 for ; Sat, 28 Jan 2012 00:00:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Jan 2012 00:00:11 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 23:00:10 +0100 From: To: Thread-Topic: White Space Goes Live in Wilmington, N.C Thread-Index: AQHM3T8JXA/UFt9gQEyehMVixXLEVw== Importance: low X-Priority: 5 Date: Fri, 27 Jan 2012 22:00:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 22:00:11.0834 (UTC) FILETIME=[0AA7A9A0:01CCDD3F] X-Nokia-AV: Clean Subject: [paws] FYI: White Space Goes Live in Wilmington, N.C X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:00:16 -0000 Interesting to see a white space based system going live in NC. See: http://bit.ly/xd94aQ From Basavaraj.Patil@nokia.com Fri Jan 27 14:11:26 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5414221F86A8 for ; Fri, 27 Jan 2012 14:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqoWsuuiDknp for ; Fri, 27 Jan 2012 14:11:23 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77021F86CE for ; Fri, 27 Jan 2012 14:11:22 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0RMAxPV011511; Sat, 28 Jan 2012 00:10:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 28 Jan 2012 00:10:58 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 23:10:58 +0100 From: To: Thread-Topic: [paws] Threat model Thread-Index: AQHM3SzX7z1G5jgDO0GoIcs3y0bfS5YgLSUAgABmgoD//7eMAIAAZ0OA//+e8IA= Date: Fri, 27 Jan 2012 22:10:58 +0000 Message-ID: In-Reply-To: <4F231DFF.3060107@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <6524F3E54CBCE34EBB3B3EE45F286B12@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jan 2012 22:10:58.0901 (UTC) FILETIME=[8C564050:01CCDD40] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:11:26 -0000 That=B9s fine. If we as a group agree that this is not a threat that we nee= d to be concerned about, then we do not need a requirement for encryption of the request/response messages. -Raj On 1/27/12 3:58 PM, "ext Joel M. Halpern" wrote: >It looks like we are creating a requirement where there isn't one. >And if we can avoid mandating encryption, that would seem to make life >simpler for all concerned. > >In fact, for an actual attacker, I think the information from the >response is almsot useless. After all, their goal is to interfere with >actual use. The numbers from the response presumably icnlude guard >regions and safety margins. The attacker is far more likely to be able >to actually measure activity, observe multiple locations, and decide >what trouble he wants to cause. None of that requires eavesdropping. > >I would really prefer we as a group not invent requirements that do not >respond to meaningful threats. >Yours, >Joel > >On 1/27/2012 4:48 PM, Basavaraj.Patil@nokia.com wrote: >> >> Resultant harm from an eavesdropper capable of behaving as a master >>device >> is causing interference to the primary owner of the spectrum by >> transmitting at power levels greater than what is authorized for >>example. >> Of course a malicious device could do that without necessarily >> eavesdropping on the link between an authorized/valid master device and >> database. But the information about available channels and allowed xmit >> power limits for example can be used to fine-tune the attack. >> >> An unauthorized master device may offer service to other devices using >>the >> available channel information for example. This is another resultant >>harm. >> >> It is indeed the case that the database is responding to a >> valid/authorized master device but the response message is being >> eavesdropped upon and hence IMO it does raise the requirement for >>avoiding >> eavesdropping. >> >> -Raj >> >> On 1/27/12 2:08 PM, "ext Joel M. Halpern" wrote: >> >>> can you please elaborate on the resultant harm if a non-authorized user >>> receives a copy of the data? Depending upon what that threat is, I can >>> imagine a number of additional issues that would need to be elucidates. >>> >>> Note that if this is because the regulations say that the database must >>> only respond to requests from authorized master, that does not actually >>> lead to a requirement to prevent eavesdropping. The database is still >>> only responding to requests from authorized participants. >>> >>> Yours, >>> Joel >>> >>> On 1/27/2012 3:01 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> Joel, >>>> >>>> A white space database MUST respond with available channel information >>>> only to a certified master device. >>>> Threat 5 is about master devices which have not been >>>>approved/certified >>>> by >>>> a regulatory body in a specific country. >>>> >>>> What threat 5 essentially implies in terms of security requirements is >>>> the >>>> need for the data to be encrypted. The response message MUST be >>>> encrypted >>>> by the white space database so that a MiTM cannot read the data and >>>>use >>>> that information. >>>> >>>> -Raj >>>> >>>> On 1/27/12 1:49 PM, "ext Joel M. Halpern" >>>>wrote: >>>> >>>>> Most of this looks good. >>>>> The last one does not seem to make sense to me. >>>>> I presume I am missing something. What follows is why I am confused, >>>>> with apologies if I have overlooked something. >>>>> >>>>> Given the nature of the system, the number of ways for a >>>>> non-cooperative >>>>> client to get the information about what the compliant clients are >>>>> allowed to do seems myriad. And the number of ways a non-compliant >>>>> client can mis-behave is also myriad. >>>>> So I do not actually understand the threat. >>>>> >>>>> I can imagine privacy-driven confidentiality with regard to requests. >>>>> I >>>>> hope we don't have to go there, but that would be a threat that I >>>>>would >>>>> think was more of an issue than receving a copy of a response. >>>>> >>>>> Yours, >>>>> Joel M. Halpern >>>>> >>>>> On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> While discussing the requirements we concluded that it would be >>>>>>useful >>>>>> to >>>>>> have a threat model for PAWS. Below is an initial writeup of the >>>>>> threat >>>>>> model. This threat model can be included in the Security >>>>>> considerations >>>>>> section of the Use-case and Requirements I-D. Security requirements >>>>>> can >>>>>> be >>>>>> derived from this threat model. >>>>>> Comments welcome. >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> Threat model for the PAWS protocol >>>>>> ---------------------------------- >>>>>> >>>>>> Assumptions: >>>>>> ............ >>>>>> >>>>>> o It is assumed that an attacker has full access to the network >>>>>>medium >>>>>> between the master device and the white space database. The >>>>>> attacker >>>>>> may be able to eavesdrop on any communications between these >>>>>> entities. The link between the master device and the white >>>>>>space >>>>>> database can be wired or wireless and provides IP connectivity. >>>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>>> The master device needs to authenticate itself with the >>>>>>white >>>>>> space database prior to requesting channel information. >>>>>>The >>>>>> attacker may try to get access to the secrets of the >>>>>>master >>>>>> device which can be used maliciously. The effect of such >>>>>>an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets >>>>>>to >>>>>> a >>>>>> white space database. >>>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> A master device discovers a white space database(s) thru >>>>>> which >>>>>> it can query for channel information. The master device >>>>>>needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master >>>>>>device >>>>>> which can confirm the validity/authenticty of the >>>>>>database. >>>>>> An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious >>>>>>and >>>>>> result in the master device causing interference to the >>>>>> primary >>>>>> user of the spectrum. >>>>>> >>>>>> Threat 3: Modifying a query request >>>>>> An attacker may modify the query request sent by a master >>>>>> device to a white space database. The attacker may change >>>>>>the >>>>>> location of the device or the capabilities in terms of its >>>>>> transmit power or antenna height etc. which could result >>>>>>in >>>>>> the >>>>>> database responding with incorrect information about >>>>>> available >>>>>> channels or max transmit power allowed. The result of >>>>>>such an >>>>>> attack is that the master device would cause >>>>>>intereference to >>>>>> the primary user of the spectrum. It could also result in >>>>>>a >>>>>> denial of service to the master device by indicating that >>>>>>no >>>>>> channels are available. >>>>>> >>>>>> Threat 4: Modifying a query response >>>>>> An attacker could modify the query response sent by the >>>>>>white >>>>>> space database to a master device. The channel >>>>>>information or >>>>>> transmit power allowed type of parameters carried in the >>>>>> response could be modified by the attacker resulting in >>>>>>the >>>>>> master device using channels that are not available at a >>>>>> location or transmitting at a greater power level than >>>>>> allowed >>>>>> resulting in interference to the primary user of that >>>>>> spectrum. Alternatively the attacker may indicate no >>>>>>channel >>>>>> availability at a location resulting in a denial of >>>>>>service >>>>>> to >>>>>> the master device. >>>>>> >>>>>> Threat 5: Using query response information >>>>>> An attacker may be a master device which is not certified >>>>>>for >>>>>> use by the relevant regulatory body. The attacker may >>>>>>listen >>>>>> to >>>>>> the communication between a valid master device and white >>>>>> space >>>>>> database and utilize the information about available >>>>>>channels >>>>>> in the response message by utilizing those channels. The >>>>>> result >>>>>> of such an attack is unauthorized use of channels by a >>>>>>master >>>>>> device which is not certified to operate. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>> >>>> >> >> From brian.rosen@neustar.biz Fri Jan 27 14:21:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 326F021F8671 for ; Fri, 27 Jan 2012 14:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66EqybwFo8AL for ; Fri, 27 Jan 2012 14:21:07 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 83F6921F8674 for ; Fri, 27 Jan 2012 14:21:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1327702902; x=1643062473; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=pnnzNWXofOVXGDPHZ58TM t+4pRdyXe9Vi/z5URR23i4=; b=fI5jxp7z6S2h5RDb26eadFrFhm1IYiIHyD34j mqcdAwtQYR9GsX1Vw811CfXmuW1g2D7MW/Y9hOCpEJnN6lOwQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.4601889; Fri, 27 Jan 2012 17:21:41 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 27 Jan 2012 17:21:02 -0500 From: "Rosen, Brian" To: " " Date: Fri, 27 Jan 2012 17:21:00 -0500 Thread-Topic: [paws] Threat model Thread-Index: AczdQfN/k2KqcFw/Swmdw1p/LREVjw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: uT9DQhO970tF/M22ZxlVtg== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 22:21:09 -0000 I don't think we have a use case that would have such a requirement, but I'= d like to make sure we don't preclude it. Here is a use case: Law Enforcement or other security people on an ad-hoc network. Any communi= cation would provide information useful to an eavesdropper. I don't think we should add that use case, just to get the encryption requi= rement. What we have is a authentication and integrity protection requirem= ent. The solutions we have for those also allow encryption (like TLS/DTLS)= . Brian On Jan 27, 2012, at 5:10 PM, wrote: >=20 > That=B9s fine. If we as a group agree that this is not a threat that we n= eed > to be concerned about, then we do not need a requirement for encryption o= f > the request/response messages. >=20 > -Raj >=20 > On 1/27/12 3:58 PM, "ext Joel M. Halpern" wrote: >=20 >> It looks like we are creating a requirement where there isn't one. >> And if we can avoid mandating encryption, that would seem to make life >> simpler for all concerned. >>=20 >> In fact, for an actual attacker, I think the information from the >> response is almsot useless. After all, their goal is to interfere with >> actual use. The numbers from the response presumably icnlude guard >> regions and safety margins. The attacker is far more likely to be able >> to actually measure activity, observe multiple locations, and decide >> what trouble he wants to cause. None of that requires eavesdropping. >>=20 >> I would really prefer we as a group not invent requirements that do not >> respond to meaningful threats. >> Yours, >> Joel >>=20 >> On 1/27/2012 4:48 PM, Basavaraj.Patil@nokia.com wrote: >>>=20 >>> Resultant harm from an eavesdropper capable of behaving as a master >>> device >>> is causing interference to the primary owner of the spectrum by >>> transmitting at power levels greater than what is authorized for >>> example. >>> Of course a malicious device could do that without necessarily >>> eavesdropping on the link between an authorized/valid master device and >>> database. But the information about available channels and allowed xmit >>> power limits for example can be used to fine-tune the attack. >>>=20 >>> An unauthorized master device may offer service to other devices using >>> the >>> available channel information for example. This is another resultant >>> harm. >>>=20 >>> It is indeed the case that the database is responding to a >>> valid/authorized master device but the response message is being >>> eavesdropped upon and hence IMO it does raise the requirement for >>> avoiding >>> eavesdropping. >>>=20 >>> -Raj >>>=20 >>> On 1/27/12 2:08 PM, "ext Joel M. Halpern" wrote: >>>=20 >>>> can you please elaborate on the resultant harm if a non-authorized use= r >>>> receives a copy of the data? Depending upon what that threat is, I ca= n >>>> imagine a number of additional issues that would need to be elucidates= . >>>>=20 >>>> Note that if this is because the regulations say that the database mus= t >>>> only respond to requests from authorized master, that does not actuall= y >>>> lead to a requirement to prevent eavesdropping. The database is still >>>> only responding to requests from authorized participants. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 1/27/2012 3:01 PM, Basavaraj.Patil@nokia.com wrote: >>>>>=20 >>>>> Joel, >>>>>=20 >>>>> A white space database MUST respond with available channel informatio= n >>>>> only to a certified master device. >>>>> Threat 5 is about master devices which have not been >>>>> approved/certified >>>>> by >>>>> a regulatory body in a specific country. >>>>>=20 >>>>> What threat 5 essentially implies in terms of security requirements i= s >>>>> the >>>>> need for the data to be encrypted. The response message MUST be >>>>> encrypted >>>>> by the white space database so that a MiTM cannot read the data and >>>>> use >>>>> that information. >>>>>=20 >>>>> -Raj >>>>>=20 >>>>> On 1/27/12 1:49 PM, "ext Joel M. Halpern" >>>>> wrote: >>>>>=20 >>>>>> Most of this looks good. >>>>>> The last one does not seem to make sense to me. >>>>>> I presume I am missing something. What follows is why I am confused= , >>>>>> with apologies if I have overlooked something. >>>>>>=20 >>>>>> Given the nature of the system, the number of ways for a >>>>>> non-cooperative >>>>>> client to get the information about what the compliant clients are >>>>>> allowed to do seems myriad. And the number of ways a non-compliant >>>>>> client can mis-behave is also myriad. >>>>>> So I do not actually understand the threat. >>>>>>=20 >>>>>> I can imagine privacy-driven confidentiality with regard to requests= . >>>>>> I >>>>>> hope we don't have to go there, but that would be a threat that I >>>>>> would >>>>>> think was more of an issue than receving a copy of a response. >>>>>>=20 >>>>>> Yours, >>>>>> Joel M. Halpern >>>>>>=20 >>>>>> On 1/27/2012 2:39 PM, Basavaraj.Patil@nokia.com wrote: >>>>>>>=20 >>>>>>> Hello, >>>>>>>=20 >>>>>>> While discussing the requirements we concluded that it would be >>>>>>> useful >>>>>>> to >>>>>>> have a threat model for PAWS. Below is an initial writeup of the >>>>>>> threat >>>>>>> model. This threat model can be included in the Security >>>>>>> considerations >>>>>>> section of the Use-case and Requirements I-D. Security requirements >>>>>>> can >>>>>>> be >>>>>>> derived from this threat model. >>>>>>> Comments welcome. >>>>>>>=20 >>>>>>> -Raj >>>>>>>=20 >>>>>>>=20 >>>>>>> Threat model for the PAWS protocol >>>>>>> ---------------------------------- >>>>>>>=20 >>>>>>> Assumptions: >>>>>>> ............ >>>>>>>=20 >>>>>>> o It is assumed that an attacker has full access to the network >>>>>>> medium >>>>>>> between the master device and the white space database. The >>>>>>> attacker >>>>>>> may be able to eavesdrop on any communications between these >>>>>>> entities. The link between the master device and the white >>>>>>> space >>>>>>> database can be wired or wireless and provides IP connectivity. >>>>>>>=20 >>>>>>> o It is assumed that the master device or the white space database >>>>>>> have NOT been compromised from a security standpoint. >>>>>>>=20 >>>>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>>>> The master device needs to authenticate itself with the >>>>>>> white >>>>>>> space database prior to requesting channel information. >>>>>>> The >>>>>>> attacker may try to get access to the secrets of the >>>>>>> master >>>>>>> device which can be used maliciously. The effect of such >>>>>>> an >>>>>>> attack being successful would result in a malicious client >>>>>>> replaying the stolen authentication/authorization secrets >>>>>>> to >>>>>>> a >>>>>>> white space database. >>>>>>>=20 >>>>>>> Threat 2: Spoofed white space database >>>>>>> A master device discovers a white space database(s) thru >>>>>>> which >>>>>>> it can query for channel information. The master device >>>>>>> needs >>>>>>> to ensure that the white space database with which it >>>>>>> communicates with is an authentic entity. The white space >>>>>>> database needs to provide its identity to the master >>>>>>> device >>>>>>> which can confirm the validity/authenticty of the >>>>>>> database. >>>>>>> An >>>>>>> attacker may attempt to spoof a white space database and >>>>>>> provide responses to a master device which are malicious >>>>>>> and >>>>>>> result in the master device causing interference to the >>>>>>> primary >>>>>>> user of the spectrum. >>>>>>>=20 >>>>>>> Threat 3: Modifying a query request >>>>>>> An attacker may modify the query request sent by a master >>>>>>> device to a white space database. The attacker may change >>>>>>> the >>>>>>> location of the device or the capabilities in terms of its >>>>>>> transmit power or antenna height etc. which could result >>>>>>> in >>>>>>> the >>>>>>> database responding with incorrect information about >>>>>>> available >>>>>>> channels or max transmit power allowed. The result of >>>>>>> such an >>>>>>> attack is that the master device would cause >>>>>>> intereference to >>>>>>> the primary user of the spectrum. It could also result in >>>>>>> a >>>>>>> denial of service to the master device by indicating that >>>>>>> no >>>>>>> channels are available. >>>>>>>=20 >>>>>>> Threat 4: Modifying a query response >>>>>>> An attacker could modify the query response sent by the >>>>>>> white >>>>>>> space database to a master device. The channel >>>>>>> information or >>>>>>> transmit power allowed type of parameters carried in the >>>>>>> response could be modified by the attacker resulting in >>>>>>> the >>>>>>> master device using channels that are not available at a >>>>>>> location or transmitting at a greater power level than >>>>>>> allowed >>>>>>> resulting in interference to the primary user of that >>>>>>> spectrum. Alternatively the attacker may indicate no >>>>>>> channel >>>>>>> availability at a location resulting in a denial of >>>>>>> service >>>>>>> to >>>>>>> the master device. >>>>>>>=20 >>>>>>> Threat 5: Using query response information >>>>>>> An attacker may be a master device which is not certified >>>>>>> for >>>>>>> use by the relevant regulatory body. The attacker may >>>>>>> listen >>>>>>> to >>>>>>> the communication between a valid master device and white >>>>>>> space >>>>>>> database and utilize the information about available >>>>>>> channels >>>>>>> in the response message by utilizing those channels. The >>>>>>> result >>>>>>> of such an attack is unauthorized use of channels by a >>>>>>> master >>>>>>> device which is not certified to operate. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Fri Jan 27 15:30:39 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FCA21F860B for ; Fri, 27 Jan 2012 15:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ram28NaOm+qa for ; Fri, 27 Jan 2012 15:30:39 -0800 (PST) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with ESMTP id E6E2621F85FD for ; Fri, 27 Jan 2012 15:30:38 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTyMzmk43Ok6c9UetBGUM7jE02SHd/9w5@postini.com; Fri, 27 Jan 2012 15:30:39 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 27 Jan 2012 15:24:53 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "paws@ietf.org" Date: Fri, 27 Jan 2012 15:24:52 -0800 Thread-Topic: [paws] Threat model Thread-Index: AQHM3StRJwsi78gZm0WinGjlBlOxJpYgzoXQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 23:30:40 -0000 It's good to have requirements based on such an analysis. This is an inter= esting start, but we may be mixing threats, vulnerabilities and mechanisms. Threats are typically tied to an actor ... human or not. I'm not sure it's= worth going hard over to something like the NIST 800-30 definitions of thr= eats, but within this framework the threats are Governments, disgruntled in= siders, tsunamis etc. Being the IETF we can jump more quickly to the threat= event and specifics of an attack, but should at least expand threats to in= clude natural events and connectivity problems. Robustness or emergency mo= des might be interesting to consider. We also have a problem in this analysis of perspective - are we considering= threats as viewed from regulatory agency or the end device owner or both. = We should consider both - but they are contradictory perspectives. Users = want continuity of service. Governments (the regulators) want control of t= he airwaves. =20 Most of the real threats that we have are nearly impossible to prevent at t= he protocol level. It's still worth examining the threats to see where we = stand. =20 On the current document threats: >o It is assumed that the master device or the white space database > have NOT been compromised from a security standpoint. > >Threat 1: Obtain master device authentication/authorization secrets > The master device needs to authenticate itself with the white > space database prior to requesting channel information. The > attacker may try to get access to the secrets of the master > device which can be used maliciously. The effect of such an > attack being successful would result in a malicious client > replaying the stolen authentication/authorization secrets to a > white space database. This does not seem consistent with the prior statement of "not compromised"= . Restatement Threat: User modifies a device to masquerade as another valid certified dev= ice. This is an interesting case where threat/vulnerability/risk play together. = The FCC or other regulatory agencies want traceability of devices. If a u= ser wants to run a rogue radio, there is no reason to access the database (= low risk - no payoff). The only reason this would be an interesting attack= might be to avoid tracking and have some anonymity. >Threat 2: Spoofed white space database > A master device discovers a white space database(s) thru which > it can query for channel information. The master device needs > to ensure that the white space database with which it > communicates with is an authentic entity. The white space > database needs to provide its identity to the master device > which can confirm the validity/authenticty of the database. An > attacker may attempt to spoof a white space database and > provide responses to a master device which are malicious and > result in the master device causing interference to the primary > user of the spectrum. I think this is two types of threat events: - malicious denial of service or intentional interference with incumbents - impersonation of white space database to enable operation of a device th= at may=20 not otherwise be possible (blocked device, unallocated channels). This = may or may not interfere with incumbent devices >Threat 3: Modifying a query request ... >Threat 4: Modifying a query response Seems like these two could be lumped together ...MiTM modifies protocol mes= sages to: - deny service - interfere with incumbents - provide unauthorized channel usage (most likely risk IMHO) >Threat 5: Using query response information > An attacker may be a master device which is not certified for > use by the relevant regulatory body. The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. The result > of such an attack is unauthorized use of channels by a master > device which is not certified to operate. As stated this is a mechanism - a clearer statement might be. Threat: Unauthorized use of channels by an uncertified device. Anyone can already go to a database and find available channels. If a devi= ce can operate without going to the database there is nothing that paws can= do to stop it operating in available or non-available channels. =20 Just to get some discussion going -here's a couple more possible threats.. Threat: Third party tracking of white space device location Likely a valuable commodity to sell for advertizing with no technical de= sign or policy for privacy Threat: Database owner termination of device service for reasons other than= incumbent protection Paul From scott.probasco@nokia.com Mon Jan 30 06:20:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB95F21F8627 for ; Mon, 30 Jan 2012 06:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.023 X-Spam-Level: X-Spam-Status: No, score=-3.023 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0V43iNJGjCG5 for ; Mon, 30 Jan 2012 06:20:33 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id BB46821F856F for ; Mon, 30 Jan 2012 06:20:32 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UEJYfl030408 for ; Mon, 30 Jan 2012 16:20:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:20:01 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 15:20:00 +0100 From: To: Thread-Topic: Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) Thread-Index: AQHM31pAbg2PbOGfaUaP9HPYMzs/ag== Date: Mon, 30 Jan 2012 14:20:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <08CB047604D86F45B38CD591D440C167@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 14:20:01.0383 (UTC) FILETIME=[40C86F70:01CCDF5A] X-Nokia-AV: Clean Subject: [paws] Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 14:20:37 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for sections 9 and 11. This text has not changed from version-02 as uploaded January 26, 2012. Our goal is that any discussion on this text will conclude by February 6. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 9. Summary and Conclusion Wireless spectrum is a scarce resource. As the demand for spectrum grows, there is a need to more efficiently utilize the available and allocated spectrum. Cognitive radio technologies enable the efficient usage of spectrum via means such as sensing or by querying a database to determine available spectrum at a given location for secondary use. White space is the general term used to refer to the bands within the spectrum which is available for secondary use at a given location. In order to use this spectrum a device needs to query a database which maintains information about the available channels within a band. A protocol is necessary for communication between the devices and databases which would be globally applicable. The document describes some examples of the role of the white space database in the operation of a radio network and also shows an examples of a services provided to the user of a TVWS device. From these use cases requirements are determined. These requirements are to be used as input to the definition of a Protocol to Access White Space database (PAWS). 11. References 11.1. Normative References [80211P] IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements; Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications; Amendment 6: Wireless Access in Vehicular Environments; http:// standards.ieee.org/getieee802/download/802.11p-2010.pdf", July 2010. [FCC47CFR90.210] FCC, "Title 47 Telecommunication CFR Chapter I - Federal Communication Commission Part 90 - Private Land Mobile Radio Services - Section 210 Emission masks; http:// edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ 47cfr90.210.pdf", October 2010. [PAWS-PS] IETF, "Protocol to Access White Space database: Problem statement; https://datatracker.ietf.org/doc/ draft-patil-paws-problem-stmt/", July 2011. [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement Levels; http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", March 1997. 11.2. Informative References [DDR] Ofcom - Independent regulator and competition authority for the UK communications industries, "Digital Dividend Review; http://stakeholders.ofcom.org.uk/spectrum/ project-pages/ddr/". [DTV] "Digital TV Transition; http://www.dtv.gov". [ECC Report 159] Electronic Communications Committee (ECC) within the European Conference of Postal and Telecommunications Administrations (CEPT), "TECHNICAL AND OPERATIONAL REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ ECCREP159.PDF", January 2011. [FCC Ruling] Probasco & Patil Expires July 18, 2012 [Page 32] Internet-Draft PAWS: Problem, uses and requirements January 2012 FCC, "Federal Communications Commission, "Unlicensed Operation in the TV Broadcast Bands; http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", December 2010. [Ofcom Implementing] Ofcom, "Ofcom, "Implementing Geolocation; http:// stakeholders.ofcom.org.uk/consultations/geolocation/ statement/ ?utm_source=3Dupdates&utm_medium=3Demail& utm_campaign=3Dgeolocation-statement"", September 2011. [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Proto col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", August 2008. [Spectrum Framework Review] Ofcom - Independent regulator and competition authority for the UK communications industries, "Spectrum Framework Review; http://stakeholders.ofcom.org.uk/consultations/sfr/", February 2005. [TV Whitespace Tutorial Intro] IEEE 802 Executive Committee Study Group on TV White Spaces, "TV Whitespace Tutorial Intro; http:// grouper.ieee.org/groups/802/802_tutorials/2009-03/ 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", March 2009. From gerald.chouinard@crc.ca Mon Jan 30 07:27:05 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7207C21F8693 for ; Mon, 30 Jan 2012 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wV1+o+Rlqjka for ; Mon, 30 Jan 2012 07:27:04 -0800 (PST) Received: from mailgw01.crc.ca (mailgw01.crc.ca [142.92.160.200]) by ietfa.amsl.com (Postfix) with SMTP id 175F221F867F for ; Mon, 30 Jan 2012 07:27:04 -0800 (PST) Received: from scanner.crc.ca (scanner.crc.ca [142.92.60.102]) by mailgw01.crc.ca (Postfix) with SMTP id ADA656B0474; Mon, 30 Jan 2012 10:27:01 -0500 (EST) Received: from scanner.crc.ca (localhost.localdomain [127.0.0.1]) by scanner.crc.ca (Postfix) with ESMTP id 936916B03B8; Mon, 30 Jan 2012 10:27:01 -0500 (EST) Received: by scanner.crc.ca (Postfix, from userid 501) id 86A036B03ED; Mon, 30 Jan 2012 10:27:01 -0500 (EST) Received: from mailhub.crc.ca (mail.crc.ca [142.92.60.201]) by scanner.crc.ca (Postfix) with ESMTP id B9DC96B03B8; Mon, 30 Jan 2012 10:26:58 -0500 (EST) Received: from localhost (extweb2.pub.crc.ca [142.92.160.17]) by mailhub.crc.ca (Postfix) with ESMTP id B28AB6B1F61; Mon, 30 Jan 2012 10:26:58 -0500 (EST) Received: from bas4-hull20-2925524780.dsl.bell.ca (bas4-hull20-2925524780.dsl.bell.ca [174.95.247.44]) by www.crc.gc.ca (Horde Framework) with HTTP; Mon, 30 Jan 2012 10:26:58 -0500 Message-ID: <20120130102658.134459ih08asyv9e@www.crc.gc.ca> Date: Mon, 30 Jan 2012 10:26:58 -0500 From: gerald.chouinard@crc.ca To: scott.probasco@nokia.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3) X-Virus-Scanned: ClamAV using ClamSMTP Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 15:27:05 -0000 Hi Scott, all, Here are some suggested changes to the text: - 7th line of section 9: change "secondary" for "opportunistic". In =20 the ITU-R Table of frequency allotment, there are bands where primary =20 and secondary services already exist. White Space opportunistic use =20 would then become some sort of tertiary service usage. - Penultimate sentence of section 9: add a coma as follows: "From =20 these use cases, requirements are determined." - Section 11, first reference: (802.11p) ... - Section 11, add a new second reference: (802.22) IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Wireless Regional Area Networks (WRAN) - Specific requirements; Part 22: Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Polici= es and Procedures for Operation in the TV bands; http:// standards.ieee.org/getieee802/download/802.22-2011.pdf", July 2011. Regards, Gerald Quoting scott.probasco@nokia.com: > Hello All, > > As editors of the problem statement, use cases & requirements draft we are > attempting to prepare a completed draft which could be ready for working > group last call before IETF83. In the coming days we will post the > sections of the draft to the mailing list. Our request is that you review > these sections and reply to the email with any comments. > > Below is the text for sections 9 and 11. This text has not changed from > version-02 as uploaded January 26, 2012. Our goal is that any discussion > on this text will conclude by February 6. To be clear, approval of the > document will go through the normal process of last calls etc.. We are > simply asking for your assistance in preparing a complete & accurate > document that could progress the work. So please review the text and send > your comments either directly to the editor or to the mailing list. > > Kind Regards, > Raj & Scott > > > > 9. Summary and Conclusion > > Wireless spectrum is a scarce resource. As the demand for spectrum > grows, there is a need to more efficiently utilize the available and > allocated spectrum. Cognitive radio technologies enable the > efficient usage of spectrum via means such as sensing or by querying > a database to determine available spectrum at a given location for > secondary use. White space is the general term used to refer to the > bands within the spectrum which is available for secondary use at a > given location. In order to use this spectrum a device needs to > query a database which maintains information about the available > channels within a band. A protocol is necessary for communication > between the devices and databases which would be globally applicable. > > The document describes some examples of the role of the white space > database in the operation of a radio network and also shows an > examples of a services provided to the user of a TVWS device. From > these use cases requirements are determined. These requirements are > to be used as input to the definition of a Protocol to Access White > Space database (PAWS). > > > > 11. References > > 11.1. Normative References > > [80211P] IEEE, "IEEE Standard for Information technology - > Telecommunications and information exchange between > systems - Local and metropolitan area networks - Specific > requirements; Part 11: Wireless LAN Medium Access Control > (MAC) and Physical Layer (PHY) Specifications; Amendment > 6: Wireless Access in Vehicular Environments; http:// > standards.ieee.org/getieee802/download/802.11p-2010.pdf", > July 2010. > > [FCC47CFR90.210] > FCC, "Title 47 Telecommunication CFR Chapter I - Federal > Communication Commission Part 90 - Private Land Mobile > Radio Services - Section 210 Emission masks; http:// > edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ > 47cfr90.210.pdf", October 2010. > > [PAWS-PS] IETF, "Protocol to Access White Space database: Problem > statement; https://datatracker.ietf.org/doc/ > draft-patil-paws-problem-stmt/", July 2011. > > [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement > Levels; > http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", > March 1997. > > 11.2. Informative References > > [DDR] Ofcom - Independent regulator and competition authority > for the UK communications industries, "Digital Dividend > Review; http://stakeholders.ofcom.org.uk/spectrum/ > project-pages/ddr/". > > [DTV] "Digital TV Transition; http://www.dtv.gov". > > [ECC Report 159] > Electronic Communications Committee (ECC) within the > European Conference of Postal and Telecommunications > Administrations (CEPT), "TECHNICAL AND OPERATIONAL > REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO > SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- > 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ > ECCREP159.PDF", January 2011. > > [FCC Ruling] > > > > Probasco & Patil Expires July 18, 2012 [Page 32] > > Internet-Draft PAWS: Problem, uses and requirements January 2012 > > > FCC, "Federal Communications Commission, "Unlicensed > Operation in the TV Broadcast Bands; > http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", > December 2010. > > [Ofcom Implementing] > Ofcom, "Ofcom, "Implementing Geolocation; http:// > stakeholders.ofcom.org.uk/consultations/geolocation/ > statement/ > ?utm_source=3Dupdates&utm_medium=3Demail& > utm_campaign=3Dgeolocation-statement"", September 2011. > > [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. > Tschofenig, "LoST: A Location-to-Service Translation Proto > col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", > August 2008. > > [Spectrum Framework Review] > Ofcom - Independent regulator and competition authority > for the UK communications industries, "Spectrum Framework > Review; > http://stakeholders.ofcom.org.uk/consultations/sfr/", > February 2005. > > [TV Whitespace Tutorial Intro] > IEEE 802 Executive Committee Study Group on TV White > Spaces, "TV Whitespace Tutorial Intro; http:// > grouper.ieee.org/groups/802/802_tutorials/2009-03/ > 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", > March 2009. > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From andy.sago@bt.com Mon Jan 30 08:55:29 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9511E8074 for ; Mon, 30 Jan 2012 08:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu0kQQEngncd for ; Mon, 30 Jan 2012 08:55:28 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4929C11E8071 for ; Mon, 30 Jan 2012 08:55:28 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 16:55:27 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 30 Jan 2012 16:55:27 +0000 From: To: Date: Mon, 30 Jan 2012 16:55:24 +0000 Thread-Topic: [paws] Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) Thread-Index: AczfY6EokL60BqT/SMaiyCb3D3INhAAB+j/w Message-ID: <619CDADDCCD2B44380834BE8BF6F71414065033161@EMV62-UKRD.domain1.systemhost.net> References: <20120130102658.134459ih08asyv9e@www.crc.gc.ca> In-Reply-To: <20120130102658.134459ih08asyv9e@www.crc.gc.ca> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:55:29 -0000 Scott Agreed these are good changes. Also, last paragraph of the conclusion, "...= and also shows an examples of a services provided ....", delete both "an" = and "a". In the references, there is a shorter link to [Ofcom Implementing]= : http://stakeholders.ofcom.org.uk/consultations/geolocation/statement/ =20 Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ger= ald.chouinard@crc.ca Sent: 30 January 2012 15:27 To: scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements: sections 9 and 11 (Summary = and Conclusion, References) Hi Scott, all, Here are some suggested changes to the text: - 7th line of section 9: change "secondary" for "opportunistic". In the ITU= -R Table of frequency allotment, there are bands where primary and secondar= y services already exist. White Space opportunistic use would then become s= ome sort of tertiary service usage. - Penultimate sentence of section 9: add a coma as follows: "From these use= cases, requirements are determined." - Section 11, first reference: (802.11p) ... - Section 11, add a new second reference: (802.22) IEEE, "IEEE Standard for Information technology - Telecommunications and information exchange between systems - Wireless Regional Area Networks (WRAN) - Specific requirements; Part 22: Cognitive Wireless RAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Polic= ies and Procedures for Operation in the TV bands; http:// standards.ieee.org/getieee802/download/802.22-2011.pdf", July 2011. Regards, Gerald Quoting scott.probasco@nokia.com: > Hello All, > > As editors of the problem statement, use cases & requirements draft we=20 > are attempting to prepare a completed draft which could be ready for=20 > working group last call before IETF83. In the coming days we will post=20 > the sections of the draft to the mailing list. Our request is that you=20 > review these sections and reply to the email with any comments. > > Below is the text for sections 9 and 11. This text has not changed=20 > from > version-02 as uploaded January 26, 2012. Our goal is that any=20 > discussion on this text will conclude by February 6. To be clear,=20 > approval of the document will go through the normal process of last=20 > calls etc.. We are simply asking for your assistance in preparing a=20 > complete & accurate document that could progress the work. So please=20 > review the text and send your comments either directly to the editor or t= o the mailing list. > > Kind Regards, > Raj & Scott > > > > 9. Summary and Conclusion > > Wireless spectrum is a scarce resource. As the demand for spectrum > grows, there is a need to more efficiently utilize the available and > allocated spectrum. Cognitive radio technologies enable the > efficient usage of spectrum via means such as sensing or by querying > a database to determine available spectrum at a given location for > secondary use. White space is the general term used to refer to the > bands within the spectrum which is available for secondary use at a > given location. In order to use this spectrum a device needs to > query a database which maintains information about the available > channels within a band. A protocol is necessary for communication > between the devices and databases which would be globally applicable. > > The document describes some examples of the role of the white space > database in the operation of a radio network and also shows an > examples of a services provided to the user of a TVWS device. From > these use cases requirements are determined. These requirements are > to be used as input to the definition of a Protocol to Access White > Space database (PAWS). > > > > 11. References > > 11.1. Normative References > > [80211P] IEEE, "IEEE Standard for Information technology - > Telecommunications and information exchange between > systems - Local and metropolitan area networks - Specific > requirements; Part 11: Wireless LAN Medium Access Control > (MAC) and Physical Layer (PHY) Specifications; Amendment > 6: Wireless Access in Vehicular Environments; http:// > standards.ieee.org/getieee802/download/802.11p-2010.pdf", > July 2010. > > [FCC47CFR90.210] > FCC, "Title 47 Telecommunication CFR Chapter I - Federal > Communication Commission Part 90 - Private Land Mobile > Radio Services - Section 210 Emission masks; http:// > edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ > 47cfr90.210.pdf", October 2010. > > [PAWS-PS] IETF, "Protocol to Access White Space database: Problem > statement; https://datatracker.ietf.org/doc/ > draft-patil-paws-problem-stmt/", July 2011. > > [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement > Levels; > http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", > March 1997. > > 11.2. Informative References > > [DDR] Ofcom - Independent regulator and competition authority > for the UK communications industries, "Digital Dividend > Review; http://stakeholders.ofcom.org.uk/spectrum/ > project-pages/ddr/". > > [DTV] "Digital TV Transition; http://www.dtv.gov". > > [ECC Report 159] > Electronic Communications Committee (ECC) within the > European Conference of Postal and Telecommunications > Administrations (CEPT), "TECHNICAL AND OPERATIONAL > REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO > SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- > 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ > ECCREP159.PDF", January 2011. > > [FCC Ruling] > > > > Probasco & Patil Expires July 18, 2012 [Page 32] > > Internet-Draft PAWS: Problem, uses and requirements January 2012 > > > FCC, "Federal Communications Commission, "Unlicensed > Operation in the TV Broadcast Bands; > http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", > December 2010. > > [Ofcom Implementing] > Ofcom, "Ofcom, "Implementing Geolocation; http:// > stakeholders.ofcom.org.uk/consultations/geolocation/ > statement/ > ?utm_source=3Dupdates&utm_medium=3Demail& > utm_campaign=3Dgeolocation-statement"", September 2011. > > [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. > Tschofenig, "LoST: A Location-to-Service Translation Proto > col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", > August 2008. > > [Spectrum Framework Review] > Ofcom - Independent regulator and competition authority > for the UK communications industries, "Spectrum Framework > Review; > http://stakeholders.ofcom.org.uk/consultations/sfr/", > February 2005. > > [TV Whitespace Tutorial Intro] > IEEE 802 Executive Committee Study Group on TV White > Spaces, "TV Whitespace Tutorial Intro; http:// > grouper.ieee.org/groups/802/802_tutorials/2009-03/ > 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", > March 2009. > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Mon Jan 30 08:55:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4F411E8091 for ; Mon, 30 Jan 2012 08:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViqlxgpYCWyv for ; Mon, 30 Jan 2012 08:55:35 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 3C69511E8089 for ; Mon, 30 Jan 2012 08:55:35 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 16:55:34 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Mon, 30 Jan 2012 16:55:34 +0000 From: To: , Date: Mon, 30 Jan 2012 16:55:31 +0000 Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM26LJph+Yc0pEHUy0sgx3BmU5sJYlIt5w Message-ID: <619CDADDCCD2B44380834BE8BF6F71414065033163@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 16:55:37 -0000 Scott [Ofcom Implementing] appears in the references section but not the main tex= t. I propose to reference it from the end of one sentence in the second par= agraph, and slightly amend the wording. The changed text would be: Ofcom published in 2004 their Spectrum Framework Review [Spectrum Framework= Review] and their Digital Dividend Review [DDR] in 2005, with proposals fr= om 2009 onwards to access TV white space, culminating in the 2009 Ofcom Sta= tement Implementing Geolocation [Ofcom Implementing]. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 25 January 2012 20:49 To: paws@ietf.org Subject: [paws] Use cases and requirements I-D: sections 1 to 3 (Introducti= on, Conventions and Terminology, Prior Work) Hello All, As editors of the problem statement, use cases & requirements draft we are = attempting to prepare a completed draft which could be ready for working gr= oup last call before IETF83. In the coming days we will post the sections o= f the draft to the mailing list. Our request is that you review these secti= ons and reply to the email with any comments. Below is the text for sections 1 to 3. This text has not changed from version-01 as uploaded October 31, 2011. Our goal is that any discussion on= this text will conclude by February 1. To be clear, approval of the docume= nt will go through the normal process of last calls etc.. We are simply ask= ing for your assistance in preparing a complete & accurate document that co= uld progress the work. So please review the text and send your comments eit= her directly to the editor or to the mailing list. Kind Regards, Raj & Scott 1. Introduction 1.1. Introduction to TV white space Wireless spectrum is a commodity that is regulated by governments. The spectrum is used for various purposes, which include entertainment (e.g. radio and television), communication (telephony and Internet access), military (radars etc.) and, navigation (satellite communication, GPS). Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. One interesting observation is that often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. Academia and Industry have studied multiple cognitive radio mechanisms for use in such a scenario. One simple mechanism is to use a geospatial database that records the primary users occupation, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by secondary users. Spectrum useable for data communications, especially wireless Internet communications, is scarce. One area which has received much attention globally is the TV white space: portions of the TV band that are not used by broadcasters in a given area. In 2008 the United States regulator (the FCC) took initial steps when they published their first ruling on the use of TV white space, and then followed it up with a final ruling in 2010 [FCC Ruling]. Finland passed an Act in 2009 enabling testing of cognitive radio systems in the TV white space. The ECC has completed Report 159 [ECC Report 159] containing requirements for operation of cognitive radio systems in the TV white space. Ofcom published in 2004 their Spectrum Framework Review [Spectrum Framework Review] and their Digital Dividend Review [DDR] in 2005, and have followed up with a proposal to access TV white space. More countries are expected to provide access to their TV spectrum in similar ways. Any entity holding spectrum that is not densely used may be asked to give it up in one way or another for more intensive use. Providing a mechanism by which secondary users share the spectrum with the primary user is attractive in many bands in many countries. Probasco & Patil Expires July 18, 2012 [Page 4] Internet-Draft PAWS: Problem, uses and requirements January 2012 Television transmission until now has primarily been analog. The switch to digital transmission has begun. As a result the spectrum allocated for television transmission can now be more effectively used. Unused channels and bands between channels can be used as long as they do not interfere with the primary service for which that channel is allocated. While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi-urban areas. There can be a number of unused TV channels in such areas that can be used for other services. The figure below shows TV white space within the lower UHF band: Avg | usage| |-------------- White Space | | | | | | 0.6| || || V V || | || ||| | || 0.4| || |||| | || | || |||| | ||<----TV transmission 0.2| || |||| | || |---------------------------------------- 400 500 600 700 800 Frequency in MHz -> Figure 1: High level view of TV White Space The fundamental issue is how to determine for a specific location and specific time if any of the spectrum is available for secondary use. There are two dimensions of use that may be interesting: space (the area in which a secondary user would not interfere with a primary user, and time: when the secondary use would not interfere with the primary use. In this discussion, we consider the time element to be relatively long term (hours in a day) rather than short term (fractions of a second). Location in this discussion is geolocation: where the transmitters (and sometimes receivers) are located relative to one another. In operation, the database records the existing user's transmitter (and some times receiver) locations along with basic transmission characteristics such as antenna height, and sometimes power. Using rules established by the regulator, the database calculates an exclusion zone for each authorized primary user, and attaches a time schedule to that use. The secondary user queries the database with its location. The database intersects the exclusion zones with the queried location, and returns the portion of the spectrum not in any exclusion zone. Such methods of geospatial database query to avoid interference have been shown to achieve favorable results, and are thus the basis for rulings by the FCC and Probasco & Patil Expires July 18, 2012 [Page 5] Internet-Draft PAWS: Problem, uses and requirements January 2012 reports from ECC and Ofcom. In any country, the rules for which primary entities are entitled to protection, how the exclusion zones are calculated, and what the limits of use by secondary entities are may vary. However, the fundamental notion of recording primary users, calculating exclusion zones, querying by location and returning available spectrum (and the schedule for that spectrum) are common This document includes the problem statement, use cases and requirements associated with the use of white space spectrum by secondary users via a database query protocol. 1.2. Scope 1.2.1. In Scope This document applies only to communications required for basic service in TV white space. The protocol will enable a white space radio device to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Register with the database using a well-defined protocol. 4. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 5. Receive in return a list of currently available white space using a well-defined format for returning information. As a result, some of the scenarios described in the following section are out of scope for this specification (although they might be addressed by future specifications). 1.2.2. Out of Scope The following topics are out of scope for this specification: TBD 2. Conventions and Terminology Probasco & Patil Expires July 18, 2012 [Page 6] Internet-Draft PAWS: Problem, uses and requirements January 2012 2.1. Conventions Used in This Document 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]. 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A primary user of white space spectrum which is afforded protection against interference by secondary users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. Probasco & Patil Expires July 18, 2012 [Page 7] Internet-Draft PAWS: Problem, uses and requirements January 2012 TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use, but is not fully occupied by that primary use at a specific location and time. White Space Device (WSD) A device which is a secondary user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. 3. Prior Work 3.1. The concept of Cognitive Radio A cognitive radio uses knowledge of the local radio environment to dynamically adapt its own configuration and function properly in a changing radio environment. Knowledge of the local radio environment can come from various technology mechanisms including sensing (attempting to ascertain primary users by listening for them within the spectrum), location determination and internet connectivity to a database to learn the details of the local radio environment. TV White Space is one implementation of cognitive radio. Because a cognitive radio adapts itself to the available spectrum in a manner that prevents the creation of harmful interference, the spectrum can be shared among different radio users. 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all full- power U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 18, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Air Interfaces Efforts are ongoing to specify air-interfaces for use in white space spectrum. IEEEs 802.11af task group is currently working on one such specification. IEEE 802.22 is another example. Other air interfaces could be specified in the future such as LTE. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Mon Jan 30 09:54:28 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2E811E8089 for ; Mon, 30 Jan 2012 09:54:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.784 X-Spam-Level: X-Spam-Status: No, score=-101.784 tagged_above=-999 required=5 tests=[AWL=-0.938, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+cU8onxVyMs for ; Mon, 30 Jan 2012 09:54:27 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 209C811E8081 for ; Mon, 30 Jan 2012 09:54:26 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UHs5HD004147; Mon, 30 Jan 2012 19:54:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 19:54:16 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 18:54:16 +0100 From: To: Thread-Topic: [paws] Threat model Thread-Index: AQHM3SzX7z1G5jgDO0GoIcs3y0bfS5YgLSUAgABmgoD//7eMAIAAZ0OA//+e8ICAAGdiAIAEB+4A Date: Mon, 30 Jan 2012 17:54:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.33] Content-Type: text/plain; charset="euc-kr" Content-ID: <0C9A37C3C2543B4EAC59A5E4A68EC661@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 17:54:16.0946 (UTC) FILETIME=[2F4BAD20:01CCDF78] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:54:28 -0000 DQpIaSBCcmlhbiwNCg0KSSBkb26hr3Qga25vdyBpZiB0aGVyZSBhcmUgYW55IHJlcXVpcmVtZW50 cyBmcm9tIGEgbGF3LWVuZm9yY2VtZW50DQpwZXJzcGVjdGl2ZSBpbiB0aGUgRkNDIHJlY29tbWVu ZGF0aW9ucyBvciBPZmNvbSBjb25zdWx0YXRpb25zLiBTbyB3aGlsZQ0KdGhlIGxhdy1lbmZvcmNl bWVudCB1c2UtY2FzZSBpcyBnb29kLCBJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBpbmNsdWRl DQppdCBpbiB0aGUgSS1EIHlldCBhcyBhbm90aGVyIHVzZSBjYXNlIGluIHRoZSBzZXQuDQoNCi1S YWoNCg0KT24gMS8yNy8xMiA0OjIxIFBNLCAiZXh0IFJvc2VuLCBCcmlhbiIgPEJyaWFuLlJvc2Vu QG5ldXN0YXIuYml6PiB3cm90ZToNCg0KPkkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhIHVzZSBjYXNl IHRoYXQgd291bGQgaGF2ZSBzdWNoIGEgcmVxdWlyZW1lbnQsIGJ1dA0KPkknZCBsaWtlIHRvIG1h a2Ugc3VyZSB3ZSBkb24ndCBwcmVjbHVkZSBpdC4NCj4NCj5IZXJlIGlzIGEgdXNlIGNhc2U6DQo+ DQo+TGF3IEVuZm9yY2VtZW50IG9yIG90aGVyIHNlY3VyaXR5IHBlb3BsZSBvbiBhbiBhZC1ob2Mg bmV0d29yay4gIEFueQ0KPmNvbW11bmljYXRpb24gd291bGQgcHJvdmlkZSBpbmZvcm1hdGlvbiB1 c2VmdWwgdG8gYW4gZWF2ZXNkcm9wcGVyLg0KPg0KPkkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGFk ZCB0aGF0IHVzZSBjYXNlLCBqdXN0IHRvIGdldCB0aGUgZW5jcnlwdGlvbg0KPnJlcXVpcmVtZW50 LiAgV2hhdCB3ZSBoYXZlIGlzIGEgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBwcm90ZWN0 aW9uDQo+cmVxdWlyZW1lbnQuICBUaGUgc29sdXRpb25zIHdlIGhhdmUgZm9yIHRob3NlIGFsc28g YWxsb3cgZW5jcnlwdGlvbiAobGlrZQ0KPlRMUy9EVExTKS4NCj4NCj5Ccmlhbg0KPg0KPk9uIEph biAyNywgMjAxMiwgYXQgNToxMCBQTSwgPEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20+DQo+PEJh c2F2YXJhai5QYXRpbEBub2tpYS5jb20+IHdyb3RlOg0KPg0KPj4gDQo+PiBUaGF0qfZzIGZpbmUu IElmIHdlIGFzIGEgZ3JvdXAgYWdyZWUgdGhhdCB0aGlzIGlzIG5vdCBhIHRocmVhdCB0aGF0IHdl DQo+Pm5lZWQNCj4+IHRvIGJlIGNvbmNlcm5lZCBhYm91dCwgdGhlbiB3ZSBkbyBub3QgbmVlZCBh IHJlcXVpcmVtZW50IGZvciBlbmNyeXB0aW9uDQo+Pm9mDQo+PiB0aGUgcmVxdWVzdC9yZXNwb25z ZSBtZXNzYWdlcy4NCj4+IA0KPj4gLVJhag0KPj4gDQo+PiBPbiAxLzI3LzEyIDM6NTggUE0sICJl eHQgSm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+PiANCj4+ PiBJdCBsb29rcyBsaWtlIHdlIGFyZSBjcmVhdGluZyBhIHJlcXVpcmVtZW50IHdoZXJlIHRoZXJl IGlzbid0IG9uZS4NCj4+PiBBbmQgaWYgd2UgY2FuIGF2b2lkIG1hbmRhdGluZyBlbmNyeXB0aW9u LCB0aGF0IHdvdWxkIHNlZW0gdG8gbWFrZSBsaWZlDQo+Pj4gc2ltcGxlciBmb3IgYWxsIGNvbmNl cm5lZC4NCj4+PiANCj4+PiBJbiBmYWN0LCBmb3IgYW4gYWN0dWFsIGF0dGFja2VyLCBJIHRoaW5r IHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZQ0KPj4+IHJlc3BvbnNlIGlzIGFsbXNvdCB1c2VsZXNz LiAgQWZ0ZXIgYWxsLCB0aGVpciBnb2FsIGlzIHRvIGludGVyZmVyZSB3aXRoDQo+Pj4gYWN0dWFs IHVzZS4gIFRoZSBudW1iZXJzIGZyb20gdGhlIHJlc3BvbnNlIHByZXN1bWFibHkgaWNubHVkZSBn dWFyZA0KPj4+IHJlZ2lvbnMgYW5kIHNhZmV0eSBtYXJnaW5zLiAgVGhlIGF0dGFja2VyIGlzIGZh ciBtb3JlIGxpa2VseSB0byBiZSBhYmxlDQo+Pj4gdG8gYWN0dWFsbHkgbWVhc3VyZSBhY3Rpdml0 eSwgb2JzZXJ2ZSBtdWx0aXBsZSBsb2NhdGlvbnMsIGFuZCBkZWNpZGUNCj4+PiB3aGF0IHRyb3Vi bGUgaGUgd2FudHMgdG8gY2F1c2UuICBOb25lIG9mIHRoYXQgcmVxdWlyZXMgZWF2ZXNkcm9wcGlu Zy4NCj4+PiANCj4+PiBJIHdvdWxkIHJlYWxseSBwcmVmZXIgd2UgYXMgYSBncm91cCBub3QgaW52 ZW50IHJlcXVpcmVtZW50cyB0aGF0IGRvIG5vdA0KPj4+IHJlc3BvbmQgdG8gbWVhbmluZ2Z1bCB0 aHJlYXRzLg0KPj4+IFlvdXJzLA0KPj4+IEpvZWwNCj4+PiANCj4+PiBPbiAxLzI3LzIwMTIgNDo0 OCBQTSwgQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSB3cm90ZToNCj4+Pj4gDQo+Pj4+IFJlc3Vs dGFudCBoYXJtIGZyb20gYW4gZWF2ZXNkcm9wcGVyIGNhcGFibGUgb2YgYmVoYXZpbmcgYXMgYSBt YXN0ZXINCj4+Pj4gZGV2aWNlDQo+Pj4+IGlzIGNhdXNpbmcgaW50ZXJmZXJlbmNlIHRvIHRoZSBw cmltYXJ5IG93bmVyIG9mIHRoZSBzcGVjdHJ1bSBieQ0KPj4+PiB0cmFuc21pdHRpbmcgYXQgcG93 ZXIgbGV2ZWxzIGdyZWF0ZXIgdGhhbiB3aGF0IGlzIGF1dGhvcml6ZWQgZm9yDQo+Pj4+IGV4YW1w bGUuDQo+Pj4+IE9mIGNvdXJzZSBhIG1hbGljaW91cyBkZXZpY2UgY291bGQgZG8gdGhhdCB3aXRo b3V0IG5lY2Vzc2FyaWx5DQo+Pj4+IGVhdmVzZHJvcHBpbmcgb24gdGhlIGxpbmsgYmV0d2VlbiBh biBhdXRob3JpemVkL3ZhbGlkIG1hc3RlciBkZXZpY2UNCj4+Pj5hbmQNCj4+Pj4gZGF0YWJhc2Uu IEJ1dCB0aGUgaW5mb3JtYXRpb24gYWJvdXQgYXZhaWxhYmxlIGNoYW5uZWxzIGFuZCBhbGxvd2Vk DQo+Pj4+eG1pdA0KPj4+PiBwb3dlciBsaW1pdHMgZm9yIGV4YW1wbGUgY2FuIGJlIHVzZWQgdG8g ZmluZS10dW5lIHRoZSBhdHRhY2suDQo+Pj4+IA0KPj4+PiBBbiB1bmF1dGhvcml6ZWQgbWFzdGVy IGRldmljZSBtYXkgb2ZmZXIgc2VydmljZSB0byBvdGhlciBkZXZpY2VzIHVzaW5nDQo+Pj4+IHRo ZQ0KPj4+PiBhdmFpbGFibGUgY2hhbm5lbCBpbmZvcm1hdGlvbiBmb3IgZXhhbXBsZS4gVGhpcyBp cyBhbm90aGVyIHJlc3VsdGFudA0KPj4+PiBoYXJtLg0KPj4+PiANCj4+Pj4gSXQgaXMgaW5kZWVk IHRoZSBjYXNlIHRoYXQgdGhlIGRhdGFiYXNlIGlzIHJlc3BvbmRpbmcgdG8gYQ0KPj4+PiB2YWxp ZC9hdXRob3JpemVkIG1hc3RlciBkZXZpY2UgYnV0IHRoZSByZXNwb25zZSBtZXNzYWdlIGlzIGJl aW5nDQo+Pj4+IGVhdmVzZHJvcHBlZCB1cG9uIGFuZCBoZW5jZSBJTU8gaXQgZG9lcyByYWlzZSB0 aGUgcmVxdWlyZW1lbnQgZm9yDQo+Pj4+IGF2b2lkaW5nDQo+Pj4+IGVhdmVzZHJvcHBpbmcuDQo+ Pj4+IA0KPj4+PiAtUmFqDQo+Pj4+IA0KPj4+PiBPbiAxLzI3LzEyIDI6MDggUE0sICJleHQgSm9l bCBNLiBIYWxwZXJuIjxqbWhAam9lbGhhbHBlcm4uY29tPiAgd3JvdGU6DQo+Pj4+IA0KPj4+Pj4g Y2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlIG9uIHRoZSByZXN1bHRhbnQgaGFybSBpZiBhIG5vbi1h dXRob3JpemVkDQo+Pj4+PnVzZXINCj4+Pj4+IHJlY2VpdmVzIGEgY29weSBvZiB0aGUgZGF0YT8g IERlcGVuZGluZyB1cG9uIHdoYXQgdGhhdCB0aHJlYXQgaXMsIEkNCj4+Pj4+Y2FuDQo+Pj4+PiBp bWFnaW5lIGEgbnVtYmVyIG9mIGFkZGl0aW9uYWwgaXNzdWVzIHRoYXQgd291bGQgbmVlZCB0byBi ZQ0KPj4+Pj5lbHVjaWRhdGVzLg0KPj4+Pj4gDQo+Pj4+PiBOb3RlIHRoYXQgaWYgdGhpcyBpcyBi ZWNhdXNlIHRoZSByZWd1bGF0aW9ucyBzYXkgdGhhdCB0aGUgZGF0YWJhc2UNCj4+Pj4+bXVzdA0K Pj4+Pj4gb25seSByZXNwb25kIHRvIHJlcXVlc3RzIGZyb20gYXV0aG9yaXplZCBtYXN0ZXIsIHRo YXQgZG9lcyBub3QNCj4+Pj4+YWN0dWFsbHkNCj4+Pj4+IGxlYWQgdG8gYSByZXF1aXJlbWVudCB0 byBwcmV2ZW50IGVhdmVzZHJvcHBpbmcuICBUaGUgZGF0YWJhc2UgaXMNCj4+Pj4+c3RpbGwNCj4+ Pj4+IG9ubHkgcmVzcG9uZGluZyB0byByZXF1ZXN0cyBmcm9tIGF1dGhvcml6ZWQgcGFydGljaXBh bnRzLg0KPj4+Pj4gDQo+Pj4+PiBZb3VycywNCj4+Pj4+IEpvZWwNCj4+Pj4+IA0KPj4+Pj4gT24g MS8yNy8yMDEyIDM6MDEgUE0sIEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20gd3JvdGU6DQo+Pj4+ Pj4gDQo+Pj4+Pj4gSm9lbCwNCj4+Pj4+PiANCj4+Pj4+PiBBIHdoaXRlIHNwYWNlIGRhdGFiYXNl IE1VU1QgcmVzcG9uZCB3aXRoIGF2YWlsYWJsZSBjaGFubmVsDQo+Pj4+Pj5pbmZvcm1hdGlvbg0K Pj4+Pj4+IG9ubHkgdG8gYSBjZXJ0aWZpZWQgbWFzdGVyIGRldmljZS4NCj4+Pj4+PiBUaHJlYXQg NSBpcyBhYm91dCBtYXN0ZXIgZGV2aWNlcyB3aGljaCBoYXZlIG5vdCBiZWVuDQo+Pj4+Pj4gYXBw cm92ZWQvY2VydGlmaWVkDQo+Pj4+Pj4gYnkNCj4+Pj4+PiBhIHJlZ3VsYXRvcnkgYm9keSBpbiBh IHNwZWNpZmljIGNvdW50cnkuDQo+Pj4+Pj4gDQo+Pj4+Pj4gV2hhdCB0aHJlYXQgNSBlc3NlbnRp YWxseSBpbXBsaWVzIGluIHRlcm1zIG9mIHNlY3VyaXR5IHJlcXVpcmVtZW50cw0KPj4+Pj4+aXMN Cj4+Pj4+PiB0aGUNCj4+Pj4+PiBuZWVkIGZvciB0aGUgZGF0YSB0byBiZSBlbmNyeXB0ZWQuIFRo ZSByZXNwb25zZSBtZXNzYWdlIE1VU1QgYmUNCj4+Pj4+PiBlbmNyeXB0ZWQNCj4+Pj4+PiBieSB0 aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2Ugc28gdGhhdCBhIE1pVE0gY2Fubm90IHJlYWQgdGhlIGRh dGEgYW5kDQo+Pj4+Pj4gdXNlDQo+Pj4+Pj4gdGhhdCBpbmZvcm1hdGlvbi4NCj4+Pj4+PiANCj4+ Pj4+PiAtUmFqDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gMS8yNy8xMiAxOjQ5IFBNLCAiZXh0IEpvZWwg TS4gSGFscGVybiI8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+PiAN Cj4+Pj4+Pj4gTW9zdCBvZiB0aGlzIGxvb2tzIGdvb2QuDQo+Pj4+Pj4+IFRoZSBsYXN0IG9uZSBk b2VzIG5vdCBzZWVtIHRvIG1ha2Ugc2Vuc2UgdG8gbWUuDQo+Pj4+Pj4+IEkgcHJlc3VtZSBJIGFt IG1pc3Npbmcgc29tZXRoaW5nLiAgV2hhdCBmb2xsb3dzIGlzIHdoeSBJIGFtDQo+Pj4+Pj4+Y29u ZnVzZWQsDQo+Pj4+Pj4+IHdpdGggYXBvbG9naWVzIGlmIEkgaGF2ZSBvdmVybG9va2VkIHNvbWV0 aGluZy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEdpdmVuIHRoZSBuYXR1cmUgb2YgdGhlIHN5c3RlbSwg dGhlIG51bWJlciBvZiB3YXlzIGZvciBhDQo+Pj4+Pj4+IG5vbi1jb29wZXJhdGl2ZQ0KPj4+Pj4+ PiBjbGllbnQgdG8gZ2V0IHRoZSBpbmZvcm1hdGlvbiBhYm91dCB3aGF0IHRoZSBjb21wbGlhbnQg Y2xpZW50cyBhcmUNCj4+Pj4+Pj4gYWxsb3dlZCB0byBkbyBzZWVtcyBteXJpYWQuICBBbmQgdGhl IG51bWJlciBvZiB3YXlzIGEgbm9uLWNvbXBsaWFudA0KPj4+Pj4+PiBjbGllbnQgY2FuIG1pcy1i ZWhhdmUgaXMgYWxzbyBteXJpYWQuDQo+Pj4+Pj4+IFNvIEkgZG8gbm90IGFjdHVhbGx5IHVuZGVy c3RhbmQgdGhlIHRocmVhdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEkgY2FuIGltYWdpbmUgcHJpdmFj eS1kcml2ZW4gY29uZmlkZW50aWFsaXR5IHdpdGggcmVnYXJkIHRvDQo+Pj4+Pj4+cmVxdWVzdHMu DQo+Pj4+Pj4+IEkNCj4+Pj4+Pj4gaG9wZSB3ZSBkb24ndCBoYXZlIHRvIGdvIHRoZXJlLCBidXQg dGhhdCB3b3VsZCBiZSBhIHRocmVhdCB0aGF0IEkNCj4+Pj4+Pj4gd291bGQNCj4+Pj4+Pj4gdGhp bmsgd2FzIG1vcmUgb2YgYW4gaXNzdWUgdGhhbiByZWNldmluZyBhIGNvcHkgb2YgYSByZXNwb25z ZS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFlvdXJzLA0KPj4+Pj4+PiBKb2VsIE0uIEhhbHBlcm4NCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IE9uIDEvMjcvMjAxMiAyOjM5IFBNLCBCYXNhdmFyYWouUGF0aWxAbm9r aWEuY29tIHdyb3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBIZWxsbywNCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gV2hpbGUgZGlzY3Vzc2luZyB0aGUgcmVxdWlyZW1lbnRzIHdlIGNvbmNsdWRlZCB0aGF0 IGl0IHdvdWxkIGJlDQo+Pj4+Pj4+PiB1c2VmdWwNCj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+PiBoYXZl IGEgdGhyZWF0IG1vZGVsIGZvciBQQVdTLiBCZWxvdyBpcyBhbiBpbml0aWFsIHdyaXRldXAgb2Yg dGhlDQo+Pj4+Pj4+PiB0aHJlYXQNCj4+Pj4+Pj4+IG1vZGVsLiBUaGlzIHRocmVhdCBtb2RlbCBj YW4gYmUgaW5jbHVkZWQgaW4gdGhlIFNlY3VyaXR5DQo+Pj4+Pj4+PiBjb25zaWRlcmF0aW9ucw0K Pj4+Pj4+Pj4gc2VjdGlvbiBvZiB0aGUgVXNlLWNhc2UgYW5kIFJlcXVpcmVtZW50cyBJLUQuIFNl Y3VyaXR5DQo+Pj4+Pj4+PnJlcXVpcmVtZW50cw0KPj4+Pj4+Pj4gY2FuDQo+Pj4+Pj4+PiBiZQ0K Pj4+Pj4+Pj4gZGVyaXZlZCBmcm9tIHRoaXMgdGhyZWF0IG1vZGVsLg0KPj4+Pj4+Pj4gQ29tbWVu dHMgd2VsY29tZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLVJhag0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IFRocmVhdCBtb2RlbCBmb3IgdGhlIFBBV1MgcHJvdG9jb2wNCj4+Pj4+Pj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g QXNzdW1wdGlvbnM6DQo+Pj4+Pj4+PiAuLi4uLi4uLi4uLi4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g byBJdCBpcyBhc3N1bWVkIHRoYXQgYW4gYXR0YWNrZXIgaGFzIGZ1bGwgYWNjZXNzIHRvIHRoZSBu ZXR3b3JrDQo+Pj4+Pj4+PiBtZWRpdW0NCj4+Pj4+Pj4+ICAgICBiZXR3ZWVuIHRoZSBtYXN0ZXIg ZGV2aWNlIGFuZCB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2UuIFRoZQ0KPj4+Pj4+Pj4gYXR0YWNr ZXINCj4+Pj4+Pj4+ICAgICBtYXkgYmUgYWJsZSB0byBlYXZlc2Ryb3Agb24gYW55IGNvbW11bmlj YXRpb25zIGJldHdlZW4gdGhlc2UNCj4+Pj4+Pj4+ICAgICBlbnRpdGllcy4gVGhlIGxpbmsgYmV0 d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIHdoaXRlDQo+Pj4+Pj4+PiBzcGFjZQ0KPj4+ Pj4+Pj4gICAgIGRhdGFiYXNlIGNhbiBiZSB3aXJlZCBvciB3aXJlbGVzcyBhbmQgcHJvdmlkZXMg SVANCj4+Pj4+Pj4+Y29ubmVjdGl2aXR5Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBvIEl0IGlzIGFz c3VtZWQgdGhhdCB0aGUgbWFzdGVyIGRldmljZSBvciB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2UN Cj4+Pj4+Pj4+ICAgICBoYXZlIE5PVCBiZWVuIGNvbXByb21pc2VkIGZyb20gYSBzZWN1cml0eSBz dGFuZHBvaW50Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaHJlYXQgMTogT2J0YWluIG1hc3RlciBk ZXZpY2UgYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbg0KPj4+Pj4+Pj5zZWNyZXRzDQo+Pj4+ Pj4+PiAgICAgICAgICBUaGUgbWFzdGVyIGRldmljZSBuZWVkcyB0byBhdXRoZW50aWNhdGUgaXRz ZWxmIHdpdGggdGhlDQo+Pj4+Pj4+PiB3aGl0ZQ0KPj4+Pj4+Pj4gICAgICAgICAgc3BhY2UgZGF0 YWJhc2UgcHJpb3IgdG8gcmVxdWVzdGluZyBjaGFubmVsIGluZm9ybWF0aW9uLg0KPj4+Pj4+Pj4g VGhlDQo+Pj4+Pj4+PiAgICAgICAgICBhdHRhY2tlciBtYXkgdHJ5IHRvIGdldCBhY2Nlc3MgdG8g dGhlIHNlY3JldHMgb2YgdGhlDQo+Pj4+Pj4+PiBtYXN0ZXINCj4+Pj4+Pj4+ICAgICAgICAgIGRl dmljZSB3aGljaCBjYW4gYmUgdXNlZCBtYWxpY2lvdXNseS4gVGhlIGVmZmVjdCBvZiBzdWNoDQo+ Pj4+Pj4+PiBhbg0KPj4+Pj4+Pj4gICAgICAgICAgYXR0YWNrIGJlaW5nIHN1Y2Nlc3NmdWwgd291 bGQgcmVzdWx0IGluIGEgbWFsaWNpb3VzDQo+Pj4+Pj4+PmNsaWVudA0KPj4+Pj4+Pj4gICAgICAg ICAgcmVwbGF5aW5nIHRoZSBzdG9sZW4gYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzZWNy ZXRzDQo+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4gYQ0KPj4+Pj4+Pj4gICAgICAgICAgd2hpdGUgc3Bh Y2UgZGF0YWJhc2UuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRocmVhdCAyOiBTcG9vZmVkIHdoaXRl IHNwYWNlIGRhdGFiYXNlDQo+Pj4+Pj4+PiAgICAgICAgICBBIG1hc3RlciBkZXZpY2UgZGlzY292 ZXJzIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UocykgdGhydQ0KPj4+Pj4+Pj4gd2hpY2gNCj4+Pj4+ Pj4+ICAgICAgICAgIGl0IGNhbiBxdWVyeSBmb3IgY2hhbm5lbCBpbmZvcm1hdGlvbi4gVGhlIG1h c3RlciBkZXZpY2UNCj4+Pj4+Pj4+IG5lZWRzDQo+Pj4+Pj4+PiAgICAgICAgICB0byBlbnN1cmUg dGhhdCB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2Ugd2l0aCB3aGljaCBpdA0KPj4+Pj4+Pj4gICAg ICAgICAgY29tbXVuaWNhdGVzIHdpdGggaXMgYW4gYXV0aGVudGljIGVudGl0eS4gVGhlIHdoaXRl IHNwYWNlDQo+Pj4+Pj4+PiAgICAgICAgICBkYXRhYmFzZSBuZWVkcyB0byBwcm92aWRlIGl0cyBp ZGVudGl0eSB0byB0aGUgbWFzdGVyDQo+Pj4+Pj4+PiBkZXZpY2UNCj4+Pj4+Pj4+ICAgICAgICAg IHdoaWNoIGNhbiBjb25maXJtIHRoZSB2YWxpZGl0eS9hdXRoZW50aWN0eSBvZiB0aGUNCj4+Pj4+ Pj4+IGRhdGFiYXNlLg0KPj4+Pj4+Pj4gQW4NCj4+Pj4+Pj4+ICAgICAgICAgIGF0dGFja2VyIG1h eSBhdHRlbXB0IHRvIHNwb29mIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgYW5kDQo+Pj4+Pj4+PiAg ICAgICAgICBwcm92aWRlIHJlc3BvbnNlcyB0byBhIG1hc3RlciBkZXZpY2Ugd2hpY2ggYXJlIG1h bGljaW91cw0KPj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+PiAgICAgICAgICByZXN1bHQgaW4gdGhlIG1h c3RlciBkZXZpY2UgY2F1c2luZyBpbnRlcmZlcmVuY2UgdG8gdGhlDQo+Pj4+Pj4+PiBwcmltYXJ5 DQo+Pj4+Pj4+PiAgICAgICAgICB1c2VyIG9mIHRoZSBzcGVjdHJ1bS4NCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gVGhyZWF0IDM6IE1vZGlmeWluZyBhIHF1ZXJ5IHJlcXVlc3QNCj4+Pj4+Pj4+ICAgICAg ICAgIEFuIGF0dGFja2VyIG1heSBtb2RpZnkgdGhlIHF1ZXJ5IHJlcXVlc3Qgc2VudCBieSBhIG1h c3Rlcg0KPj4+Pj4+Pj4gICAgICAgICAgZGV2aWNlIHRvIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2Uu IFRoZSBhdHRhY2tlciBtYXkgY2hhbmdlDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+ICAgICAgICAg IGxvY2F0aW9uIG9mIHRoZSBkZXZpY2Ugb3IgdGhlIGNhcGFiaWxpdGllcyBpbiB0ZXJtcyBvZg0K Pj4+Pj4+Pj5pdHMNCj4+Pj4+Pj4+ICAgICAgICAgIHRyYW5zbWl0IHBvd2VyIG9yIGFudGVubmEg aGVpZ2h0IGV0Yy4gd2hpY2ggY291bGQgcmVzdWx0DQo+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4gdGhl DQo+Pj4+Pj4+PiAgICAgICAgICBkYXRhYmFzZSByZXNwb25kaW5nIHdpdGggaW5jb3JyZWN0IGlu Zm9ybWF0aW9uIGFib3V0DQo+Pj4+Pj4+PiBhdmFpbGFibGUNCj4+Pj4+Pj4+ICAgICAgICAgIGNo YW5uZWxzIG9yIG1heCB0cmFuc21pdCBwb3dlciBhbGxvd2VkLiBUaGUgcmVzdWx0IG9mDQo+Pj4+ Pj4+PiBzdWNoIGFuDQo+Pj4+Pj4+PiAgICAgICAgICBhdHRhY2sgaXMgdGhhdCB0aGUgbWFzdGVy IGRldmljZSB3b3VsZCBjYXVzZQ0KPj4+Pj4+Pj4gaW50ZXJlZmVyZW5jZSB0bw0KPj4+Pj4+Pj4g ICAgICAgICAgdGhlIHByaW1hcnkgdXNlciBvZiB0aGUgc3BlY3RydW0uIEl0IGNvdWxkIGFsc28g cmVzdWx0IGluDQo+Pj4+Pj4+PiBhDQo+Pj4+Pj4+PiAgICAgICAgICBkZW5pYWwgb2Ygc2Vydmlj ZSB0byB0aGUgbWFzdGVyIGRldmljZSBieSBpbmRpY2F0aW5nIHRoYXQNCj4+Pj4+Pj4+IG5vDQo+ Pj4+Pj4+PiAgICAgICAgICBjaGFubmVscyBhcmUgYXZhaWxhYmxlLg0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBUaHJlYXQgNDogTW9kaWZ5aW5nIGEgcXVlcnkgcmVzcG9uc2UNCj4+Pj4+Pj4+ICAgICAg ICAgIEFuIGF0dGFja2VyIGNvdWxkIG1vZGlmeSB0aGUgcXVlcnkgcmVzcG9uc2Ugc2VudCBieSB0 aGUNCj4+Pj4+Pj4+IHdoaXRlDQo+Pj4+Pj4+PiAgICAgICAgICBzcGFjZSBkYXRhYmFzZSB0byBh IG1hc3RlciBkZXZpY2UuIFRoZSBjaGFubmVsDQo+Pj4+Pj4+PiBpbmZvcm1hdGlvbiBvcg0KPj4+ Pj4+Pj4gICAgICAgICAgdHJhbnNtaXQgcG93ZXIgYWxsb3dlZCB0eXBlIG9mIHBhcmFtZXRlcnMg Y2FycmllZCBpbiB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgIHJlc3BvbnNlIGNvdWxkIGJlIG1vZGlm aWVkIGJ5IHRoZSBhdHRhY2tlciByZXN1bHRpbmcgaW4NCj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4g ICAgICAgICAgbWFzdGVyIGRldmljZSB1c2luZyBjaGFubmVscyB0aGF0IGFyZSBub3QgYXZhaWxh YmxlIGF0IGENCj4+Pj4+Pj4+ICAgICAgICAgIGxvY2F0aW9uIG9yIHRyYW5zbWl0dGluZyBhdCBh IGdyZWF0ZXIgcG93ZXIgbGV2ZWwgdGhhbg0KPj4+Pj4+Pj4gYWxsb3dlZA0KPj4+Pj4+Pj4gICAg ICAgICAgcmVzdWx0aW5nIGluIGludGVyZmVyZW5jZSB0byB0aGUgcHJpbWFyeSB1c2VyIG9mIHRo YXQNCj4+Pj4+Pj4+ICAgICAgICAgIHNwZWN0cnVtLiBBbHRlcm5hdGl2ZWx5IHRoZSBhdHRhY2tl ciBtYXkgaW5kaWNhdGUgbm8NCj4+Pj4+Pj4+IGNoYW5uZWwNCj4+Pj4+Pj4+ICAgICAgICAgIGF2 YWlsYWJpbGl0eSBhdCBhIGxvY2F0aW9uIHJlc3VsdGluZyBpbiBhIGRlbmlhbCBvZg0KPj4+Pj4+ Pj4gc2VydmljZQ0KPj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+ICAgICAgICAgIHRoZSBtYXN0ZXIgZGV2 aWNlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaHJlYXQgNTogVXNpbmcgcXVlcnkgcmVzcG9uc2Ug aW5mb3JtYXRpb24NCj4+Pj4+Pj4+ICAgICAgICAgIEFuIGF0dGFja2VyIG1heSBiZSBhIG1hc3Rl ciBkZXZpY2Ugd2hpY2ggaXMgbm90IGNlcnRpZmllZA0KPj4+Pj4+Pj4gZm9yDQo+Pj4+Pj4+PiAg ICAgICAgICB1c2UgYnkgdGhlIHJlbGV2YW50IHJlZ3VsYXRvcnkgYm9keS4gVGhlIGF0dGFja2Vy IG1heQ0KPj4+Pj4+Pj4gbGlzdGVuDQo+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4gICAgICAgICAgdGhl IGNvbW11bmljYXRpb24gYmV0d2VlbiBhIHZhbGlkIG1hc3RlciBkZXZpY2UgYW5kIHdoaXRlDQo+ Pj4+Pj4+PiBzcGFjZQ0KPj4+Pj4+Pj4gICAgICAgICAgZGF0YWJhc2UgYW5kIHV0aWxpemUgdGhl IGluZm9ybWF0aW9uIGFib3V0IGF2YWlsYWJsZQ0KPj4+Pj4+Pj4gY2hhbm5lbHMNCj4+Pj4+Pj4+ ICAgICAgICAgIGluIHRoZSByZXNwb25zZSBtZXNzYWdlIGJ5IHV0aWxpemluZyB0aG9zZSBjaGFu bmVscy4gVGhlDQo+Pj4+Pj4+PiByZXN1bHQNCj4+Pj4+Pj4+ICAgICAgICAgIG9mIHN1Y2ggYW4g YXR0YWNrIGlzIHVuYXV0aG9yaXplZCB1c2Ugb2YgY2hhbm5lbHMgYnkgYQ0KPj4+Pj4+Pj4gbWFz dGVyDQo+Pj4+Pj4+PiAgICAgICAgICBkZXZpY2Ugd2hpY2ggaXMgbm90IGNlcnRpZmllZCB0byBv cGVyYXRlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBw YXdzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCj4NCg0K From andy.sago@bt.com Mon Jan 30 09:56:38 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115E311E8089 for ; Mon, 30 Jan 2012 09:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id li4M9acHF+7q for ; Mon, 30 Jan 2012 09:56:37 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 6521411E8081 for ; Mon, 30 Jan 2012 09:56:36 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 17:56:35 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 30 Jan 2012 17:56:35 +0000 From: To: , Date: Mon, 30 Jan 2012 17:56:32 +0000 Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM26LJph+Yc0pEHUy0sgx3BmU5sJYlIt5wgAAWfoA= Message-ID: <619CDADDCCD2B44380834BE8BF6F714140653B437E@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F71414065033163@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414065033163@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:56:38 -0000 Scott Sorry, there is an error in my own correction... it should read "2011 Ofcom= Statement" not 2009. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of and= y.sago@bt.com Sent: 30 January 2012 16:56 To: scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott [Ofcom Implementing] appears in the references section but not the main tex= t. I propose to reference it from the end of one sentence in the second par= agraph, and slightly amend the wording. The changed text would be: Ofcom published in 2004 their Spectrum Framework Review [Spectrum Framework= Review] and their Digital Dividend Review [DDR] in 2005, with proposals fr= om 2009 onwards to access TV white space, culminating in the 2009 Ofcom Sta= tement Implementing Geolocation [Ofcom Implementing]. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 25 January 2012 20:49 To: paws@ietf.org Subject: [paws] Use cases and requirements I-D: sections 1 to 3 (Introducti= on, Conventions and Terminology, Prior Work) Hello All, As editors of the problem statement, use cases & requirements draft we are = attempting to prepare a completed draft which could be ready for working gr= oup last call before IETF83. In the coming days we will post the sections o= f the draft to the mailing list. Our request is that you review these secti= ons and reply to the email with any comments. Below is the text for sections 1 to 3. This text has not changed from version-01 as uploaded October 31, 2011. Our goal is that any discussion on= this text will conclude by February 1. To be clear, approval of the docume= nt will go through the normal process of last calls etc.. We are simply ask= ing for your assistance in preparing a complete & accurate document that co= uld progress the work. So please review the text and send your comments eit= her directly to the editor or to the mailing list. Kind Regards, Raj & Scott 1. Introduction 1.1. Introduction to TV white space Wireless spectrum is a commodity that is regulated by governments. The spectrum is used for various purposes, which include entertainment (e.g. radio and television), communication (telephony and Internet access), military (radars etc.) and, navigation (satellite communication, GPS). Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. One interesting observation is that often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. Academia and Industry have studied multiple cognitive radio mechanisms for use in such a scenario. One simple mechanism is to use a geospatial database that records the primary users occupation, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by secondary users. Spectrum useable for data communications, especially wireless Internet communications, is scarce. One area which has received much attention globally is the TV white space: portions of the TV band that are not used by broadcasters in a given area. In 2008 the United States regulator (the FCC) took initial steps when they published their first ruling on the use of TV white space, and then followed it up with a final ruling in 2010 [FCC Ruling]. Finland passed an Act in 2009 enabling testing of cognitive radio systems in the TV white space. The ECC has completed Report 159 [ECC Report 159] containing requirements for operation of cognitive radio systems in the TV white space. Ofcom published in 2004 their Spectrum Framework Review [Spectrum Framework Review] and their Digital Dividend Review [DDR] in 2005, and have followed up with a proposal to access TV white space. More countries are expected to provide access to their TV spectrum in similar ways. Any entity holding spectrum that is not densely used may be asked to give it up in one way or another for more intensive use. Providing a mechanism by which secondary users share the spectrum with the primary user is attractive in many bands in many countries. Probasco & Patil Expires July 18, 2012 [Page 4] Internet-Draft PAWS: Problem, uses and requirements January 2012 Television transmission until now has primarily been analog. The switch to digital transmission has begun. As a result the spectrum allocated for television transmission can now be more effectively used. Unused channels and bands between channels can be used as long as they do not interfere with the primary service for which that channel is allocated. While urban areas tend to have dense usage of spectrum and a number of TV channels, the same is not true in rural and semi-urban areas. There can be a number of unused TV channels in such areas that can be used for other services. The figure below shows TV white space within the lower UHF band: Avg | usage| |-------------- White Space | | | | | | 0.6| || || V V || | || ||| | || 0.4| || |||| | || | || |||| | ||<----TV transmission 0.2| || |||| | || |---------------------------------------- 400 500 600 700 800 Frequency in MHz -> Figure 1: High level view of TV White Space The fundamental issue is how to determine for a specific location and specific time if any of the spectrum is available for secondary use. There are two dimensions of use that may be interesting: space (the area in which a secondary user would not interfere with a primary user, and time: when the secondary use would not interfere with the primary use. In this discussion, we consider the time element to be relatively long term (hours in a day) rather than short term (fractions of a second). Location in this discussion is geolocation: where the transmitters (and sometimes receivers) are located relative to one another. In operation, the database records the existing user's transmitter (and some times receiver) locations along with basic transmission characteristics such as antenna height, and sometimes power. Using rules established by the regulator, the database calculates an exclusion zone for each authorized primary user, and attaches a time schedule to that use. The secondary user queries the database with its location. The database intersects the exclusion zones with the queried location, and returns the portion of the spectrum not in any exclusion zone. Such methods of geospatial database query to avoid interference have been shown to achieve favorable results, and are thus the basis for rulings by the FCC and Probasco & Patil Expires July 18, 2012 [Page 5] Internet-Draft PAWS: Problem, uses and requirements January 2012 reports from ECC and Ofcom. In any country, the rules for which primary entities are entitled to protection, how the exclusion zones are calculated, and what the limits of use by secondary entities are may vary. However, the fundamental notion of recording primary users, calculating exclusion zones, querying by location and returning available spectrum (and the schedule for that spectrum) are common This document includes the problem statement, use cases and requirements associated with the use of white space spectrum by secondary users via a database query protocol. 1.2. Scope 1.2.1. In Scope This document applies only to communications required for basic service in TV white space. The protocol will enable a white space radio device to complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined access method. 3. Register with the database using a well-defined protocol. 4. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 5. Receive in return a list of currently available white space using a well-defined format for returning information. As a result, some of the scenarios described in the following section are out of scope for this specification (although they might be addressed by future specifications). 1.2.2. Out of Scope The following topics are out of scope for this specification: TBD 2. Conventions and Terminology Probasco & Patil Expires July 18, 2012 [Page 6] Internet-Draft PAWS: Problem, uses and requirements January 2012 2.1. Conventions Used in This Document 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]. 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A primary user of white space spectrum which is afforded protection against interference by secondary users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. Probasco & Patil Expires July 18, 2012 [Page 7] Internet-Draft PAWS: Problem, uses and requirements January 2012 TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use, but is not fully occupied by that primary use at a specific location and time. White Space Device (WSD) A device which is a secondary user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. 3. Prior Work 3.1. The concept of Cognitive Radio A cognitive radio uses knowledge of the local radio environment to dynamically adapt its own configuration and function properly in a changing radio environment. Knowledge of the local radio environment can come from various technology mechanisms including sensing (attempting to ascertain primary users by listening for them within the spectrum), location determination and internet connectivity to a database to learn the details of the local radio environment. TV White Space is one implementation of cognitive radio. Because a cognitive radio adapts itself to the available spectrum in a manner that prevents the creation of harmful interference, the spectrum can be shared among different radio users. 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all full- power U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 18, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Air Interfaces Efforts are ongoing to specify air-interfaces for use in white space spectrum. IEEEs 802.11af task group is currently working on one such specification. IEEE 802.22 is another example. Other air interfaces could be specified in the future such as LTE. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Mon Jan 30 09:58:11 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CB921F860F for ; Mon, 30 Jan 2012 09:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAkMe6VTpz+M for ; Mon, 30 Jan 2012 09:58:10 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0A521F860D for ; Mon, 30 Jan 2012 09:58:10 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UHvBci006763; Mon, 30 Jan 2012 19:58:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 19:57:19 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 18:57:18 +0100 From: To: , Thread-Topic: [paws] Threat model Thread-Index: AQHM3Uuw2q+mv4TAuUKOAAuKydmQAZYkwVQA Date: Mon, 30 Jan 2012 17:57:18 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.33] Content-Type: text/plain; charset="us-ascii" Content-ID: <0557ADB1B3E44A4C9C42D9B081C43549@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 17:57:19.0554 (UTC) FILETIME=[9C237220:01CCDF78] X-Nokia-AV: Clean Subject: Re: [paws] Threat model X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 17:58:11 -0000 Hi Paul, Do you have any proposals or text w.r.t the threat model writeup? Also from an IETF perspective regarding threat models, please see Peter's email: http://www.ietf.org/mail-archive/web/paws/current/msg00592.html -Raj On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >It's good to have requirements based on such an analysis. This is an >interesting start, but we may be mixing threats, vulnerabilities and >mechanisms. > >Threats are typically tied to an actor ... human or not. I'm not sure >it's worth going hard over to something like the NIST 800-30 definitions >of threats, but within this framework the threats are Governments, >disgruntled insiders, tsunamis etc. Being the IETF we can jump more >quickly to the threat event and specifics of an attack, but should at >least expand threats to include natural events and connectivity problems. > Robustness or emergency modes might be interesting to consider. > >We also have a problem in this analysis of perspective - are we >considering threats as viewed from regulatory agency or the end device >owner or both. We should consider both - but they are contradictory >perspectives. Users want continuity of service. Governments (the >regulators) want control of the airwaves. > >Most of the real threats that we have are nearly impossible to prevent at >the protocol level. It's still worth examining the threats to see where >we stand. =20 > >On the current document threats: > >>o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >>Threat 1: Obtain master device authentication/authorization secrets >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >This does not seem consistent with the prior statement of "not >compromised". >Restatement > >Threat: User modifies a device to masquerade as another valid certified >device. > >This is an interesting case where threat/vulnerability/risk play >together. The FCC or other regulatory agencies want traceability of >devices. If a user wants to run a rogue radio, there is no reason to >access the database (low risk - no payoff). The only reason this would >be an interesting attack might be to avoid tracking and have some >anonymity. > >>Threat 2: Spoofed white space database >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. > >I think this is two types of threat events: > - malicious denial of service or intentional interference with incumbents > - impersonation of white space database to enable operation of a device >that may=20 > not otherwise be possible (blocked device, unallocated channels). >This may or may not > interfere with incumbent devices > >>Threat 3: Modifying a query request >... > >>Threat 4: Modifying a query response >Seems like these two could be lumped together ...MiTM modifies protocol >messages to: > - deny service > - interfere with incumbents > - provide unauthorized channel usage (most likely risk IMHO) > >>Threat 5: Using query response information >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >As stated this is a mechanism - a clearer statement might be. > >Threat: Unauthorized use of channels by an uncertified device. > >Anyone can already go to a database and find available channels. If a >device can operate without going to the database there is nothing that >paws can do to stop it operating in available or non-available channels. > >Just to get some discussion going -here's a couple more possible threats.. > >Threat: Third party tracking of white space device location > Likely a valuable commodity to sell for advertizing with no technical >design or policy for privacy >Threat: Database owner termination of device service for reasons other >than incumbent protection > > > >Paul > > From gerald.chouinard@sympatico.ca Mon Jan 30 12:30:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DF411E8091 for ; Mon, 30 Jan 2012 12:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzCvpTT4TQDx for ; Mon, 30 Jan 2012 12:29:59 -0800 (PST) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7D11E80BB for ; Mon, 30 Jan 2012 12:29:59 -0800 (PST) Received: from BLU0-SMTP82 ([65.55.116.73]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 12:29:59 -0800 X-Originating-IP: [174.95.247.44] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.247.44]) by BLU0-SMTP82.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 12:29:57 -0800 From: Gerald Chouinard To: Date: Mon, 30 Jan 2012 15:29:56 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CCDF64.06B5E790" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aczfje4hBqIvPtzVQA6ucq3r2yBLaQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 30 Jan 2012 20:29:58.0354 (UTC) FILETIME=[EF356B20:01CCDF8D] X-Mailman-Approved-At: Mon, 30 Jan 2012 13:46:52 -0800 Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:38:53 -0000 ------=_NextPart_000_002E_01CCDF64.06B5E790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald ------=_NextPart_000_002E_01CCDF64.06B5E790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Here is my understanding of the = terms:

 

= Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

= Lightly licensed: Special case = where thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. The annual = license fee is usually small to facilitate the deployment of a service that would = not normally be economically attractive.  Small local operators would = be interested by this (e.g., rural broadband in Canada<= /st1:place>) and not big Telcos that would normally work with full licensing through = auction over large service areas.

 

= License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

 

= Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

 

To my knowledge, the term “unlicensed” is used only in the USA to describe a legal operation because the term = “license-exempt” has been used for another specific = purpose.

 

Since the PAWS addresses the = interface to the database for the international market, it should rely on the = definition of the terms recognized by the ITU-R. I would suggest the use of = ‘licensed’ and ‘license-exempt’ with a footnote indicating that the = term ‘unlicensed’ is used in the USA instead of the usual = ‘license-exempt’.

 

Gerald

------=_NextPart_000_002E_01CCDF64.06B5E790-- From jmalyar@telcordia.com Mon Jan 30 13:53:08 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B280611E80B1 for ; Mon, 30 Jan 2012 13:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dh4fAp5GwMh for ; Mon, 30 Jan 2012 13:53:02 -0800 (PST) Received: from dnsmx1rrc.telcordia.com (dnsmx1rrc.telcordia.com [128.96.20.41]) by ietfa.amsl.com (Postfix) with ESMTP id A20AC11E80B0 for ; Mon, 30 Jan 2012 13:52:52 -0800 (PST) Received: from pya-dte-bms01.telcordia.com (pya-dte-bms01.cc.telcordia.com [128.96.37.48]) by dnsmx1rrc.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q0ULqpix021454; Mon, 30 Jan 2012 16:52:52 -0500 (EST) X-AuditID: 80602530-b7bceae0000009fd-71-4f27112d1996 Received: from rrc-dte-exhb1.dte.telcordia.com (rrc-dte-exhb1.cc.telcordia.com [128.96.20.12]) by pya-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id C4.50.02557.D21172F4; Mon, 30 Jan 2012 16:52:45 -0500 (EST) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by rrc-dte-exhb1.dte.telcordia.com ([128.96.20.12]) with mapi; Mon, 30 Jan 2012 16:52:51 -0500 From: "Malyar, John P" To: "'Gerald Chouinard'" , "'paws@ietf.org'" Date: Mon, 30 Jan 2012 16:52:50 -0500 Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: Aczfje4hBqIvPtzVQA6ucq3r2yBLaQACytMA Message-ID: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75Frrcdteexmb1dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:53:08 -0000 --_000_5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75Frrcdteexmb1dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Use of the two terms identified below with the suggested footnote seems a r= easonable compromise. From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ger= ald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald --_000_5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75Frrcdteexmb1dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Use of th= e two terms identified below with the suggested footnote seems a reasonable= compromise.  

 

From: paws-bounc= es@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Choui= nard
Sent: Monday, January 30, 2012 3:30 PM
To: paws@ie= tf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicen= sed'

 

All,

 

Here is my understanding of the terms:

&= nbsp;

Licensed: Spectrum that is acquired by an operato= r over a given service area for a given time period.  This is usually = done through auctions (think of the Telcos), beauty contest, first-come / f= irst-served or by government allocation (e.g., public service).

 <= /span>

Lightly licensed: Special case where thefrequency alloc= ation is done through first-come / first-served process for a given time fr= ame over a relatively limited service area. The annual license fee is usual= ly small to facilitate the deployment of a service that would not normally = be economically attractive.  Small local operators would be interested= by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas.

 =

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'= >License-exempt: Operation of RF devices in a frequency band w= here no formal licensing process is needed such as in the 2.4 GHz ISM band.= In the USA<= /ns0:place>, this term is u= sed for a specific type of operation. The FCC should be contacted to clarif= y it.

 

Unlicensed: Illegal operation o= f an RF device that can transmit in a frequency band without a duly issued = license.  In the USA, = this term is used to mean “license-exempt," see above.

=  

To my knowledge, the term “unlicensed” is used o= nly in the USA to describe = a legal operation because the term “license-exempt” has been us= ed for another specific purpose.

 

Since the PAWS = addresses the interface to the database for the international market, it sh= ould rely on the definition of the terms recognized by the ITU-R. I would s= uggest the use of ‘licensed’ and ‘license-exempt’ w= ith a footnote indicating that the term ‘unlicensed’ is used in= the USA instead of the usual ‘license-exempt’.

 

Gerald

= --_000_5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75Frrcdteexmb1dt_-- From nbravin@earthlink.net Mon Jan 30 14:06:34 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E408A11E80A2 for ; Mon, 30 Jan 2012 14:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgVtIQrB59a7 for ; Mon, 30 Jan 2012 14:06:34 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id EA9E321F85AC for ; Mon, 30 Jan 2012 14:06:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Mau3gXA+gbcaS3P78aPrE7papelhVDpekT4HtaLUEHM34e01EAGA6sLLD1qK5GcJ; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RrzMv-00059N-2J; Mon, 30 Jan 2012 17:06:33 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--385843083 From: Nancy Bravin In-Reply-To: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> Date: Mon, 30 Jan 2012 14:06:31 -0800 Message-Id: <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> To: "Malyar, John P" X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8674c592d8500fb65d0614c66862460ff3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "'paws@ietf.org'" , 'Gerald Chouinard' Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:06:35 -0000 --Apple-Mail-2--385843083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi All, I Agree. Gerald, I think you did it! Seem perfect to me, Sincerely, Nancy=20 On Jan 30, 2012, at 1:52 PM, Malyar, John P wrote: > Use of the two terms identified below with the suggested footnote = seems a reasonable compromise. =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Gerald Chouinard > Sent: Monday, January 30, 2012 3:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos that would = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail-2--385843083 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi All,  I Agree.
Gerald, I think you did = it! Seem perfect to me, Sincerely, = Nancy 

On Jan 30, 2012, at 1:52 PM, Malyar, = John P wrote:

Use = of the two terms identified below with the suggested footnote seems a = reasonable compromise.  
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Gerald = Chouinard
Sent: Monday, January 30, 2012 = 3:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
 
All,
 
 
 Spectrum that is acquired = by an operator over a given service area for a given time period. =  This is usually done through auctions (think of the Telcos), = beauty contest, first-come / first-served or by government allocation = (e.g., public service). 
 Special case where = thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. = The annual license fee is usually small to facilitate the deployment of = a service that would not normally be economically attractive. =  Small local operators would be interested by this (e.g., rural = broadband in ) and not big Telcos that would normally work with full = licensing through auction over large service areas.
 Operation of RF devices in = a frequency band where no formal licensing process is needed such as in = the 2.4 GHz ISM band. In the  
 Illegal operation of an RF = device that can transmit in a frequency band without a duly issued = license.  In the  
  to describe a legal = operation because the term =93license-exempt=94 has been used for = another specific purpose.
 
Since the PAWS addresses the interface to the = database for the international market, it should rely on the definition = of the terms recognized by the ITU-R. I would suggest the use of = =91licensed=92 and =91license-exempt=92 with a footnote indicating that = the term =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92.
Gerald Date: Mon, 30 Jan 2012 17:09:51 -0500 Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: Aczfm/Z5FN3XVNbsSH2yT53v65F9Mg== Message-ID: In-Reply-To: <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB4C7EE61EA1Fpeterspectrumbridgecom_" MIME-Version: 1.0 Cc: "'paws@ietf.org'" , 'Gerald Chouinard' Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:09:48 -0000 --_000_CB4C7EE61EA1Fpeterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One small change to the definition of licensed. Although you identify all t= he original mechanisms I can think of for acquiring spectrum many operators= have built or extended their portfolio through secondary markets or M&A ac= tivities. From: Nancy Bravin > Date: Mon, 30 Jan 2012 17:06:31 -0500 To: "Malyar, John P" > Cc: "'paws@ietf.org'" >, 'Gerald Chouinard' > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Hi All, I Agree. Gerald, I think you did it! Seem perfect to me, Sincerely, Nancy On Jan 30, 2012, at 1:52 PM, Malyar, John P wrote: Use of the two terms identified below with the suggested footnote seems a r= easonable compromise. From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gerald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CB4C7EE61EA1Fpeterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
One small change to the definit= ion of licensed. Although you identify all the original mechanisms I can th= ink of for acquiring spectrum many operators have built or extended their p= ortfolio through secondary markets or M&A activities.

From: Nancy Bravin <nbravin@earthlink.net>
Date: Mon, 30 Jan 2012 17:06:31 -0500<= br>To: "Malyar, John P" = <jmalyar@telcordia.com><= br>Cc: "'paws@ietf.org'" <paws@ietf.org>, 'Gerald Chouinard' <gerald.chouinard@sympatico.ca>
Subject: Re: [paws] Discussion on 'license-ex= empt' vs 'unlicensed'

Hi All,  I Agree.
Gerald, I think = you did it! Seem perfect to me, Sincerely, Nancy 

<= div>On Jan 30, 2012, at 1:52 PM, Malyar, John P wrote:

Use of the two terms identified bel= ow with the suggested footnote seems a reasonable compromise.  
 
=
From= : pa= ws-bounces@ietf.org [= mailto:paws-bounces@ietf.org]<= span class=3D"Apple-converted-space"> On Behalf Of Gerald Chouinard
Sent: Monday, January 30, 20= 12 3:30 PM
To: = paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'=
 
All,<= /div>
 
Here is my understanding of the terms:
 =
Licensed: Spectrum tha= t is acquired by an operator over a given service area for a given time per= iod.  This is usually done through auctions (think of the Telcos), bea= uty contest, first-come / first-served or by government allocation (e.g., p= ublic service).
 
=
Lightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively = limited service area. The annual license fee is usually small to facilitate= the deployment of a service that would not normally be economically attrac= tive.  Small local operators would be interested by this (e.g., rural = broadband in Canada) and not big Telcos that w= ould normally work with full licensing through auction over large service a= reas.
<= div style=3D"margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-b= ottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">=  
License-exempt:&n= bsp;Operation of RF devices in a frequency band where no formal lice= nsing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation.= The FCC should be contacted to clarify it.
 
Unlicensed: Illegal operation of an RF dev= ice that can transmit in a frequency band without a duly issued license. &n= bsp;In the USA, this term is used to mean =93l= icense-exempt," see above.
 <= o:p>
To my knowledge, the term =93unlicensed=94 is u= sed only in the USA to describe a legal operation because the term =93l= icense-exempt=94 has been used for another specific purpose.
 
Since the PAWS addr= esses the interface to the database for the international market, it should= rely on the definition of the terms recognized by the ITU-R. I would sugge= st the use of =91licensed=92 and =91license-exempt=92 with a footnote indic= ating that the term =91unlicensed=92 is used in the USA instead of the usua= l =91license-exempt=92.
 
Gerald
_____________________________= __________________
paws mailing list
paws@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/paws" style=3D"color: blue;= text-decoration: underline; ">https://www.ietf.org/mailman/listinfo/paws

<= /html> --_000_CB4C7EE61EA1Fpeterspectrumbridgecom_-- From paul@marvell.com Mon Jan 30 14:29:25 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38C021F85AF for ; Mon, 30 Jan 2012 14:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYeG2Dde+3Ii for ; Mon, 30 Jan 2012 14:29:24 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0DC21F85CD for ; Mon, 30 Jan 2012 14:29:23 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTycZv/u/wYTW/PvAthMmAtGagFfK8CtN@postini.com; Mon, 30 Jan 2012 14:29:24 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 30 Jan 2012 14:29:18 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "paws@ietf.org" Date: Mon, 30 Jan 2012 14:29:13 -0800 Thread-Topic: Threats, Services and Predicatable Availability Thread-Index: AQHM3Uuw2q+mv4TAuUKOAAuKydmQAZYkwVQAgACYDxA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567642F92@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: 0VA= DxbW FLJJ Hqen Ino0 JuCl K5L9 LAXy MMnC R/Zo TRFW UskU UzWl VNDI VfWb WaXG; 2; YgBhAHMAYQB2AGEAcgBhAGoALgBwAGEAdABpAGwAQABuAG8AawBpAGEALgBjAG8AbQA7AHAAYQB3AHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {138F8EAF-1CD8-4C25-B3E6-ACA10837CF3C}; cABhAHUAbABAAG0AYQByAHYAZQBsAGwALgBjAG8AbQA=; Mon, 30 Jan 2012 22:29:13 GMT; VABoAHIAZQBhAHQAcwAsACAAUwBlAHIAdgBpAGMAZQBzACAAYQBuAGQAIABQAHIAZQBkAGkAYwBhAHQAYQBiAGwAZQAgAEEAdgBhAGkAbABhAGIAaQBsAGkAdAB5AA== x-cr-puzzleid: {138F8EAF-1CD8-4C25-B3E6-ACA10837CF3C} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Threats, Services and Predicatable Availability X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:29:25 -0000 Hi Raj, >Do you have any proposals or text w.r.t the threat model writeup? Also >from an IETF perspective regarding threat models, please see Peter's >email: http://www.ietf.org/mail-archive/web/paws/current/msg00592.html > >-Raj I'll spend a little time formalizing the ideas I submitted below. However,= "threats" are part of a complete set of requirements and looking at the cu= rrent proposal, I feel we need to clarify the service that we offer before = we can say what are real threats. Specifically, the threat: >>> device which can be used maliciously. The effect of such an >>> attack being successful would result in a malicious client >>> replaying the stolen authentication/authorization secrets to a >>> white space database. This is not a threat as worded... but why? We need to define what we offer, and then things that prevent or break thes= e offered services are potential risks that can be mapped to threats. As a= start, I propose (which I hope is mostly in line with the use cases) two m= ain services with some subtopics: 1) Prevent Interference of License-exempt Use with Licensed Operation=09 - Support changes in channel, time Period and region for licensed operatio= n - Support predictable availability of licensed channels - Support the ability to disable specific vendor/model-types from operatio= n when=20 they are determined to be causing interference 2) Enable Authorized Channel Utilization for License-exempt Operation=09 - Facilitate fixed use of channels - Facilitate mobile use of channels - Facilitate indoor use of channels - Support predictable availability of license-exempt channels - Support changing of authorized channels to prevent interference with lic= ensed usage So, threat event is something that has a result of preventing the promised = services. The threat event either causes unapproved interference with lice= nsed operation, or it prevents White Space "license-exempt" operation.=20 The "Support Predictable Availability" is something new I'd like to introdu= ce for discussion. There needs to be a expectation that once you are using= a channel that your use will not be terminated abruptly in an unanticipate= d manner. Right now - we are creating mechanism to quickly cutoff a device= for any reason at all (for the use case of mobile microphones). This is ac= tually supposed to be a predictable event with some type of scheduling. An= license-exempt devices needs to be able to determine how long it might ope= rate under the regulations in a particular channel/region. Building a syst= em where you never know when your communications might get cut off seems li= ke a bad idea. =20 Paul > >On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: > >>It's good to have requirements based on such an analysis. This is an >>interesting start, but we may be mixing threats, vulnerabilities and >>mechanisms. >> >>Threats are typically tied to an actor ... human or not. I'm not sure >>it's worth going hard over to something like the NIST 800-30 >definitions >>of threats, but within this framework the threats are Governments, >>disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>quickly to the threat event and specifics of an attack, but should at >>least expand threats to include natural events and connectivity >problems. >> Robustness or emergency modes might be interesting to consider. >> >>We also have a problem in this analysis of perspective - are we >>considering threats as viewed from regulatory agency or the end device >>owner or both. We should consider both - but they are contradictory >>perspectives. Users want continuity of service. Governments (the >>regulators) want control of the airwaves. >> >>Most of the real threats that we have are nearly impossible to prevent >at >>the protocol level. It's still worth examining the threats to see >where >>we stand. >> >>On the current document threats: >> >>>o It is assumed that the master device or the white space database >>> have NOT been compromised from a security standpoint. >>> >>>Threat 1: Obtain master device authentication/authorization secrets >>> The master device needs to authenticate itself with the white >>> space database prior to requesting channel information. The >>> attacker may try to get access to the secrets of the master >>> device which can be used maliciously. The effect of such an >>> attack being successful would result in a malicious client >>> replaying the stolen authentication/authorization secrets to a >>> white space database. >>This does not seem consistent with the prior statement of "not >>compromised". >>Restatement >> >>Threat: User modifies a device to masquerade as another valid certified >>device. >> >>This is an interesting case where threat/vulnerability/risk play >>together. The FCC or other regulatory agencies want traceability of >>devices. If a user wants to run a rogue radio, there is no reason to >>access the database (low risk - no payoff). The only reason this would >>be an interesting attack might be to avoid tracking and have some >>anonymity. >> >>>Threat 2: Spoofed white space database >>> A master device discovers a white space database(s) thru which >>> it can query for channel information. The master device needs >>> to ensure that the white space database with which it >>> communicates with is an authentic entity. The white space >>> database needs to provide its identity to the master device >>> which can confirm the validity/authenticty of the database. An >>> attacker may attempt to spoof a white space database and >>> provide responses to a master device which are malicious and >>> result in the master device causing interference to the primary >>> user of the spectrum. >> >>I think this is two types of threat events: >> - malicious denial of service or intentional interference with >incumbents >> - impersonation of white space database to enable operation of a >device >>that may >> not otherwise be possible (blocked device, unallocated channels). >>This may or may not >> interfere with incumbent devices >> >>>Threat 3: Modifying a query request >>... >> >>>Threat 4: Modifying a query response >>Seems like these two could be lumped together ...MiTM modifies protocol >>messages to: >> - deny service >> - interfere with incumbents >> - provide unauthorized channel usage (most likely risk IMHO) >> >>>Threat 5: Using query response information >>> An attacker may be a master device which is not certified for >>> use by the relevant regulatory body. The attacker may listen to >>> the communication between a valid master device and white space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. The result >>> of such an attack is unauthorized use of channels by a master >>> device which is not certified to operate. >>As stated this is a mechanism - a clearer statement might be. >> >>Threat: Unauthorized use of channels by an uncertified device. >> >>Anyone can already go to a database and find available channels. If a >>device can operate without going to the database there is nothing that >>paws can do to stop it operating in available or non-available >channels. >> >>Just to get some discussion going -here's a couple more possible >threats.. >> >>Threat: Third party tracking of white space device location >> Likely a valuable commodity to sell for advertizing with no >technical >>design or policy for privacy >>Threat: Database owner termination of device service for reasons other >>than incumbent protection >> >> >> >>Paul >> >> From paul@marvell.com Mon Jan 30 14:44:31 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05C721F8739 for ; Mon, 30 Jan 2012 14:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.904 X-Spam-Level: X-Spam-Status: No, score=-5.904 tagged_above=-999 required=5 tests=[AWL=-0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0NYNDcKt31z for ; Mon, 30 Jan 2012 14:44:29 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75721F8738 for ; Mon, 30 Jan 2012 14:44:28 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTycdSYslbpM8lshSL0rYvkohCA4UZIkG@postini.com; Mon, 30 Jan 2012 14:44:29 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 30 Jan 2012 14:44:21 -0800 From: Paul Lambert To: Nancy Bravin , "Malyar, John P" Date: Mon, 30 Jan 2012 14:44:19 -0800 Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: Aczfm3BdQBH1Lq7SSnO3xelkgSJjzQABKoVA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> In-Reply-To: <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6SCVEXCH2marve_" MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:44:32 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6SCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What is the correct term for something that is operating as a license-exemp= t device - yet has been given short term authorization to share a channel w= ith other license-exempt devices based on a query to a regional authorities= database in a portion of spectrum that may also include licensed or light-= licensed devices at other times or in other areas. Paul From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gerald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6SCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

What is the correct term for something that is operating as = a license-exempt device – yet has been given short term authorization to share a chann= el with other license-exempt devices based on a query to a regional authorities dat= abase in a portion of spectrum that may also include licensed or light-licensed d= evices at other times or in other areas.

 

 

Paul

 

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard
Sent: Monday, Januar= y 30, 2012 3:30 PM
To: paws@ietf.org
Subject: [paws] Disc= ussion on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understanding of the terms:

 

Licensed:&nbs= p;Spec= trum that is acquired by an operator over a given service area for a given time period.  This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g.= , public service).

 

Lightly licensed:&nbs= p;Spec= ial case where thefrequency allocation is done through first-come / first-serve= d process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a servi= ce that would not normally be economically attractive.  Small local opera= tors would be interested by this (e.g., rural broadband in Canada) and not big Telcos that = would normally work with full licensing through auction over large service areas.=

 

License-exempt:<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>&nbs= p;Oper= ation of RF devices in a frequency band where no formal licensing process is need= ed such as in the 2.4 GHz ISM band. In the=  USA, this term is used for a specific type of operation. The FCC should be conta= cted to clarify it.

 

Unlicensed:&nbs= p;Ille= gal operation of an RF device that can transmit in a frequency band without a d= uly issued license.  In the USA, this term is used to mean “license-exempt," see above.

 

To my knowledge, the term “unlicensed” is used only= in the USA to describe a legal operation be= cause the term “license-exempt” has been used for another specific purpose.

 

Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recogni= zed by the ITU-R. I would suggest the use of ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the USA instead of the usual ‘license-exempt’.

 

Gerald

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

 

--_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6SCVEXCH2marve_-- From brian.rosen@neustar.biz Mon Jan 30 14:45:59 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503AA21F873A for ; Mon, 30 Jan 2012 14:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc-9mhAbCCQd for ; Mon, 30 Jan 2012 14:45:58 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C0A8E21F8739 for ; Mon, 30 Jan 2012 14:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1327963676; x=1643318663; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=C/62Wo+ia4YuKFPTOpUD7KHqPj8nBIF5jegx2E0JOkM=; b=TrkdufTw7VkLt8ZcWa/LtZhBdWiOnRrpxPmuDPlaQ7W1Vdqfiauu7thA978AdG T3vR3zsYDQOBbkQYYsMV9zwQ== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.5025551; Mon, 30 Jan 2012 17:47:55 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 30 Jan 2012 17:45:43 -0500 From: "Rosen, Brian" To: Paul Lambert Date: Mon, 30 Jan 2012 17:45:43 -0500 Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: AczfoOYkVWll9sHrSBa3meBldn4MwQ== Message-ID: <32E7EA09-A091-4FE5-B3A1-85F249D3520E@neustar.biz> References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: J1SvncABucqjhlHHxycPBA== Content-Type: multipart/alternative; boundary="_000_32E7EA09A0914FE5B3A185F249D3520Eneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:45:59 -0000 --_000_32E7EA09A0914FE5B3A185F249D3520Eneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Uh, whitespace device? Sorry, couldn't resist. Brian On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote: What is the correct term for something that is operating as a license-exemp= t device =96 yet has been given short term authorization to share a channel= with other license-exempt devices based on a query to a regional authoriti= es database in a portion of spectrum that may also include licensed or ligh= t-licensed devices at other times or in other areas. Paul From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gerald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_32E7EA09A0914FE5B3A185F249D3520Eneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Uh, whitespace device?

Sorry, couldn't resist.

Brian

On Jan 30, 2012, at 5:44 PM,= Paul Lambert wrote:

 
What= is the correct term for something that is operating as a license-exempt de= vice =96 yet has been given short term authorization to share a channel wit= h other license-exempt devices based on a query to a regional authorities d= atabase in a portion of spectrum that may also include licensed or light-li= censed devices at other times or in other areas.
 
 = ;
Paul
 
&nb= sp;
 <= o:p>
From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard
Sent: Monday, January 30, 2012 3:30 PM
To:<= span class=3D"apple-converted-space"> paws@ietf.org
Subject: [pa= ws] Discussion on 'license-exempt' vs 'unlicensed'
<= /div>
 
To my knowledge, the term =93unlicensed=94 is used only in the USA to describe a legal operation because the term =93l= icense-exempt=94 has been used for another specific purpose.
=
 
_________________________________= ______________
paws mailing list
paw= s@ietf.org
https://www.ietf.org/mailman/listinfo/paws

= --_000_32E7EA09A0914FE5B3A185F249D3520Eneustarbiz_-- From Gabor.Bajko@nokia.com Mon Jan 30 14:48:45 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B845B21F8757 for ; Mon, 30 Jan 2012 14:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9s8eUY31FML for ; Mon, 30 Jan 2012 14:48:43 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC821F8755 for ; Mon, 30 Jan 2012 14:48:42 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UMmfFj025827; Tue, 31 Jan 2012 00:48:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 00:48:41 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 23:48:41 +0100 From: To: , Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: Aczfje4hBqIvPtzVQA6ucq3r2yBLaQAEUHYg Date: Mon, 30 Jan 2012 22:48:40 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23@008-AM1MPN1-006.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.66.245] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 22:48:41.0569 (UTC) FILETIME=[503B3D10:01CCDFA1] X-Nokia-AV: Clean Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:48:45 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as 'license-exempt', in most cases the t= erm 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These look to be very pre= cise definitions, however in everyday use I rarely hear people referring to= ISM band as ‘license-exempt’, in most cases the term ‘un= licensed-band’ is used.

 <= /p>

Therefore, may I suggest = that the draft will include the following statement:

 <= /p>

The terms unlicensed and = license-exempt spectrum are used in this document interchangeably and refer= to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'<= /o:p>

 

All,

 

Here is my understanding of th= e terms:

 

Licensed: Spectrum that is acquired by an operator over a given servi= ce area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by gove= rnment allocation (e.g., public service).

 

Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a relatively= limited service area. The annual license fee is usually small to facilitat= e the deployment of a service that would not normally be economically attra= ctive.  Small local operators would be interested by this (e.g., rural broadband in Canada= ) and not big Telcos that would normally work with full licensing through auction ov= er large service areas.

 

License-exempt:<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:navy"> Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be cont= acted to clarify it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to mean “license-exempt," see above.

 

To my knowledge, the term R= 20;unlicensed” is used only in the USA to = describe a legal operation because the term “license-exempt” has been used for another specific purpose.

 

Since the PAWS addresses the i= nterface to the database for the international market, it should rely on th= e definition of the terms recognized by the ITU-R. I would suggest the use of ‘licensed’ and ‘license-exempt’= with a footnote indicating that the term ‘unlicensed’ is used = in the USA instead of the usual ‘license-exempt’.

 

Gerald<= /o:p>

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23008AM1MPN1006mg_-- From paul@marvell.com Mon Jan 30 15:19:34 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7D11E80C7 for ; Mon, 30 Jan 2012 15:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.722 X-Spam-Level: X-Spam-Status: No, score=-5.722 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRTYiGy6lcUg for ; Mon, 30 Jan 2012 15:19:31 -0800 (PST) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD4E11E80C6 for ; Mon, 30 Jan 2012 15:19:21 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKTycldsoIMcxiUJbva8oou19TUZC/OlQV@postini.com; Mon, 30 Jan 2012 15:19:30 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 30 Jan 2012 15:17:19 -0800 From: Paul Lambert To: "Rosen, Brian" , "paws@ietf.org" Date: Mon, 30 Jan 2012 15:17:18 -0800 Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: AczfoOYkVWll9sHrSBa3meBldn4MwQAAOheA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567642FBD@SC-VEXCH2.marvell.com> References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> <32E7EA09-A091-4FE5-B3A1-85F249D3520E@neustar.biz> In-Reply-To: <32E7EA09-A091-4FE5-B3A1-85F249D3520E@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FBDSCVEXCH2marve_" MIME-Version: 1.0 Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:19:34 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FBDSCVEXCH2marve_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Uh, whitespace device? :) Maybe ... but if we are talking about the "license" it might be "Database = Licensed", "Database License-Exempt", or "White Space Licensed" Seems like we had some really excellent definitions - but happened to be mi= ssing the category that we are trying to support. "Unlicensed" in FCC terms also has a connotation of multiple users and robu= stness. Devices operating "unlicensed" are not concerned about potential i= nterference with other unlicensed devices. There are potentially multiple = and they generally need to play well together. Licensed devices are typica= lly a single owner to facilitate a level of service based on a more coordin= ated model. Seems like all devices are licensed from the perspective that the air-wares= are controlled and allocated. Even unlicensed or licensed exempt allocati= ons have limitations and device conformance testing. It's just that the en= d-user does not need to explicitly file for a license in these bands. As an architecture - all devices have a license, and that some just happen = to have paid money or been given a monopoly by an authority to have a singl= e user license. Some of the licenses can be short lived and need to be dis= tributed. Some are implicit based on the conformance tests that the device= must pass. The licenses that paws is addressing are ones that can be modi= fied by some form of IP communications (aka database lookup). So ... as an attempt for text .... Whitespace licensed: Operation of RF devices in a frequency band where auth= orized operation is determined based on a devices location, device type and= operating time period. Coordination of this mode of operation will typica= lly be managed by databases tracking Licensed operation in the same bands. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, January 30, 2012 2:46 PM To: Paul Lambert Cc: Nancy Bravin; Malyar, John P; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Uh, whitespace device? Sorry, couldn't resist. Brian On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote: What is the correct term for something that is operating as a license-exemp= t device - yet has been given short term authorization to share a channel w= ith other license-exempt devices based on a query to a regional authorities= database in a portion of spectrum that may also include licensed or light-= licensed devices at other times or in other areas. Paul From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gerald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FBDSCVEXCH2marve_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Uh, whitespace device?

J 

Maybe … but if we are talking about the “license= ” it might be  “Database Licensed”, “Database License-Exempt”, or  “White Space Licensed”

 

Seems like we had some really excellent definitions – = but happened to be missing the category that we are trying to support.=

 

“Unlicensed” in FCC terms also has a connotation= of multiple users and robustness.  Devices operating “unlicensed= 221; are not concerned about potential interference with other unlicensed devices.  There are potentially multiple and they generally need to pl= ay well together.  Licensed devices are typically a single owner to facilitate a level of service based on a more coordinated model.=

 

Seems like all devices are licensed from the perspective tha= t the air-wares are controlled and allocated.  Even unlicensed or licens= ed exempt allocations have limitations and device conformance testing.  I= t’s just that the end-user does not need to explicitly file for a license in th= ese bands.

 

As an architecture – all devices have a license, and t= hat some just happen to have paid money or been given a monopoly by an authorit= y to have a single user license.  Some of the licenses can be short lived a= nd need to be distributed.  Some are implicit based on the conformance te= sts that the device must pass.  The licenses that paws is addressing are o= nes that can be modified by some form of IP communications (aka database lookup= ).

 

So … as an attempt for text ….=

 

Whitespace licensed:&nbs= p;Oper= ation of RF devices in a frequency band where authorized operation is determined = based on a devices location, device type and operating time period.  Coordin= ation of this mode of operation will typically be managed by databases tracking L= icensed operation in the same bands.

 

 

Paul

 

Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141

 

From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Monday, January 30, 2012 2:46 PM
To: Paul Lambert
Cc: Nancy Bravin; Malyar, John P; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Uh, whitespace device?

 

Sorry, couldn't resist.

 

Brian

 

On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote:<= /o:p>



 

What is the correct term for something that is operating as = a license-exempt device – yet has been given short term authorization t= o share a channel with other license-exempt devices based on a query to a regional authorities database in a portion of spectrum that may also includ= e licensed or light-licensed devices at other times or in other areas.=

 

 

Paul

 

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard
Sent: Monday, Januar= y 30, 2012 3:30 PM
To: paws@ietf.org
Subject: [paws] Disc= ussion on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understanding of the terms:

 

Licensed:&nbs= p;Spec= trum that is acquired by an operator over a given service area for a given time period.  This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g.= , public service).

 

Lightly licensed:&nbs= p;Spec= ial case where thefrequency allocation is done through first-come / first-serve= d process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a servi= ce that would not normally be economically attractive.  Small local opera= tors would be interested by this (e.g., rural broadband in Canada) and not big Telcos that = would normally work with full licensing through auction over large service areas.=

 

License-exempt:<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:navy'>&nbs= p;Oper= ation of RF devices in a frequency band where no formal licensing process is need= ed such as in the 2.4 GHz ISM band. In the=  USA, this term is used for a specific type of operation. The FCC should be conta= cted to clarify it.

 

Unlicensed:&nbs= p;Ille= gal operation of an RF device that can transmit in a frequency band without a d= uly issued license.  In the USA, this term is used to mean “license-exempt," see above.

 

To my knowledge, the term “unlicensed” is used only= in the USA to describe a legal operation be= cause the term “license-exempt” has been used for another specific purpose.

 

Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recogni= zed by the ITU-R. I would suggest the use of ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the USA instead of the usual ‘license-exempt’.

 

Gerald

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

 

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

 

--_000_7BAC95F5A7E67643AAFB2C31BEE662D01567642FBDSCVEXCH2marve_-- From stephen.farrell@cs.tcd.ie Mon Jan 30 15:35:28 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E5111E80E1 for ; Mon, 30 Jan 2012 15:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS-xvS0DpsTA for ; Mon, 30 Jan 2012 15:35:27 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5378011E80D7 for ; Mon, 30 Jan 2012 15:35:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B234B153E2E; Mon, 30 Jan 2012 23:35:26 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1327966526; bh=Tz+0+3QsLDlGFH TJt0QlQP5L83QX5Dujf3kTWe0kPnQ=; b=BZgaqb0PBnzG78ovqCY/yqeirzmHQO khKQOj4OVGa05YPXNR/UBOnOjWnH1PPiptQmRijNqXdgUvqCc8G249509VRDfzlA dtIM3mntORnRZHzz+GuMMPkaTzS1I7jjvqFk2qzC2UahoAWVcS9vpdYZMyDMimzG W0foe1vtiThFCMlze0+MoS7ZYrEWMlv748En/A/SUWmJIZHaHmXkW9FI2rlm3YT6 5zFYL+QWzsc6MWZ/aMsBzQ5OD4aVrOzmwkXqnkQ5qrO2C2Cl1p621PtkZpzPvVqg WzuLQ9hp2Xxr5cMlRY8+PtenPNen7Uw7d5TgRF28Nh9BL5iqmT+pnHZA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id D5LGnDq9y7Jh; Mon, 30 Jan 2012 23:35:26 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.41.13.45]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 522AD153E2D; Mon, 30 Jan 2012 23:35:15 +0000 (GMT) Message-ID: <4F272932.5040802@cs.tcd.ie> Date: Mon, 30 Jan 2012 23:35:14 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Lambert References: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567642F92@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567642F92@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] Threats, Services and Predicatable Availability X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:35:28 -0000 Sorry to keep on on the same thing, but it doesn't seem to be resonating much;-) The charter says: "Robust privacy and security mechanisms are needed..." I'm guessing its possible an analysis starting from your suggestions below should produce a good result wrt security but maybe less so for privacy (which is less well understood by us all). How about adding "Prevent unnecessary exposure of personally identifying information (PII)" ? Note that the above could me met via encryption of PII, (with possibly high-cost key management) or by just not sending PII when you don't need to which is fairly cheap if you're not forced by regulation to send it. (Since some devices presumably are not personally identifying but others are, then maybe there's a simple enough answer in the end...) S On 01/30/2012 10:29 PM, Paul Lambert wrote: > > Hi Raj, > >> Do you have any proposals or text w.r.t the threat model writeup? Also >>from an IETF perspective regarding threat models, please see Peter's >> email: http://www.ietf.org/mail-archive/web/paws/current/msg00592.html >> >> -Raj > > I'll spend a little time formalizing the ideas I submitted below. However, "threats" are part of a complete set of requirements and looking at the current proposal, I feel we need to clarify the service that we offer before we can say what are real threats. Specifically, the threat: > >>>> device which can be used maliciously. The effect of such an >>>> attack being successful would result in a malicious client >>>> replaying the stolen authentication/authorization secrets to a >>>> white space database. > > This is not a threat as worded... but why? > > We need to define what we offer, and then things that prevent or break these offered services are potential risks that can be mapped to threats. As a start, I propose (which I hope is mostly in line with the use cases) two main services with some subtopics: > > 1) Prevent Interference of License-exempt Use with Licensed Operation > - Support changes in channel, time Period and region for licensed operation > - Support predictable availability of licensed channels > - Support the ability to disable specific vendor/model-types from operation when > they are determined to be causing interference > 2) Enable Authorized Channel Utilization for License-exempt Operation > - Facilitate fixed use of channels > - Facilitate mobile use of channels > - Facilitate indoor use of channels > - Support predictable availability of license-exempt channels > - Support changing of authorized channels to prevent interference with licensed usage > > So, threat event is something that has a result of preventing the promised services. The threat event either causes unapproved interference with licensed operation, or it prevents White Space "license-exempt" operation. > > The "Support Predictable Availability" is something new I'd like to introduce for discussion. There needs to be a expectation that once you are using a channel that your use will not be terminated abruptly in an unanticipated manner. Right now - we are creating mechanism to quickly cutoff a device for any reason at all (for the use case of mobile microphones). This is actually supposed to be a predictable event with some type of scheduling. An license-exempt devices needs to be able to determine how long it might operate under the regulations in a particular channel/region. Building a system where you never know when your communications might get cut off seems like a bad idea. > > > > Paul > > >> >> On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >> >>> It's good to have requirements based on such an analysis. This is an >>> interesting start, but we may be mixing threats, vulnerabilities and >>> mechanisms. >>> >>> Threats are typically tied to an actor ... human or not. I'm not sure >>> it's worth going hard over to something like the NIST 800-30 >> definitions >>> of threats, but within this framework the threats are Governments, >>> disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>> quickly to the threat event and specifics of an attack, but should at >>> least expand threats to include natural events and connectivity >> problems. >>> Robustness or emergency modes might be interesting to consider. >>> >>> We also have a problem in this analysis of perspective - are we >>> considering threats as viewed from regulatory agency or the end device >>> owner or both. We should consider both - but they are contradictory >>> perspectives. Users want continuity of service. Governments (the >>> regulators) want control of the airwaves. >>> >>> Most of the real threats that we have are nearly impossible to prevent >> at >>> the protocol level. It's still worth examining the threats to see >> where >>> we stand. >>> >>> On the current document threats: >>> >>>> o It is assumed that the master device or the white space database >>>> have NOT been compromised from a security standpoint. >>>> >>>> Threat 1: Obtain master device authentication/authorization secrets >>>> The master device needs to authenticate itself with the white >>>> space database prior to requesting channel information. The >>>> attacker may try to get access to the secrets of the master >>>> device which can be used maliciously. The effect of such an >>>> attack being successful would result in a malicious client >>>> replaying the stolen authentication/authorization secrets to a >>>> white space database. >>> This does not seem consistent with the prior statement of "not >>> compromised". >>> Restatement >>> >>> Threat: User modifies a device to masquerade as another valid certified >>> device. >>> >>> This is an interesting case where threat/vulnerability/risk play >>> together. The FCC or other regulatory agencies want traceability of >>> devices. If a user wants to run a rogue radio, there is no reason to >>> access the database (low risk - no payoff). The only reason this would >>> be an interesting attack might be to avoid tracking and have some >>> anonymity. >>> >>>> Threat 2: Spoofed white space database >>>> A master device discovers a white space database(s) thru which >>>> it can query for channel information. The master device needs >>>> to ensure that the white space database with which it >>>> communicates with is an authentic entity. The white space >>>> database needs to provide its identity to the master device >>>> which can confirm the validity/authenticty of the database. An >>>> attacker may attempt to spoof a white space database and >>>> provide responses to a master device which are malicious and >>>> result in the master device causing interference to the primary >>>> user of the spectrum. >>> >>> I think this is two types of threat events: >>> - malicious denial of service or intentional interference with >> incumbents >>> - impersonation of white space database to enable operation of a >> device >>> that may >>> not otherwise be possible (blocked device, unallocated channels). >>> This may or may not >>> interfere with incumbent devices >>> >>>> Threat 3: Modifying a query request >>> ... >>> >>>> Threat 4: Modifying a query response >>> Seems like these two could be lumped together ...MiTM modifies protocol >>> messages to: >>> - deny service >>> - interfere with incumbents >>> - provide unauthorized channel usage (most likely risk IMHO) >>> >>>> Threat 5: Using query response information >>>> An attacker may be a master device which is not certified for >>>> use by the relevant regulatory body. The attacker may listen to >>>> the communication between a valid master device and white space >>>> database and utilize the information about available channels >>>> in the response message by utilizing those channels. The result >>>> of such an attack is unauthorized use of channels by a master >>>> device which is not certified to operate. >>> As stated this is a mechanism - a clearer statement might be. >>> >>> Threat: Unauthorized use of channels by an uncertified device. >>> >>> Anyone can already go to a database and find available channels. If a >>> device can operate without going to the database there is nothing that >>> paws can do to stop it operating in available or non-available >> channels. >>> >>> Just to get some discussion going -here's a couple more possible >> threats.. >>> >>> Threat: Third party tracking of white space device location >>> Likely a valuable commodity to sell for advertizing with no >> technical >>> design or policy for privacy >>> Threat: Database owner termination of device service for reasons other >>> than incumbent protection >>> >>> >>> >>> Paul >>> >>> > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From Gabor.Bajko@nokia.com Mon Jan 30 15:42:47 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA011E80F0 for ; Mon, 30 Jan 2012 15:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iV9ENYWPPd+7 for ; Mon, 30 Jan 2012 15:42:46 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 07C4A11E80EC for ; Mon, 30 Jan 2012 15:42:45 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0UNgaYM019856 for ; Tue, 31 Jan 2012 01:42:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 01:42:35 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Tue, 31 Jan 2012 00:42:35 +0100 From: To: Thread-Topic: next steps for the wg -Correction Thread-Index: Aczfp59nGwfLTwcBQhC3akPV3zruqw== Date: Mon, 30 Jan 2012 23:42:34 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D9C@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.66.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2012 23:42:35.0829 (UTC) FILETIME=[D8002650:01CCDFA8] X-Nokia-AV: Clean Subject: Re: [paws] next steps for the wg -Correction X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:42:47 -0000 I believe I made a mistake in this initial mail thread, which I'd like to c= orrect: I wrote down below that a conclusion of the F2F was to delete requirement D= .8, which said: D.8: The Data Model MUST support specifying channel availability informati= on for an area around a specified location. Listening to the tape again, it doesn't seem that we discussed deleting it.= And the Mobility use case does need a requirement like this. Therefore, I'd propose the editor includes a D.8 requirement into the next = version of the draft. A more appropriate reformulation of the requirement w= ould be: D.8: The Data Model MUST support specifying channel availability informati= on for a specified contour. Is this acceptable? - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Thursday, January 12, 2012 5:27 PM To: paws@ietf.org Subject: [paws] next steps for the wg As the AD noted, the list has been inactive for the last few weeks. In this email I am trying to summarize where we are and what we need to do = next in the WG: 1. use cases: We had a long discussion about the use cases in the last f2f,= and it seems that the only use case requiring a re-write is the m2m one. J= uan-Carlos promised to revise the use case based on the comments received a= nd post the revised version to the list asap. Brian promised to contribute a use case on mesh-networking, as that seems t= o be different from the m2m one. With the revision of the m2m and addition of the mesh-networking one, the u= se case part should be complete. 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with = D.6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.= pdf also contain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdf and slide 9 of http://www.ietf.org/p= roceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = of http://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agr= ee on the format the location would be represented in. The data format part= is still open, but as this piece does not really belong to requirements bu= t rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete P.2 currently says: The protocol MUST support regulatory domain discovery. We need to discuss this further on the list, to come up with a better formu= lated requirement. The minutes captured: Implies transmitter first queries the DB to find out the regulatory domain = before it queries for the available channel list need to spend time figurin= g out an implementable requirement. Related to sending "rules" for a domai= n put it as a suggestion rather than requirement. Current regulations envi= sion tight coupling between certified devices and owners. need to document the coupling between regulatory domain, database, requirem= ents. Suggestions for P.2 expected to the list. P.3 currently says: The protocol between the master device and the WS Data= base MUST support pushing updates in channel availability changes to subj= ects. There were comments that this requirement involves a mechanism, we should r= eformulate to be mechanism agnostic. There was a suggestion to "make the requirement "quick way to change availa= bility" rather than imply a mechanism.". The use case is that if the channel availability changes in the DB, the cli= ent has to be able to detect it and get the new availability list within a = time period set by the regulator. Can someone send suggested text on how to reformulate this requirement? We had no time to go through these requirements, so I am asking here on the= list to please comment on them: P.4: The protocol between the master device and the WS Database MUST support mutual authentication and authorization. P.5: The protocol between the master device and the WS Database MUST support integrity and confidentiality protection. P.6: The protocol MUST support both username/password and digital certificates based authentication. P.12: A master device MUST be capable of validating the digital certificate of the WS Database. P.13: A master device MUST be capable of checking the validity of the WS Database certificate and whether it has been revoked or not. Note, P.13 requires support for OCSP (RFC2560) in the client, I am not sure= if that is needed, please send your opinions. The wording of P.11 has to be enhanced to match the description of the revi= sed D.1 We did not have any discussion on P.9, so I'd like to get comments on the l= ist about this: P.9: A master device MUST be able to query the whitespace database for channel availability information for a specific expected coverage area around its current location. Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. I ask the editor to implement the changes above and post a revised version = asap, so we can have further reviews on it. We also have a protocol framework document available at http://www.ietf.org= /id/draft-das-paws-protocol-00.txt We did have a brief discussion on it, the author promised to update it to c= apture the received comments and post a new version in the next few weeks. = If you have additional comments, please send those to the list, so the auth= or can address them. We also have a proposal available on the data model structure, available at= http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt It was presented in the last f2f, but there was no time for comments. Pleas= e send your comments on this document to the list too. - Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From gerald.chouinard@sympatico.ca Mon Jan 30 16:13:07 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185EB11E80D9 for ; Mon, 30 Jan 2012 16:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.082 X-Spam-Level: * X-Spam-Status: No, score=1.082 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_40=-0.185, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn-wcwnB4ZtB for ; Mon, 30 Jan 2012 16:13:04 -0800 (PST) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by ietfa.amsl.com (Postfix) with ESMTP id 9634521F858D for ; Mon, 30 Jan 2012 16:13:04 -0800 (PST) Received: from BLU0-SMTP39 ([65.55.116.72]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:13:04 -0800 X-Originating-IP: [174.95.247.44] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.247.44]) by BLU0-SMTP39.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 16:13:03 -0800 From: Gerald Chouinard To: , References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 30 Jan 2012 19:13:02 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01CCDF83.311BFF50" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aczfje4hBqIvPtzVQA6ucq3r2yBLaQAEUHYgAAELzFA= In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23@008-AM1MPN1-006.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 31 Jan 2012 00:13:03.0328 (UTC) FILETIME=[19465E00:01CCDFAD] Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 00:13:07 -0000 ------=_NextPart_000_0078_01CCDF83.311BFF50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Gabor, I agree with your proposal. This seems to be reasonable. However one needs to be careful with the word 'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald ------=_NextPart_000_0078_01CCDF83.311BFF50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gabor,

 

I agree with your proposal.  = This seems to be reasonable.  However one needs to be careful with the = word ‘unlicensed’ which may mean ‘illegal’ operation of an RF device in many administrations.

 

Gerald

 

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, = 2012 17:49
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: RE: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

These look = to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as ‘license-exempt’, in most cases the = term ‘unlicensed-band’ is used.

 <= /o:p>

Therefore, = may I suggest that the draft will include the following = statement:

 <= /o:p>

The terms = unlicensed and license-exempt spectrum are used in this document interchangeably = and refer to a spectrum in which no formal licensing process is needed for RF = devices to operate in, such as the ISM band.

 <= /o:p>

-          Gabor

 <= /o:p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, = 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understanding of the = terms:

 

= Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

= Lightly licensed: Special case = where thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. The annual = license fee is usually small to facilitate the deployment of a service that would = not normally be economically attractive.  Small local operators would = be interested by this (e.g., rural broadband in Canada) and not big Telcos = that would normally work with full licensing through auction over large = service areas.

 

= License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the = USA, = this term is used for a specific type of operation. The FCC should be contacted to clarify it.

 

= Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to = mean “license-exempt," see above.

 

To my knowledge, the term “unlicensed” is used only in the USA to describe a legal = operation because the term “license-exempt” has been used for another specific purpose.

 

Since the PAWS addresses the = interface to the database for the international market, it should rely on the = definition of the terms recognized by the ITU-R. I would suggest the use of ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the = USA = instead of the usual ‘license-exempt’.

 

Gerald

------=_NextPart_000_0078_01CCDF83.311BFF50-- From paul@marvell.com Mon Jan 30 18:37:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5D121F851E for ; Mon, 30 Jan 2012 18:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcD4pbwwJ5PT for ; Mon, 30 Jan 2012 18:37:00 -0800 (PST) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9618F21F851C for ; Mon, 30 Jan 2012 18:36:59 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKTydTxfCFj/TRKq7rv1YtYf71d1Uaw5H1@postini.com; Mon, 30 Jan 2012 18:36:59 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 30 Jan 2012 18:36:00 -0800 From: Paul Lambert To: Stephen Farrell Date: Mon, 30 Jan 2012 18:35:59 -0800 Thread-Topic: [paws] Threats, Services and Predicatable Availability Thread-Index: Aczfp9nmQhS/QzK5S1GYIKp0Vp743QAF0+eA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567643057@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567642F92@SC-VEXCH2.marvell.com> <4F272932.5040802@cs.tcd.ie> In-Reply-To: <4F272932.5040802@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threats, Services and Predicatable Availability X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 02:37:01 -0000 >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] ... >Sorry to keep on on the same thing, but it doesn't seem >to be resonating much;-) > >The charter says: "Robust privacy and security mechanisms >are needed..." > >I'm guessing its possible an analysis starting from your >suggestions below should produce a good result wrt security >but maybe less so for privacy (which is less well >understood by us all). > >How about adding "Prevent unnecessary exposure of >personally identifying information (PII)" ? Excellent idea. As you state it, this works for both database and user dev= ices. =20 > >Note that the above could me met via encryption of >PII, (with possibly high-cost key management) or by >just not sending PII when you don't need to which is >fairly cheap if you're not forced by regulation to >send it. (Since some devices presumably are not >personally identifying but others are, then maybe >there's a simple enough answer in the end...) Seems like a encrypted tunnel (TLS, IPsec, etc) would prevent MiTM viewing = of PII. - don't send PII - encrypt/mask PII - encrypt message end-to-end between ... hum, is a master a potential adve= rsary? maybe I see where you were going with the field encryption Master-to-DB TLS/IPSec whatever is adequate Client-through-Master-to-DB is a little more difficult to ensure PII pri= vacy Database use and of PII is a difficult topic. Not sure if we should facili= tate users authorization or controlled release of their information. The P= AWS protocol could perhaps have bits that express a requested policy (discl= ose or not). Enforcement would be left to trusting the DB to do the right = thing with the request. Paul > >S > >On 01/30/2012 10:29 PM, Paul Lambert wrote: >> >> Hi Raj, >> >>> Do you have any proposals or text w.r.t the threat model writeup? >Also >>>from an IETF perspective regarding threat models, please see Peter's >>> email: http://www.ietf.org/mail- >archive/web/paws/current/msg00592.html >>> >>> -Raj >> >> I'll spend a little time formalizing the ideas I submitted below. >However, "threats" are part of a complete set of requirements and >looking at the current proposal, I feel we need to clarify the service >that we offer before we can say what are real threats. Specifically, >the threat: >> >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets to >a >>>>> white space database. >> >> This is not a threat as worded... but why? >> >> We need to define what we offer, and then things that prevent or break >these offered services are potential risks that can be mapped to >threats. As a start, I propose (which I hope is mostly in line with the >use cases) two main services with some subtopics: >> >> 1) Prevent Interference of License-exempt Use with Licensed Operation > >> - Support changes in channel, time Period and region for licensed >operation >> - Support predictable availability of licensed channels >> - Support the ability to disable specific vendor/model-types from >operation when >> they are determined to be causing interference >> 2) Enable Authorized Channel Utilization for License-exempt Operation > >> - Facilitate fixed use of channels >> - Facilitate mobile use of channels >> - Facilitate indoor use of channels >> - Support predictable availability of license-exempt channels >> - Support changing of authorized channels to prevent interference >with licensed usage >> >> So, threat event is something that has a result of preventing the >promised services. The threat event either causes unapproved >interference with licensed operation, or it prevents White Space >"license-exempt" operation. >> >> The "Support Predictable Availability" is something new I'd like to >introduce for discussion. There needs to be a expectation that once you >are using a channel that your use will not be terminated abruptly in an >unanticipated manner. Right now - we are creating mechanism to quickly >cutoff a device for any reason at all (for the use case of mobile >microphones). This is actually supposed to be a predictable event with >some type of scheduling. An license-exempt devices needs to be able to >determine how long it might operate under the regulations in a >particular channel/region. Building a system where you never know when >your communications might get cut off seems like a bad idea. >> >> >> >> Paul >> >> >>> >>> On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >>> >>>> It's good to have requirements based on such an analysis. This is >an >>>> interesting start, but we may be mixing threats, vulnerabilities and >>>> mechanisms. >>>> >>>> Threats are typically tied to an actor ... human or not. I'm not >sure >>>> it's worth going hard over to something like the NIST 800-30 >>> definitions >>>> of threats, but within this framework the threats are Governments, >>>> disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>>> quickly to the threat event and specifics of an attack, but should >at >>>> least expand threats to include natural events and connectivity >>> problems. >>>> Robustness or emergency modes might be interesting to consider. >>>> >>>> We also have a problem in this analysis of perspective - are we >>>> considering threats as viewed from regulatory agency or the end >device >>>> owner or both. We should consider both - but they are contradictory >>>> perspectives. Users want continuity of service. Governments (the >>>> regulators) want control of the airwaves. >>>> >>>> Most of the real threats that we have are nearly impossible to >prevent >>> at >>>> the protocol level. It's still worth examining the threats to see >>> where >>>> we stand. >>>> >>>> On the current document threats: >>>> >>>>> o It is assumed that the master device or the white space database >>>>> have NOT been compromised from a security standpoint. >>>>> >>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>> The master device needs to authenticate itself with the >white >>>>> space database prior to requesting channel information. The >>>>> attacker may try to get access to the secrets of the master >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets to >a >>>>> white space database. >>>> This does not seem consistent with the prior statement of "not >>>> compromised". >>>> Restatement >>>> >>>> Threat: User modifies a device to masquerade as another valid >certified >>>> device. >>>> >>>> This is an interesting case where threat/vulnerability/risk play >>>> together. The FCC or other regulatory agencies want traceability of >>>> devices. If a user wants to run a rogue radio, there is no reason >to >>>> access the database (low risk - no payoff). The only reason this >would >>>> be an interesting attack might be to avoid tracking and have some >>>> anonymity. >>>> >>>>> Threat 2: Spoofed white space database >>>>> A master device discovers a white space database(s) thru >which >>>>> it can query for channel information. The master device >needs >>>>> to ensure that the white space database with which it >>>>> communicates with is an authentic entity. The white space >>>>> database needs to provide its identity to the master device >>>>> which can confirm the validity/authenticty of the database. >An >>>>> attacker may attempt to spoof a white space database and >>>>> provide responses to a master device which are malicious and >>>>> result in the master device causing interference to the >primary >>>>> user of the spectrum. >>>> >>>> I think this is two types of threat events: >>>> - malicious denial of service or intentional interference with >>> incumbents >>>> - impersonation of white space database to enable operation of a >>> device >>>> that may >>>> not otherwise be possible (blocked device, unallocated channels). >>>> This may or may not >>>> interfere with incumbent devices >>>> >>>>> Threat 3: Modifying a query request >>>> ... >>>> >>>>> Threat 4: Modifying a query response >>>> Seems like these two could be lumped together ...MiTM modifies >protocol >>>> messages to: >>>> - deny service >>>> - interfere with incumbents >>>> - provide unauthorized channel usage (most likely risk IMHO) >>>> >>>>> Threat 5: Using query response information >>>>> An attacker may be a master device which is not certified >for >>>>> use by the relevant regulatory body. The attacker may listen >to >>>>> the communication between a valid master device and white >space >>>>> database and utilize the information about available >channels >>>>> in the response message by utilizing those channels. The >result >>>>> of such an attack is unauthorized use of channels by a >master >>>>> device which is not certified to operate. >>>> As stated this is a mechanism - a clearer statement might be. >>>> >>>> Threat: Unauthorized use of channels by an uncertified device. >>>> >>>> Anyone can already go to a database and find available channels. If >a >>>> device can operate without going to the database there is nothing >that >>>> paws can do to stop it operating in available or non-available >>> channels. >>>> >>>> Just to get some discussion going -here's a couple more possible >>> threats.. >>>> >>>> Threat: Third party tracking of white space device location >>>> Likely a valuable commodity to sell for advertizing with no >>> technical >>>> design or policy for privacy >>>> Threat: Database owner termination of device service for reasons >other >>>> than incumbent protection >>>> >>>> >>>> >>>> Paul >>>> >>>> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From nbravin@earthlink.net Tue Jan 31 03:32:50 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F095521F867B for ; Tue, 31 Jan 2012 03:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6bkgqEXu6Xw for ; Tue, 31 Jan 2012 03:32:50 -0800 (PST) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8380921F8665 for ; Tue, 31 Jan 2012 03:32:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=UgqPP3oW6DNy9riOaePl8HhyrSOFj4LW0DZcSHfynVvuNgRrln1s9mKK29KYbvd1; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RsBx4-0002Xm-Ro; Tue, 31 Jan 2012 06:32:43 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--337472848 From: Nancy Bravin In-Reply-To: Date: Tue, 31 Jan 2012 03:32:41 -0800 Message-Id: <383940EA-33FB-4FC0-AEE4-03E34C779289@earthlink.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23@008-AM1MPN1-006.mgdnok.nokia.com> To: Gerald Chouinard X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad866fbe9069127ed3c0d5b3d76c4601296f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:32:51 -0000 --Apple-Mail-1--337472848 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Gabor and Gerald,=20 Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 How to get around the fact that some Countries are or will be "licensed = only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: > Gabor, > =20 > I agree with your proposal. This seems to be reasonable. However one = needs to be careful with the word =91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. > =20 > Gerald > =20 > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 > Sent: Monday, 30 January, 2012 17:49 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. > =20 > Therefore, may I suggest that the draft will include the following = statement: > =20 > The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: Monday, January 30, 2012 12:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos that would = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail-1--337472848 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Gabor = and Gerald, 
Since we are dealing on a global basis, can there = a footnote to "unlicensed" we can use to indicate that "according to = each countries regulatory requirements"  
How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks
Nancy
On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:

Gabor,

 

I agree with your proposal.  = This seems to be reasonable.  However one needs to be careful with the = word =91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 

Gerald

 

From: Gabor.Bajko@nokia.com = [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, = 2012 17:49
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: RE: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

These look = to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.

 

Therefore, = may I suggest that the draft will include the following = statement:

 

The terms = unlicensed and license-exempt spectrum are used in this document interchangeably = and refer to a spectrum in which no formal licensing process is needed for RF = devices to operate in, such as the ISM band.

 

-          Gabor

 

From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, = 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understanding of the = terms:

 

L= icensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

L= ightly licensed: Special case = where thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. The annual = license fee is usually small to facilitate the deployment of a service that would = not normally be economically attractive.  Small local operators would = be interested by this (e.g., rural broadband in Canada) and not big Telcos = that would normally work with full licensing through auction over large = service areas.

 

L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it.

 

U= nlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, = this term is used to mean =93license-exempt," see above.

 

To my knowledge, the term =93unlicensed=94 is used only in the USA = to describe a legal operation because the term =93license-exempt=94 has been used for another specific purpose.

 

Since the PAWS addresses the = interface to the database for the international market, it should rely on the = definition of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the = USA instead of the usual =91license-exempt=92.

 

Gerald

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

= --Apple-Mail-1--337472848-- From gerald.chouinard@sympatico.ca Tue Jan 31 07:07:39 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4CD21F84BD for ; Tue, 31 Jan 2012 07:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_20=-0.74, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL95P9USJ-OT for ; Tue, 31 Jan 2012 07:07:35 -0800 (PST) Received: from blu0-omc3-s34.blu0.hotmail.com (blu0-omc3-s34.blu0.hotmail.com [65.55.116.109]) by ietfa.amsl.com (Postfix) with ESMTP id 4E95221F84F7 for ; Tue, 31 Jan 2012 07:07:35 -0800 (PST) Received: from BLU0-SMTP79 ([65.55.116.74]) by blu0-omc3-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 07:07:34 -0800 X-Originating-IP: [174.95.243.143] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.143]) by BLU0-SMTP79.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 07:07:31 -0800 From: Gerald Chouinard To: "'Nancy Bravin'" References: <1ECAFF543A2FED4EA2BEB6CACE08E47601DE4D23@008-AM1MPN1-006.mgdnok.nokia.com> <383940EA-33FB-4FC0-AEE4-03E34C779289@earthlink.net> Date: Tue, 31 Jan 2012 10:07:30 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01CCE000.2604C390" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AczgDBX8CJSeV7RpSCufxRXBCsvuXwAGaeLA In-Reply-To: <383940EA-33FB-4FC0-AEE4-03E34C779289@earthlink.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 31 Jan 2012 15:07:31.0730 (UTC) FILETIME=[0E229F20:01CCE02A] Cc: paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 15:07:39 -0000 ------=_NextPart_000_009B_01CCE000.2604C390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can then decide under what king of regime it will 'assign' this band for operation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt" such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. This seems to be reasonable. However one needs to be careful with the word 'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_009B_01CCE000.2604C390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy,

 

This is not that simple.  In = fact, the qualifiers “license-exempt” and “unlicensed” = can apply to more than one thing.

 

If the qualifier applies to a = frequency band, different options exist. As an example, in the ITU-R context, an = “unlicensed” band is typically a new band, say in the 300 GHz, for which no request = has been made for its use.  It is therefore un-allocated to a specific = service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this band to one or = many services on a primary or secondary basis, then the administrations can = then decide under what king of regime it will ‘assign’ this band = for operation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow = operation with an exemption of licenses, thus = “license-exempt” such as in the 2.4 GHz ISM band. This is also called = “unlicensed” in the USA.

 

If the qualifier applies to an = operation, the operation can be exempt of license by the local administration, thus = a “license-exempt” = operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which he = does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the = technical limits imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an “unlicensed” = operation.

 

If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license = or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone smuggles a = device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id = de-facto an “unlicensed” device since it has not passed through the normal certification = process.

 

Note that a = “license-exempt” device still has to go through a certification process and meet the = limits imposed by the local regulator for the “license-exempt” = operation in the given frequency band whereas an “unlicensed” device = may not pass the certification process since it has not been licensed to = operation in the country.

 

This is why the qualifier = “unlicensed” has to be treated with care and the footnote will need to be crafted = very carefully.

 

With respect to your second point, = if an administration only allows “licensed” operation, the = situation will be much simpler to manage since specific conditions will be attached to = these licenses.

 

Gerald

 

From: Nancy = Bravin [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 = January, 2012 06:33
To: Gerald Chouinard
Cc: = Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and Gerald, 

Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to = each countries regulatory requirements" =  

How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? =  Thanks

Nancy

On Jan 30, 2012, at 4:13 PM, Gerald Chouinard = wrote:



Gabor,

 

I agree with your proposal.  = This seems to be reasonable.  However one needs to be careful with the = word ‘unlicensed’ which may mean ‘illegal’ operation = of an RF device in many = administrations.

 

Gerald

 

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, = 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] = Discussion on 'license-exempt' vs = 'unlicensed'

 

These look = to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as ‘license-exempt’, in most cases the = term ‘unlicensed-band’ is used. =

 =

Therefore, = may I suggest that the draft will include the following = statement:

 =

The terms = unlicensed and license-exempt spectrum are used in this document interchangeably = and refer to a spectrum in which no formal licensing process is needed for RF = devices to operate in, such as the ISM = band.

 =

-          Gabor<= /u1:p>

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, = 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] = Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

Here is my understanding of the = terms:

 

= Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

= Lightly licensed: Special case = where thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. The annual = license fee is usually small to facilitate the deployment of a service that would = not normally be economically attractive.  Small local operators would = be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through = auction over large service areas.

 

= License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

 

= Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

 

To my knowledge, the term “unlicensed” is used only in the USA to describe a legal operation because the term = “license-exempt” has been used for another specific = purpose.

 

Since the PAWS addresses the = interface to the database for the international market, it should rely on the = definition of the terms recognized by the ITU-R. I would suggest the use of ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the = USA instead of the usual = ‘license-exempt’.

 

Gerald

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

 

------=_NextPart_000_009B_01CCE000.2604C390-- From mksaji@yahoo.com Tue Jan 31 08:12:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3138F21F848F for ; Tue, 31 Jan 2012 08:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.655 X-Spam-Level: *** X-Spam-Status: No, score=3.655 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, REPTO_QUOTE_YAHOO=2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbh+Tm18dkOc for ; Tue, 31 Jan 2012 08:12:20 -0800 (PST) Received: from nm7-vm0.bullet.mail.ne1.yahoo.com (nm7-vm0.bullet.mail.ne1.yahoo.com [98.138.91.66]) by ietfa.amsl.com (Postfix) with SMTP id 9DAD921F8484 for ; Tue, 31 Jan 2012 08:12:19 -0800 (PST) Received: from [98.138.90.52] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 16:12:16 -0000 Received: from [98.138.87.1] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 16:12:16 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 16:12:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 422699.73681.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 6919 invoked by uid 60001); 31 Jan 2012 16:12:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1328026335; bh=LIpZsLQby8wM+xNHMxduIAVYaH0rGrFWSj1VQQ3mjmg=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LBe1jZvO2ekPcR5TXrXNpGo4IsfeU0Pgb1dK0V8CbXHeD+D0z3UV97g5PPZ347BLQKo33RZzIKJvNcg6H+8BNZAntSrJOE7H8GpX7L6pl9ekseDdsV+GJB7ITjOBoLfQi2FTJw4z1txh2uCFbjLKrAksSlouB9Yfm2D5SZG9P0k= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=R7115JWWzUHQ4tIF8W6sHdcE7D/GSyAdH/7w27Bkp/u5blA957ZsR/7uo4HBLUugE8FZWtTWV5mCr15qPVMw8ssXldKfi/TLziv5OeADBOZQpoY0pWrXvuDX7F/zxkZFaTPDKgAgKVBjM2wXaKBJ/RYo8WZcTMQ18/6KgKbvBwo=; X-YMail-OSG: 0KuQLvoVM1nOmgJaI7Y3W_RkY814nurB3V5PfPAl_DuZRyw 7y6gl45Yp2trGvmpPxcpDn2DAMgWyC_pzS1nlLvrHlHiRV_JvfcbRstBGgtL srngc.tXZ_Pv9eeZrnJS2gWZ2FpoclphM7rim4af_1LWoPLEkIieG2fCaqls uE7PJGRFboUTU0hI1TZtl_4EvV.nmY4nJL4o0wEGpMJw_yWBX3bfGDOXUiyn PZyCMQrcEhqc4K5840Ox9LEkl62.TxQEVMbDhRi7MZ_laeqiJRoI7AQisbyT V2epgkJ724SDbnLLYnJaZuLHDAmJHs4RYAoTxXIagY_qE_XCq8GCI.QBGs6P cdXuEb9ivkNFdMHiPSyC4Yy.2Z9sSR7ysFsDYiKYprV5tobqSdBgEUq.NUmg _sv7xlO8SsPizqcCvITjBMcYIbJ1yRjOKdIjCBp8yjieJAVvQD38fm0WC4wo IX9NDIeYHEhOkFeltZ4S7gR1qXbv91EBSQvSajMY.hgYMMNXeZpfPHZYtWWa i0nxu57bpxQZJPEFDx1sfh.EFTT0IjbGLc2VfPv0frw-- Received: from [49.249.136.127] by web36703.mail.mud.yahoo.com via HTTP; Tue, 31 Jan 2012 08:12:15 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> <32E7EA09-A091-4FE5-B3A1-85F249D3520E@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FBD@SC-VEXCH2.marvell.com> Message-ID: <1328026335.6265.YahooMailNeo@web36703.mail.mud.yahoo.com> Date: Tue, 31 Jan 2012 08:12:15 -0800 (PST) From: "M.K.Sajeev" To: Paul Lambert , "Rosen, Brian" , "paws@ietf.org" In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567642FBD@SC-VEXCH2.marvell.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2114655128-1150249085-1328026335=:6265" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "M.K.Sajeev" List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 16:12:21 -0000 ---2114655128-1150249085-1328026335=:6265 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0A=0AA bit confused seeing the 'unlicensed' band discussion here. Will = a white space database be maintaining details of devices/channel allocation= s of unlicensed band operation of devices? (is it really feasible, as unlic= ensed band can be used by any device without any specific channels allocati= on, etc....) Or will the databases limit their operation to just the =C2=A0= licensed/lightly licensed band operations? Or is it just that we are only d= efining these terms here.=0A=C2=A0=0ABest Regards,=0A=0ASajeev Manikkoth=0A= Mobile: +919663311378=0AEmail: mksaji@ieee.org=0Ahttp://www.linkedin.com/in= /mksajeev=0A=0A=0A=0A=0A________________________________=0A From: Paul Lamb= ert =0ATo: "Rosen, Brian" ; "paw= s@ietf.org" =0ASent: Tuesday, 31 January 2012, 4:47=0ASubje= ct: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'=0A =0A=0A = =0A> Uh, whitespace device?=0AJ=C2=A0 =0AMaybe =E2=80=A6 but if we are talk= ing about the =E2=80=9Clicense=E2=80=9D=0Ait might be =C2=A0=E2=80=9CDataba= se Licensed=E2=80=9D, =E2=80=9CDatabase=0ALicense-Exempt=E2=80=9D, or =C2= =A0=E2=80=9CWhite Space Licensed=E2=80=9D=0A=C2=A0=0ASeems like we had some= really excellent definitions =E2=80=93 but happened=0Ato be missing the ca= tegory that we are trying to support.=0A=C2=A0=0A=E2=80=9CUnlicensed=E2=80= =9D in FCC terms also has a connotation of=0Amultiple users and robustness.= =C2=A0 Devices operating =E2=80=9Cunlicensed=E2=80=9D=0Aare not concerned a= bout potential interference with other unlicensed=0Adevices.=C2=A0 There ar= e potentially multiple and they generally need to play=0Awell together.=C2= =A0 Licensed devices are typically a single owner to=0Afacilitate a level o= f service based on a more coordinated model.=0A=C2=A0=0ASeems like all devi= ces are licensed from the perspective that=0Athe air-wares are controlled a= nd allocated.=C2=A0 Even unlicensed or licensed=0Aexempt allocations have l= imitations and device conformance testing.=C2=A0 It=E2=80=99s=0Ajust that t= he end-user does not need to explicitly file for a license in these=0Abands= .=0A=C2=A0=0AAs an architecture =E2=80=93 all devices have a license, and t= hat=0Asome just happen to have paid money or been given a monopoly by an au= thority to=0Ahave a single user license.=C2=A0 Some of the licenses can be = short lived and=0Aneed to be distributed.=C2=A0 Some are implicit based on = the conformance tests=0Athat the device must pass.=C2=A0 The licenses that = paws is addressing are ones=0Athat can be modified by some form of IP commu= nications (aka database lookup).=0A=C2=A0=0ASo =E2=80=A6 as an attempt for = text =E2=80=A6.=0A=C2=A0=0AWhitespace licensed:=C2=A0Operation=0Aof RF devi= ces in a frequency band where authorized operation is determined based=0Aon= a devices location, device type and operating time period.=C2=A0 Coordinat= ion=0Aof this mode of operation will typically be managed by databases trac= king Licensed=0Aoperation in the same bands.=0A=C2=A0=0A=C2=A0=0APaul=0A=C2= =A0=0APaul A. Lambert | Marvell Semiconductor | +1-650-787-9141=0A=C2=A0=0A= From:Rosen, Brian=0A[mailto:Brian.Rosen@neustar.biz] =0ASent: Monday, Janua= ry 30, 2012 2:46 PM=0ATo: Paul Lambert=0ACc: Nancy Bravin; Malyar, John P; = paws@ietf.org=0ASubject: Re: [paws] Discussion on 'license-exempt' vs 'unli= censed'=0A=C2=A0=0AUh, whitespace device?=0A=C2=A0=0ASorry, couldn't resist= .=0A=C2=A0=0ABrian=0A=C2=A0=0AOn Jan 30, 2012, at 5:44 PM, Paul Lambert wro= te:=0A=0A=0A=C2=A0=0AWhat is the correct term for something that is operati= ng as a=0Alicense-exempt device =E2=80=93 yet has been given short term aut= horization to=0Ashare a channel with other license-exempt devices based on = a query to a=0Aregional authorities database in a portion of spectrum that = may also include=0Alicensed or light-licensed devices at other times or in = other areas.=0A=C2=A0=0A=C2=A0=0APaul=0A=C2=A0=0A=C2=A0=0A=C2=A0=0AFrom:=C2= =A0paws-bounces@ietf.org=C2=A0[mailto:paws-bounces@ietf.org]=C2=A0On Behalf= Of=C2=A0Gerald Chouinard=0ASent:=C2=A0Monday, January 30,=0A2012 3:30 PM= =0ATo:=C2=A0paws@ietf.org=0ASubject:=C2=A0[paws] Discussion=0Aon 'license-e= xempt' vs 'unlicensed'=0A=C2=A0=0AAll,=0A=C2=A0=0AHere is my understanding = of the terms:=0A=C2=A0=0ALicensed:=C2=A0Spectrum=0Athat is acquired by an o= perator over a given service area for a given time=0Aperiod. =C2=A0This is = usually done through auctions (think of the Telcos),=0Abeauty contest, firs= t-come / first-served or by government allocation (e.g.,=0Apublic service).= =0A=C2=A0=0ALightly licensed:=C2=A0Special=0Acase where thefrequency alloca= tion is done through first-come / first-served=0Aprocess for a given time f= rame over a relatively limited service area. The=0Aannual license fee is us= ually small to facilitate the deployment of a service=0Athat would not norm= ally be economically attractive. =C2=A0Small local operators=0Awould be int= erested by this (e.g., rural broadband in=C2=A0Canada) and not big Telcos t= hat would=0Anormally work with full licensing through auction over large se= rvice areas.=0A=C2=A0=0ALicense-exempt:=C2=A0Operation=0Aof RF devices in a= frequency band where no formal licensing process is needed=0Asuch as in th= e 2.4 GHz ISM band. In the=C2=A0USA,=0Athis term is used for a specific typ= e of operation. The FCC should be contacted=0Ato clarify it.=0A=C2=A0=0AUnl= icensed:=C2=A0Illegal=0Aoperation of an RF device that can transmit in a fr= equency band without a duly=0Aissued license. =C2=A0In the=C2=A0USA,=0Athis= term is used to mean =E2=80=9Clicense-exempt," see above.=0A=C2=A0=0ATo my= knowledge, the term =E2=80=9Cunlicensed=E2=80=9D is used only in=0Athe=C2= =A0USA=C2=A0to describe a legal operation because=0Athe term =E2=80=9Clicen= se-exempt=E2=80=9D has been used for another specific=0Apurpose.=0A=C2=A0= =0ASince the PAWS addresses the interface to the database for the=0Ainterna= tional market, it should rely on the definition of the terms recognized=0Ab= y the ITU-R. I would suggest the use of =E2=80=98licensed=E2=80=99 and=0A= =E2=80=98license-exempt=E2=80=99 with a footnote indicating that the term= =0A=E2=80=98unlicensed=E2=80=99 is used in the USA instead of the usual=0A= =E2=80=98license-exempt=E2=80=99.=0A=C2=A0=0AGerald=0A_____________________= __________________________=0Apaws mailing list=0Apaws@ietf.org=0Ahttps://ww= w.ietf.org/mailman/listinfo/paws=0A=C2=A0=0A_______________________________= ________________=0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org= /mailman/listinfo/paws=0A=C2=A0=0A_________________________________________= ______=0Apaws mailing list=0Apaws@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/paws ---2114655128-1150249085-1328026335=:6265 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,=

A bit confused seeing the 'unl= icensed' band discussion here. Will a white space database be maintaining d= etails of devices/channel allocations of unlicensed band operation of devic= es? (is it really feasible, as unlicensed band can be used by any device wi= thout any specific channels allocation, etc....) Or will the databases limi= t their operation to just the  licensed/lightly licensed band operatio= ns? Or is it just that we are only defining these terms here.
<= div> 
= Best Regards,

Sajeev Manikkoth
Mobile: +919663311378
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev


=
From: Paul Lambert <paul@marvell.com>
<= span style=3D"font-weight: bold;">To: "Rosen, Brian" <Brian.R= osen@neustar.biz>; "paws@ietf.org" <paws@ietf.org>
Sent: Tuesday, 31 January 2012, 4:47=
Subject: Re: [paws] D= iscussion on 'license-exempt' vs 'unlicensed'

=0A=0A=0A =0A =0A=0A
> Uh, whitespace de= vice?
J 
Maybe =85 but if we are talki= ng about the =93license=94 it might be  =93Database Licensed=94, =93Da= tabase License-Exempt=94, or  =93White Space Licensed=94
 
Seems like we had some really= excellent definitions =96 but happened to be missing the category that we = are trying to support.
 
=93Unlicensed=94 in FCC terms= also has a connotation of multiple users and robustness.  Devices ope= rating =93unlicensed=94 are not concerned about potential interference with other unlicensed devices.  There are potentially mu= ltiple and they generally need to play well together.  Licensed device= s are typically a single owner to facilitate a level of service based on a = more coordinated model.
 
Seems like all devices are li= censed from the perspective that the air-wares are controlled and allocated= .  Even unlicensed or licensed exempt allocations have limitations and device conformance testing.  It=92s = just that the end-user does not need to explicitly file for a license in th= ese bands.
 
As an architecture =96 all de= vices have a license, and that some just happen to have paid money or been = given a monopoly by an authority to have a single user license.  Some of the licenses can be short lived and n= eed to be distributed.  Some are implicit based on the conformance tes= ts that the device must pass.  The licenses that paws is addressing ar= e ones that can be modified by some form of IP communications (aka database lookup).
 
So =85 as an attempt for text= =85.
 
Whitespace licensed: Operation of RF devices in a frequency band where authorized operation is determined= based on a devices location, device type and operating time period.  = Coordination of this mode of operation will typically be managed by databas= es tracking Licensed operation in the same bands.
 
 
Paul
 
Paul A. Lambert | Marvell S= emiconductor | +1-650-787-9141
 
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Monday, January 30, 2012 2:46 PM
To: Paul Lambert
Cc: Nancy Bravin; Malyar, John P; p= aws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'
 
Uh, whitespace device?
 
Sorry, couldn't resist.
 
Brian
 
On Jan 30, 2012, at 5:44 PM, Paul Lamb= ert wrote:


 
What is the correct term for = something that is operating as a license-exempt device =96 yet has been giv= en short term authorization to share a channel with other license-exempt devices based on a query to a regional a= uthorities database in a portion of spectrum that may also include licensed= or light-licensed devices at other times or in other areas.
 
 
Paul
 
 
 
From:&= nbsp;paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard
Sent: = Monday, January 30, 2012 3:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'
 
All,
 
Here is my understanding of the terms:
 
Licensed: Spectrum that is acquired by an operator over a given service area for a given time= period.  This is usually done through auctions (think of the Telcos),= beauty contest, first-come / first-served or by government allocation (e.g= ., public service).
 
Lightly licensed: Special case where thefrequency allocation is done through first-come / first-serv= ed process for a given time frame over a relatively limited service area. T= he annual license fee is usually small to facilitate the deployment of a se= rvice that would not normally be economically attractive.  Small local operators would be interested b= y this (e.g., rural broadband in Canada) and not big Telcos that wouldnormally work with= full licensing through auction over large service areas.
 
License-exempt: Operation of RF devices in a frequency band where no formal licensing process is nee= ded such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type o= f operation. The FCC should be contacted to clarify it.
 
Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a = duly issued license.  In the USA, this term is used to mean =93license-exempt,"= ; see above.
 
To my knowledge, the term =93unlicensed= =94 is used only in the&n= bsp;USA to describe a legal operation because the term =93license-exempt=94 has been = used for another specific purpose.
 
Since the PAWS addresses the interface to= the database for the international market, it should rely on the definitio= n of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 with a = footnote indicating that the term =91unlicensed=92 is used in the USA inste= ad of the usual =91license-exempt=92.
 
Gerald
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws
 

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


_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB4D779118A73basavarajpatilnokiacom_-- From gerald.chouinard@sympatico.ca Tue Jan 31 10:16:05 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AC11E8075 for ; Tue, 31 Jan 2012 10:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.554 X-Spam-Level: * X-Spam-Status: No, score=1.554 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDeLZDN8kF0R for ; Tue, 31 Jan 2012 10:15:53 -0800 (PST) Received: from blu0-omc3-s28.blu0.hotmail.com (blu0-omc3-s28.blu0.hotmail.com [65.55.116.103]) by ietfa.amsl.com (Postfix) with ESMTP id A82AF11E8073 for ; Tue, 31 Jan 2012 10:15:52 -0800 (PST) Received: from BLU0-SMTP22 ([65.55.116.73]) by blu0-omc3-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 10:15:51 -0800 X-Originating-IP: [174.95.243.143] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.143]) by BLU0-SMTP22.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 10:15:50 -0800 From: Gerald Chouinard To: , , , , References: <1328026335.6265.YahooMailNeo@web36703.mail.mud.yahoo.com> Date: Tue, 31 Jan 2012 13:15:49 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BB_01CCE01A.7496C070" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AczfoOYkBqIvPtzVQA6ucq3r2yBLaf//+A4AgAEbk4D//6ZSAP//d23A In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 31 Jan 2012 18:15:50.0579 (UTC) FILETIME=[5CC62830:01CCE044] Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:16:05 -0000 ------=_NextPart_000_00BB_01CCE01A.7496C070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, "Freely" !!! Not exactly. Devices operating in the ISM bands still have to comply with regulatory requirements in terms of maximum power (i.e., EIRP) and band occupation (i.e., their transmissions need to be limited to the ISM band boundaries), and they have to be certified (i.e., bear an FCC ID in the US and IC ID in Canada, etc.). Similar requirements will need to be met by the TV white space devices, and in addition, they will need to abide by the database response depending on their physical location. In simple terms, TV white space devices will likely be considered as ISM band type devices that, in addition, need to check and abide by the database requirements unless some licensing or light-licensing regimes are applied (e.g., RRBS in Canada: IC SRSP300-512, RSS196). Also, in both cases, none of these devices need to provide for coexistence from the regulatory requirements, a potential for evolution toward a 'trash band'. Such co-existence operation would have to come from industry initiatives. Fortunately, a number of groups has already developed schemes to that effect (e.g., 802.19.1, 802.22, 802.16h, etc.) Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Tuesday, 31 January, 2012 11:51 To: mksaji@ieee.org; paul@marvell.com; Brian.Rosen@neustar.biz; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Usage of the spectrum in the case of white space is not akin to the ISM band where any device can operate in that band freely. In this case devices can operate only after verifying channel availability at a location. Databases and regulation control how the spectrum is used. From: "ext M.K.Sajeev" Reply-To: "M.K.Sajeev" Date: Tue, 31 Jan 2012 08:12:15 -0800 To: Paul Lambert , "Brian.Rosen@neustar.biz" , "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Hi, A bit confused seeing the 'unlicensed' band discussion here. Will a white space database be maintaining details of devices/channel allocations of unlicensed band operation of devices? (is it really feasible, as unlicensed band can be used by any device without any specific channels allocation, etc....) Or will the databases limit their operation to just the licensed/lightly licensed band operations? Or is it just that we are only defining these terms here. Best Regards, Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev _____ From: Paul Lambert To: "Rosen, Brian" ; "paws@ietf.org" Sent: Tuesday, 31 January 2012, 4:47 Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > Uh, whitespace device? :-) Maybe . but if we are talking about the "license" it might be "Database Licensed", "Database License-Exempt", or "White Space Licensed" Seems like we had some really excellent definitions - but happened to be missing the category that we are trying to support. "Unlicensed" in FCC terms also has a connotation of multiple users and robustness. Devices operating "unlicensed" are not concerned about potential interference with other unlicensed devices. There are potentially multiple and they generally need to play well together. Licensed devices are typically a single owner to facilitate a level of service based on a more coordinated model. Seems like all devices are licensed from the perspective that the air-wares are controlled and allocated. Even unlicensed or licensed exempt allocations have limitations and device conformance testing. It's just that the end-user does not need to explicitly file for a license in these bands. As an architecture - all devices have a license, and that some just happen to have paid money or been given a monopoly by an authority to have a single user license. Some of the licenses can be short lived and need to be distributed. Some are implicit based on the conformance tests that the device must pass. The licenses that paws is addressing are ones that can be modified by some form of IP communications (aka database lookup). So . as an attempt for text .. Whitespace licensed: Operation of RF devices in a frequency band where authorized operation is determined based on a devices location, device type and operating time period. Coordination of this mode of operation will typically be managed by databases tracking Licensed operation in the same bands. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, January 30, 2012 2:46 PM To: Paul Lambert Cc: Nancy Bravin; Malyar, John P; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Uh, whitespace device? Sorry, couldn't resist. Brian On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote: What is the correct term for something that is operating as a license-exempt device - yet has been given short term authorization to share a channel with other license-exempt devices based on a query to a regional authorities database in a portion of spectrum that may also include licensed or light-licensed devices at other times or in other areas. Paul From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that wouldnormally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_00BB_01CCE01A.7496C070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

“Freely” !!!  Not exactly. Devices operating in the ISM bands still have to comply with regulatory requirements in terms of maximum power (i.e., EIRP) and band occupation (i.e., their transmissions need to be limited to the ISM band boundaries), and they have to be certified (i.e., bear an FCC ID in the = US and IC ID in Canada, etc.).  Similar requirements will need to be met = by the TV white space devices, and in addition, they will need to abide by the database response depending on their physical location. In simple terms, = TV white space devices will likely be considered as ISM band type devices = that, in addition, need to check and abide by the database requirements unless = some licensing or light-licensing regimes are applied (e.g., RRBS in Canada: = IC SRSP300-512, RSS196).

 

Also, in both cases, none of these = devices need to provide for coexistence from the regulatory requirements, a = potential for evolution toward a ‘trash band’. Such co-existence = operation would have to come from industry initiatives. Fortunately, a number of = groups has already developed schemes to that effect (e.g., 802.19.1, 802.22, = 802.16h, etc.)

 

Gerald =

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com
Sent: Tuesday, 31 = January, 2012 11:51
To: mksaji@ieee.org; paul@marvell.com; Brian.Rosen@neustar.biz; paws@ietf.org
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Usage of the = spectrum in the case of white space is not akin to the ISM band where any device = can operate in that band freely. In this case devices can operate only after verifying channel availability at a location. Databases and regulation = control how the spectrum is used.

 

From: "ext M.K.Sajeev" <mksaji@yahoo.com>
Reply-To: = "M.K.Sajeev" <mksaji@ieee.org>
Date: Tue, 31 Jan 2012 = 08:12:15 -0800
To: Paul Lambert <paul@marvell.com>, "Brian.Rosen@neustar.biz"= <Brian.Rosen@neustar.biz>, = "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Hi,

 

A = bit confused seeing the 'unlicensed' band discussion here. Will a white = space database be maintaining details of devices/channel allocations of = unlicensed band operation of devices? (is it really feasible, as unlicensed band = can be used by any device without any specific channels allocation, etc....) Or = will the databases limit their operation to just the  licensed/lightly = licensed band operations? Or is it just that we are only defining these terms = here.

 

Best Regards,

 

Sajeev Manikkoth
Mobile: +919663311378
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

From: Paul Lambert = <paul@marvell.com>
To: "Rosen, = Brian" <Brian.Rosen@neustar.biz>; = "paws@ietf.org" <paws@ietf.org>
Sent: Tuesday, 31 January = 2012, 4:47
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

> Uh, whitespace = device?

J 

Maybe … but if we are talking about the “license” it might = be  “Database Licensed”, “Database = License-Exempt”, or  “White Space Licensed”

 <= /font>

Seems like we had some really excellent definitions – but happened to be missing the category that we are trying to support.

 <= /font>

“Unlicen= sed” in FCC terms also has a connotation of multiple users and = robustness.  Devices operating “unlicensed” are not concerned about = potential interference with other unlicensed devices.  There are potentially multiple and they generally need to play well together.  Licensed = devices are typically a single owner to facilitate a level of service based on a = more coordinated model.

 <= /font>

Seems like all devices are licensed from the perspective that the air-wares = are controlled and allocated.  Even unlicensed or licensed exempt = allocations have limitations and device conformance testing.  It’s just = that the end-user does not need to explicitly file for a license in these = bands.

 <= /font>

As an architecture – all devices have a license, and that some just = happen to have paid money or been given a monopoly by an authority to have a = single user license.  Some of the licenses can be short lived and need to be distributed.  Some are implicit based on the conformance tests that = the device must pass.  The licenses that paws is addressing are ones = that can be modified by some form of IP communications (aka database = lookup).

 <= /font>

So … as an attempt for text ….

 <= /font>

Whitespace licensed: Operation of RF devices in a frequency band where authorized operation is determined based on a devices location, device type and = operating time period.  Coordination of this mode of operation will typically = be managed by databases tracking Licensed operation in the same = bands.

 <= /font>

 <= /font>

Paul

 <= /font>

Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141

 <= /font>

From: Rosen, Brian = [mailto:Brian.Rosen@neustar.biz]
Sent: Monday, January 30, = 2012 2:46 PM
To: Paul Lambert
Cc: Nancy Bravin; Malyar, = John P; paws@ietf.org
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Uh, whitespace device?

 

Sorry, couldn't resist.

 

Brian

=

 

On = Jan 30, 2012, at 5:44 PM, Paul Lambert wrote:

 

 <= /font>

What is the correct term for something that is operating as a license-exempt = device – yet has been given short term authorization to share a channel = with other license-exempt devices based on a query to a regional authorities database in a portion of spectrum that may also include licensed or light-licensed devices at other times or in other = areas.

 <= /font>

 <= /font>

Paul

 <= /font>

 <= /font>

 <= /font>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard
Sent: Monday, January = 30, 2012 3:30 PM
To: paws@ietf.org
Subject: [paws] Discussion = on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my = understanding of the terms:

 

Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small to = facilitate the deployment of a service that would not normally be economically = attractive.  Small local operators would be interested by this (e.g., rural = broadband in Canada) and not big Telcos that wouldnormally work with full licensing through auction = over large service areas.

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for = a specific type of operation. The FCC should be contacted to clarify = it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to = mean “license-exempt," see above.

 

To my knowledge, = the term “unlicensed” is used only in the USA to describe a = legal operation because the term “license-exempt” has been used = for another specific purpose.

 

Since the PAWS = addresses the interface to the database for the international market, it should = rely on the definition of the terms recognized by the ITU-R. I would suggest the = use of ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the = USA = instead of the usual ‘license-exempt’.

 

Gerald

________________= _______________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

________________= _______________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/= mailman/listinfo/paws

 


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

______________= _________________________________ paws mailing list paws@ietf.org https://www.ietf.org/= mailman/listinfo/paws

------=_NextPart_000_00BB_01CCE01A.7496C070-- From Basavaraj.Patil@nokia.com Tue Jan 31 10:29:53 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAB721F8540 for ; Tue, 31 Jan 2012 10:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.983 X-Spam-Level: X-Spam-Status: No, score=-101.983 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbYHfUXbXkG1 for ; Tue, 31 Jan 2012 10:29:51 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 124FB11E80FF for ; Tue, 31 Jan 2012 10:29:50 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0VITQMG020940; Tue, 31 Jan 2012 20:29:29 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 20:29:26 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Tue, 31 Jan 2012 19:29:25 +0100 From: To: , , , , Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: AczfoOYkBqIvPtzVQA6ucq3r2yBLaf//+A4AgAEbk4D//6ZSAP//d23AgACkDYA= Date: Tue, 31 Jan 2012 18:29:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.28] Content-Type: multipart/alternative; boundary="_000_CB4D8F0018A9Fbasavarajpatilnokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2012 18:29:26.0394 (UTC) FILETIME=[4309A5A0:01CCE046] X-Nokia-AV: Clean Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:29:53 -0000 --_000_CB4D8F0018A9Fbasavarajpatilnokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Right.. Agree that ISM band devices still need to comply with regulatory re= quirements and get type approval etc. to operate. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 13:15:49 -0500 To: Basavaraj Patil >, >, >, "Brian.Rosen@neustar.biz" >, "paws@ietf.o= rg" > Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' Hi, =93Freely=94 !!! Not exactly. Devices operating in the ISM bands still hav= e to comply with regulatory requirements in terms of maximum power (i.e., E= IRP) and band occupation (i.e., their transmissions need to be limited to t= he ISM band boundaries), and they have to be certified (i.e., bear an FCC I= D in the US and IC ID in Canada, etc.). Similar requirements will need to = be met by the TV white space devices, and in addition, they will need to ab= ide by the database response depending on their physical location. In simpl= e terms, TVwhite space devices will likely be considered as ISM band type d= evices that, in addition, need to check and abide by the database requireme= nts unless some licensing or light-licensing regimes are applied (e.g., RRB= S in Canada: IC SRSP300-512, RSS196). Also, in both cases, none of these devices need to provide for coexistence = from the regulatory requirements, a potential for evolution toward a =91tra= sh band=92. Such co-existence operation would have to come from industry in= itiatives. Fortunately, a number of groups has already developed schemes to= that effect (e.g., 802.19.1, 802.22, 802.16h, etc.) Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Basavaraj.Patil@nokia.com Sent: Tuesday, 31 January, 2012 11:51 To: mksaji@ieee.org; paul@marvell.com; Brian.Rosen@neustar.biz; paws@= ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Usage of the spectrum in the case of white space is not akin to the ISM ban= d where any device canoperate in that band freely. In this case devices can= operate only after verifying channel availability at a location. Databases= and regulation control how the spectrum is used. From: "ext M.K.Sajeev" > Reply-To: "M.K.Sajeev" > Date: Tue, 31 Jan 2012 08:12:15 -0800 To: Paul Lambert >, "Brian.Rosen@= neustar.biz" >, "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Hi, A bit confused seeing the 'unlicensed' band discussion here. Will a white s= pace database be maintaining details of devices/channel allocations of unli= censed band operation of devices? (is it really feasible, as unlicensed ban= d can be used by any device without any specific channels allocation, etc..= ..) Or will the databases limit their operation to just the licensed/light= ly licensed band operations? Or is it just that we are only defining these = terms here. Best Regards, Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev ________________________________ From: Paul Lambert > To: "Rosen, Brian" = >; "paws@ietf.org" > Sent: Tuesday, 31 January 2012, 4:47 Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > Uh, whitespace device? :) Maybe =85 but if we are talking about the =93license=94 it might be =93Dat= abase Licensed=94, =93Database License-Exempt=94, or =93White Space Licens= ed=94 Seems like we had some really excellent definitions =96 but happened to be = missing the category that we are trying to support. =93Unlicensed=94 in FCC terms also has a connotation of multiple users and = robustness. Devices operating =93unlicensed=94 are not concerned about pote= ntial interference with other unlicensed devices. There are potentially mu= ltiple and they generally need to play well together. Licensed devices are= typically a single owner to facilitate a level of service based on a more = coordinated model. Seems like all devices are licensed from the perspective that the air-wares= are controlled and allocated. Even unlicensed or licensed exempt allocati= ons have limitations and device conformance testing. It=92s just that the = end-user does not need to explicitly file for a license in these bands. As an architecture =96 all devices have a license, and that some just happe= n to have paid money or been given a monopoly by an authority to have a sin= gle user license. Some of the licenses can be short lived and need to be d= istributed. Some are implicit based on the conformance tests that the devi= ce must pass. The licenses that paws is addressing are ones that can be mo= dified by some form of IP communications (aka database lookup). So =85 as an attempt for text =85. Whitespace licensed: Operation of RF devices in a frequency band where auth= orized operation is determined based on a devices location, device type and= operating time period. Coordination of this mode of operation will typica= lly bemanaged by databases tracking Licensed operation in the same bands. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, January 30, 2012 2:46 PM To: Paul Lambert Cc: Nancy Bravin; Malyar, John P; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Uh, whitespace device? Sorry, couldn't resist. Brian On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote: What is the correct term for something that is operating as a license-exemp= t device =96 yet has been given short term authorization to share a channel= withother license-exempt devices based on a query to a regional authoritie= s database in a portion of spectrum that may also include licensed or light= -licensed devices at other times or in other areas. Paul From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gerald Chouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural broa= dband in Canada) and not big Telcos that wouldnormally work with full licen= sing through auction overlarge service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB4D8F0018A9Fbasavarajpatilnokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5DFA634AC4D96E498633F2ACEBCE2AA9@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable

Right.. Agree that ISM band devices still need to comply with regulato= ry requirements and get type approval etc. to operate.

From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca<= /a>>
Date: Tue, 31 Jan 2012 13:15:49 -05= 00
To: Basavaraj Patil <basavaraj.patil@nokia.com>, <mksaji@ieee.org>, <paul@marvell.com>, "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz= >, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Discussion on '= license-exempt' vs 'unlicensed'

Hi,

 

=93Freely=94 !!!  Not exactly. De= vices operating in the ISM bands still have to comply with regulatory requi= rements in terms of maximum power (i.e., EIRP) and band occupation (i.e., their transmissions need to be lim= ited to the ISM band boundaries), and they have to be certified (i.e., bear= an FCC ID in the US and IC ID in Canada, etc.).  Similar requirements= will need to be met by the TV white space devices, and in addition, they will need to abide by the database re= sponse depending on their physical location. In simple terms, TVwhite space= devices will likely be considered as ISM band type devices that, in additi= on, need to check and abide by the database requirements unless some licensing or light-licensing regimes are= applied (e.g., RRBS in Canada: IC SRSP300-512, RSS196).<= /font>

 

Also, in both cases, none of these dev= ices need to provide for coexistence from the regulatory requirements, a po= tential for evolution toward a =91trash band=92. Such co-existence operation would have to come = from industry initiatives. Fortunately, a number of groups has already deve= loped schemes to that effect (e.g., 802.19.1, 802.22, 802.16h, etc.)

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Basavaraj.Patil@nokia.com
Sent: Tuesday, 31 January, 2= 012 11:51
To: mksaji@ieee.org; paul@marvell.com; Brian.Rosen@neustar.biz; paws@ietf.org=
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 

Usage of the= spectrum in the case of white space is not akin to the ISM band where any = device canoperate in that band freely. In this case devices can operate only after verifying channel availability at= a location. Databases and regulation control how the spectrum is used.

 <= /o:p>

From: = "ext = M.K.Sajeev" <mksaji@yahoo.com>
Reply-To: "M.K.Sajeev&q= uot; <mksaji@ieee.org>
Date: Tue, 31 Jan 2012 08:12= :15 -0800
To: Paul Lambert <paul@marvell.com>, "Brian.Rosen@neustar.biz" <Brian.Rosen@neustar.biz>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 <= /o:p>

Hi,

 

A bit confused seeing the 'unlicensed' band discussion here. Will a whit= e space database be maintaining details of devices/channel allocations of unlicensed band operation of devices? (is it really feasibl= e, as unlicensed band can be used by any device without any specific channe= ls allocation, etc....) Or will the databases limit their operation to just= the  licensed/lightly licensed band operations? Or is it just that we are only defining these terms here.=

 

Best Regards,

 

<= font size=3D"3" color=3D"#c00000" face=3D"Times New Roman">Sajeev Manikkoth
Mobile:= +919663311378
Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev

From: Paul Lambert <paul@marvell.com&= gt;
To: "Rosen, Brian"= <Brian.Rosen@neustar.biz= >; "paws@ietf.org" <paws@ietf.org>
Sent: Tuesday, 31 January 20= 12, 4:47
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'<= span style=3D"color:black">

 

> Uh, whitespace device?

J  =

Maybe =85 but if we are talking about the =93license=94 it m= ight be  =93Database Licensed=94, =93Database License-Exempt=94, or  =93White Space Licensed=94

 

Seems like we had some really excellent definitions =96 but = happened to be missing the category that we are trying to support.

 

=93Unlicensed=94 in FCC terms also has a connotation of mult= iple users and robustness. Devices operating =93unlicensed=94 are not concerned about potential interference with other unlicensed devic= es.  There are potentially multiple and they generally need to play we= ll together.  Licensed devices are typically a single owner to facilit= ate a level of service based on a more coordinated model.

 

Seems like all devices are licensed from the perspective tha= t the air-wares are controlled and allocated.  Even unlicensed or licensed exempt allocations have limitations and device= conformance testing.  It=92s just that the end-user does not need to = explicitly file for a license in these bands.

 

As an architecture =96 all devices have a license, and that = some just happen to have paid money or been given a monopoly by an authority to have a single user license.  Some of th= e licenses can be short lived and need to be distributed.  Some are im= plicit based on the conformance tests that the device must pass.  The = licenses that paws is addressing are ones that can be modified by some form of IP communications (aka database lookup).

 

So =85 as an attempt for text =85.

 

Whitespace licensed: Operation of RF devices in a frequency band where authorized operation is determined= based on a devices location, device type and operating time period.  = Coordination of this mode of operation will typically bemanaged by database= s tracking Licensed operation in the same bands.

 

 

Paul

 

Paul A. Lambert | Marvell Semiconductor | +1-650-787-914= 1

 

From: Rosen, Brian [mailto:Brian.Rose= n@neustar.biz]
Sent: Monday, January 30, 20= 12 2:46 PM
To: Paul Lambert
Cc: Nancy Bravin; Malyar, Jo= hn P; paws@ietf.org
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'<= span style=3D"color:black">

 

Uh, whitespace device?

 

Sorry, couldn't resist.

 

Brian

 

On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote:

 

 

What is the correct term for something that is operating as = a license-exempt device =96 yet has been given short term authorization to share a channel withother license-exempt devic= es based on a query to a regional authorities database in a portion of spec= trum that may also include licensed or light-licensed devices at other time= s or in other areas.

 

 

Paul

 

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gerald Chouinard
Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org
Subject: [paws] Discussion on 'license-ex= empt' vs 'unlicensed'

 

All,

 

Here is my understanding of the terms:

 

Licensed: <= /span>Spectrum that is acquired by an operator over a given service area for a given time= period.  This is usually done through auctions (think of the Telcos),= beauty contest, first-come / first-served or by government allocation (e.g= ., public service).

 

Lightly licensed:=  = Special case where thefrequency allocation is done through first-come / first-serv= ed process for a given time frame over a relatively limited service area. T= he annual license fee is usually small to facilitate the deployment of a se= rvice that would not normally be economically attractive. Small local operators would be interested by= this (e.g., rural broadband in C= anada) and not big Telcos that wouldnormally work with full licensing through auction ove= rlarge service areas.

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing process is nee= ded such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be cont= acted to clarify it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a = duly issued license.  In the USA, this term is used to mean =93license-exempt," see above.

 

To my knowledge, the term =93unlicensed=94 is used only in the USA=  to describe a legal operation because the term =93license-exempt=94 has been = used for another specific purpose.

 

Since the PAWS addresses the interface to the database for the int= ernational market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of =91licens= ed=92 and =91license-exempt=92 with a footnote indicating that the term =91= unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.

 

Gerald

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

 

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

 


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

____________= ___________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB4D8F0018A9Fbasavarajpatilnokiacom_-- From paul@marvell.com Tue Jan 31 10:54:36 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6392521F85C6 for ; Tue, 31 Jan 2012 10:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MTxLQ6l7Fk0 for ; Tue, 31 Jan 2012 10:54:35 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4537421F85BB for ; Tue, 31 Jan 2012 10:54:34 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTyg451rX0eW9qCe+HhNsAw62UGkGfvkf@postini.com; Tue, 31 Jan 2012 10:54:34 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Tue, 31 Jan 2012 10:51:06 -0800 From: Paul Lambert To: M.K.Sajeev , "Rosen, Brian" , "paws@ietf.org" Date: Tue, 31 Jan 2012 10:51:04 -0800 Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: AczgMxtVhQQfna1NTKWHrHrwEqs4rgAFeFxg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567643194@SC-VEXCH2.marvell.com> References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> <32E7EA09-A091-4FE5-B3A1-85F249D3520E@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FBD@SC-VEXCH2.marvell.com> <1328026335.6265.YahooMailNeo@web36703.mail.mud.yahoo.com> In-Reply-To: <1328026335.6265.YahooMailNeo@web36703.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7BAC95F5A7E67643AAFB2C31BEE662D01567643194SCVEXCH2marve_" MIME-Version: 1.0 Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:54:36 -0000 --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567643194SCVEXCH2marve_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpMaWdodGx5ICBsaWNlbnNlZCBhbmQgbGljZW5zZSBleGVtcHQgKG9yIHVubGljZW5zZWQgaW4g RkNDIHZlcm5hY3VsYXIpIGhhdmUgcHJpb3Ig4oCTIHRoYXQgd2FzIHdoeSBJIHdhcyBwcm9wb3Np bmcgdGhhdCB3ZSBzaG91bGQgaW5jbHVkZSBhIGRlZmluaXRpb24gZm9yIHRoZSBnZW9sb2NhdGlv biBiYXNlZCB3aGl0ZSBzcGFjZSBhY2Nlc3MgdGhhdCBwYXdzIGlzIHN1cHBvcnRpbmcgYXMgYSBu ZXcgZGVmaW5pdGlvbi4NCg0KUGF1bA0KDQoNClBhdWwgQS4gTGFtYmVydCB8IE1hcnZlbGwgU2Vt aWNvbmR1Y3RvciB8ICsxLTY1MC03ODctOTE0MQ0KDQpGcm9tOiBNLksuU2FqZWV2IFttYWlsdG86 bWtzYWppQHlhaG9vLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTIgODoxMiBB TQ0KVG86IFBhdWwgTGFtYmVydDsgUm9zZW4sIEJyaWFuOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3Bhd3NdIERpc2N1c3Npb24gb24gJ2xpY2Vuc2UtZXhlbXB0JyB2cyAndW5saWNlbnNl ZCcNCg0KSGksDQoNCkEgYml0IGNvbmZ1c2VkIHNlZWluZyB0aGUgJ3VubGljZW5zZWQnIGJhbmQg ZGlzY3Vzc2lvbiBoZXJlLiBXaWxsIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgYmUgbWFpbnRhaW5p bmcgZGV0YWlscyBvZiBkZXZpY2VzL2NoYW5uZWwgYWxsb2NhdGlvbnMgb2YgdW5saWNlbnNlZCBi YW5kIG9wZXJhdGlvbiBvZiBkZXZpY2VzPyAoaXMgaXQgcmVhbGx5IGZlYXNpYmxlLCBhcyB1bmxp Y2Vuc2VkIGJhbmQgY2FuIGJlIHVzZWQgYnkgYW55IGRldmljZSB3aXRob3V0IGFueSBzcGVjaWZp YyBjaGFubmVscyBhbGxvY2F0aW9uLCBldGMuLi4uKSBPciB3aWxsIHRoZSBkYXRhYmFzZXMgbGlt aXQgdGhlaXIgb3BlcmF0aW9uIHRvIGp1c3QgdGhlICBsaWNlbnNlZC9saWdodGx5IGxpY2Vuc2Vk IGJhbmQgb3BlcmF0aW9ucz8gT3IgaXMgaXQganVzdCB0aGF0IHdlIGFyZSBvbmx5IGRlZmluaW5n IHRoZXNlIHRlcm1zIGhlcmUuDQoNCkJlc3QgUmVnYXJkcywNCg0KU2FqZWV2IE1hbmlra290aA0K TW9iaWxlOiArOTE5NjYzMzExMzc4DQpFbWFpbDogbWtzYWppQGllZWUub3JnDQpodHRwOi8vd3d3 LmxpbmtlZGluLmNvbS9pbi9ta3NhamVldg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRnJvbTogUGF1bCBMYW1iZXJ0IDxwYXVsQG1hcnZlbGwuY29tPg0KVG86ICJSb3Nlbiwg QnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej47ICJwYXdzQGlldGYub3JnIiA8cGF3c0Bp ZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIDMxIEphbnVhcnkgMjAxMiwgNDo0Nw0KU3ViamVjdDog UmU6IFtwYXdzXSBEaXNjdXNzaW9uIG9uICdsaWNlbnNlLWV4ZW1wdCcgdnMgJ3VubGljZW5zZWQn DQoNCj4gVWgsIHdoaXRlc3BhY2UgZGV2aWNlPw0K4pi6DQpNYXliZSDigKYgYnV0IGlmIHdlIGFy ZSB0YWxraW5nIGFib3V0IHRoZSDigJxsaWNlbnNl4oCdIGl0IG1pZ2h0IGJlICDigJxEYXRhYmFz ZSBMaWNlbnNlZOKAnSwg4oCcRGF0YWJhc2UgTGljZW5zZS1FeGVtcHTigJ0sIG9yICDigJxXaGl0 ZSBTcGFjZSBMaWNlbnNlZOKAnQ0KDQpTZWVtcyBsaWtlIHdlIGhhZCBzb21lIHJlYWxseSBleGNl bGxlbnQgZGVmaW5pdGlvbnMg4oCTIGJ1dCBoYXBwZW5lZCB0byBiZSBtaXNzaW5nIHRoZSBjYXRl Z29yeSB0aGF0IHdlIGFyZSB0cnlpbmcgdG8gc3VwcG9ydC4NCg0K4oCcVW5saWNlbnNlZOKAnSBp biBGQ0MgdGVybXMgYWxzbyBoYXMgYSBjb25ub3RhdGlvbiBvZiBtdWx0aXBsZSB1c2VycyBhbmQg cm9idXN0bmVzcy4gIERldmljZXMgb3BlcmF0aW5nIOKAnHVubGljZW5zZWTigJ0gYXJlIG5vdCBj b25jZXJuZWQgYWJvdXQgcG90ZW50aWFsIGludGVyZmVyZW5jZSB3aXRoIG90aGVyIHVubGljZW5z ZWQgZGV2aWNlcy4gIFRoZXJlIGFyZSBwb3RlbnRpYWxseSBtdWx0aXBsZSBhbmQgdGhleSBnZW5l cmFsbHkgbmVlZCB0byBwbGF5IHdlbGwgdG9nZXRoZXIuICBMaWNlbnNlZCBkZXZpY2VzIGFyZSB0 eXBpY2FsbHkgYSBzaW5nbGUgb3duZXIgdG8gZmFjaWxpdGF0ZSBhIGxldmVsIG9mIHNlcnZpY2Ug YmFzZWQgb24gYSBtb3JlIGNvb3JkaW5hdGVkIG1vZGVsLg0KDQpTZWVtcyBsaWtlIGFsbCBkZXZp Y2VzIGFyZSBsaWNlbnNlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSB0aGF0IHRoZSBhaXItd2FyZXMg YXJlIGNvbnRyb2xsZWQgYW5kIGFsbG9jYXRlZC4gIEV2ZW4gdW5saWNlbnNlZCBvciBsaWNlbnNl ZCBleGVtcHQgYWxsb2NhdGlvbnMgaGF2ZSBsaW1pdGF0aW9ucyBhbmQgZGV2aWNlIGNvbmZvcm1h bmNlIHRlc3RpbmcuICBJdOKAmXMganVzdCB0aGF0IHRoZSBlbmQtdXNlciBkb2VzIG5vdCBuZWVk IHRvIGV4cGxpY2l0bHkgZmlsZSBmb3IgYSBsaWNlbnNlIGluIHRoZXNlIGJhbmRzLg0KDQpBcyBh biBhcmNoaXRlY3R1cmUg4oCTIGFsbCBkZXZpY2VzIGhhdmUgYSBsaWNlbnNlLCBhbmQgdGhhdCBz b21lIGp1c3QgaGFwcGVuIHRvIGhhdmUgcGFpZCBtb25leSBvciBiZWVuIGdpdmVuIGEgbW9ub3Bv bHkgYnkgYW4gYXV0aG9yaXR5IHRvIGhhdmUgYSBzaW5nbGUgdXNlciBsaWNlbnNlLiAgU29tZSBv ZiB0aGUgbGljZW5zZXMgY2FuIGJlIHNob3J0IGxpdmVkIGFuZCBuZWVkIHRvIGJlIGRpc3RyaWJ1 dGVkLiAgU29tZSBhcmUgaW1wbGljaXQgYmFzZWQgb24gdGhlIGNvbmZvcm1hbmNlIHRlc3RzIHRo YXQgdGhlIGRldmljZSBtdXN0IHBhc3MuICBUaGUgbGljZW5zZXMgdGhhdCBwYXdzIGlzIGFkZHJl c3NpbmcgYXJlIG9uZXMgdGhhdCBjYW4gYmUgbW9kaWZpZWQgYnkgc29tZSBmb3JtIG9mIElQIGNv bW11bmljYXRpb25zIChha2EgZGF0YWJhc2UgbG9va3VwKS4NCg0KU28g4oCmIGFzIGFuIGF0dGVt cHQgZm9yIHRleHQg4oCmLg0KDQpXaGl0ZXNwYWNlIGxpY2Vuc2VkOiBPcGVyYXRpb24gb2YgUkYg ZGV2aWNlcyBpbiBhIGZyZXF1ZW5jeSBiYW5kIHdoZXJlIGF1dGhvcml6ZWQgb3BlcmF0aW9uIGlz IGRldGVybWluZWQgYmFzZWQgb24gYSBkZXZpY2VzIGxvY2F0aW9uLCBkZXZpY2UgdHlwZSBhbmQg b3BlcmF0aW5nIHRpbWUgcGVyaW9kLiAgQ29vcmRpbmF0aW9uIG9mIHRoaXMgbW9kZSBvZiBvcGVy YXRpb24gd2lsbCB0eXBpY2FsbHkgYmUgbWFuYWdlZCBieSBkYXRhYmFzZXMgdHJhY2tpbmcgTGlj ZW5zZWQgb3BlcmF0aW9uIGluIHRoZSBzYW1lIGJhbmRzLg0KDQoNClBhdWwNCg0KUGF1bCBBLiBM YW1iZXJ0IHwgTWFydmVsbCBTZW1pY29uZHVjdG9yIHwgKzEtNjUwLTc4Ny05MTQxDQoNCkZyb206 IFJvc2VuLCBCcmlhbiBbbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KU2VudDogTW9u ZGF5LCBKYW51YXJ5IDMwLCAyMDEyIDI6NDYgUE0NClRvOiBQYXVsIExhbWJlcnQNCkNjOiBOYW5j eSBCcmF2aW47IE1hbHlhciwgSm9obiBQOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bh d3NdIERpc2N1c3Npb24gb24gJ2xpY2Vuc2UtZXhlbXB0JyB2cyAndW5saWNlbnNlZCcNCg0KVWgs IHdoaXRlc3BhY2UgZGV2aWNlPw0KDQpTb3JyeSwgY291bGRuJ3QgcmVzaXN0Lg0KDQpCcmlhbg0K DQpPbiBKYW4gMzAsIDIwMTIsIGF0IDU6NDQgUE0sIFBhdWwgTGFtYmVydCB3cm90ZToNCg0KDQpX aGF0IGlzIHRoZSBjb3JyZWN0IHRlcm0gZm9yIHNvbWV0aGluZyB0aGF0IGlzIG9wZXJhdGluZyBh cyBhIGxpY2Vuc2UtZXhlbXB0IGRldmljZSDigJMgeWV0IGhhcyBiZWVuIGdpdmVuIHNob3J0IHRl cm0gYXV0aG9yaXphdGlvbiB0byBzaGFyZSBhIGNoYW5uZWwgd2l0aCBvdGhlciBsaWNlbnNlLWV4 ZW1wdCBkZXZpY2VzIGJhc2VkIG9uIGEgcXVlcnkgdG8gYSByZWdpb25hbCBhdXRob3JpdGllcyBk YXRhYmFzZSBpbiBhIHBvcnRpb24gb2Ygc3BlY3RydW0gdGhhdCBtYXkgYWxzbyBpbmNsdWRlIGxp Y2Vuc2VkIG9yIGxpZ2h0LWxpY2Vuc2VkIGRldmljZXMgYXQgb3RoZXIgdGltZXMgb3IgaW4gb3Ro ZXIgYXJlYXMuDQoNCg0KUGF1bA0KDQoNCg0KRnJvbTogcGF3cy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgR2VyYWxkIENob3VpbmFyZA0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDMw LCAyMDEyIDM6MzAgUE0NClRvOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0K U3ViamVjdDogW3Bhd3NdIERpc2N1c3Npb24gb24gJ2xpY2Vuc2UtZXhlbXB0JyB2cyAndW5saWNl bnNlZCcNCg0KQWxsLA0KDQpIZXJlIGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIHRlcm1zOg0K DQpMaWNlbnNlZDogU3BlY3RydW0gdGhhdCBpcyBhY3F1aXJlZCBieSBhbiBvcGVyYXRvciBvdmVy IGEgZ2l2ZW4gc2VydmljZSBhcmVhIGZvciBhIGdpdmVuIHRpbWUgcGVyaW9kLiAgVGhpcyBpcyB1 c3VhbGx5IGRvbmUgdGhyb3VnaCBhdWN0aW9ucyAodGhpbmsgb2YgdGhlIFRlbGNvcyksIGJlYXV0 eSBjb250ZXN0LCBmaXJzdC1jb21lIC8gZmlyc3Qtc2VydmVkIG9yIGJ5IGdvdmVybm1lbnQgYWxs b2NhdGlvbiAoZS5nLiwgcHVibGljIHNlcnZpY2UpLg0KDQpMaWdodGx5IGxpY2Vuc2VkOiBTcGVj aWFsIGNhc2Ugd2hlcmUgdGhlZnJlcXVlbmN5IGFsbG9jYXRpb24gaXMgZG9uZSB0aHJvdWdoIGZp cnN0LWNvbWUgLyBmaXJzdC1zZXJ2ZWQgcHJvY2VzcyBmb3IgYSBnaXZlbiB0aW1lIGZyYW1lIG92 ZXIgYSByZWxhdGl2ZWx5IGxpbWl0ZWQgc2VydmljZSBhcmVhLiBUaGUgYW5udWFsIGxpY2Vuc2Ug ZmVlIGlzIHVzdWFsbHkgc21hbGwgdG8gZmFjaWxpdGF0ZSB0aGUgZGVwbG95bWVudCBvZiBhIHNl cnZpY2UgdGhhdCB3b3VsZCBub3Qgbm9ybWFsbHkgYmUgZWNvbm9taWNhbGx5IGF0dHJhY3RpdmUu ICBTbWFsbCBsb2NhbCBvcGVyYXRvcnMgd291bGQgYmUgaW50ZXJlc3RlZCBieSB0aGlzIChlLmcu LCBydXJhbCBicm9hZGJhbmQgaW4gQ2FuYWRhKSBhbmQgbm90IGJpZyBUZWxjb3MgdGhhdCB3b3Vs ZCBub3JtYWxseSB3b3JrIHdpdGggZnVsbCBsaWNlbnNpbmcgdGhyb3VnaCBhdWN0aW9uIG92ZXIg bGFyZ2Ugc2VydmljZSBhcmVhcy4NCg0KTGljZW5zZS1leGVtcHQ6IE9wZXJhdGlvbiBvZiBSRiBk ZXZpY2VzIGluIGEgZnJlcXVlbmN5IGJhbmQgd2hlcmUgbm8gZm9ybWFsIGxpY2Vuc2luZyBwcm9j ZXNzIGlzIG5lZWRlZCBzdWNoIGFzIGluIHRoZSAyLjQgR0h6IElTTSBiYW5kLiBJbiB0aGUgVVNB LCB0aGlzIHRlcm0gaXMgdXNlZCBmb3IgYSBzcGVjaWZpYyB0eXBlIG9mIG9wZXJhdGlvbi4gVGhl IEZDQyBzaG91bGQgYmUgY29udGFjdGVkIHRvIGNsYXJpZnkgaXQuDQoNClVubGljZW5zZWQ6IEls bGVnYWwgb3BlcmF0aW9uIG9mIGFuIFJGIGRldmljZSB0aGF0IGNhbiB0cmFuc21pdCBpbiBhIGZy ZXF1ZW5jeSBiYW5kIHdpdGhvdXQgYSBkdWx5IGlzc3VlZCBsaWNlbnNlLiAgSW4gdGhlIFVTQSwg dGhpcyB0ZXJtIGlzIHVzZWQgdG8gbWVhbiDigJxsaWNlbnNlLWV4ZW1wdCwiIHNlZSBhYm92ZS4N Cg0KVG8gbXkga25vd2xlZGdlLCB0aGUgdGVybSDigJx1bmxpY2Vuc2Vk4oCdIGlzIHVzZWQgb25s eSBpbiB0aGUgVVNBIHRvIGRlc2NyaWJlIGEgbGVnYWwgb3BlcmF0aW9uIGJlY2F1c2UgdGhlIHRl cm0g4oCcbGljZW5zZS1leGVtcHTigJ0gaGFzIGJlZW4gdXNlZCBmb3IgYW5vdGhlciBzcGVjaWZp YyBwdXJwb3NlLg0KDQpTaW5jZSB0aGUgUEFXUyBhZGRyZXNzZXMgdGhlIGludGVyZmFjZSB0byB0 aGUgZGF0YWJhc2UgZm9yIHRoZSBpbnRlcm5hdGlvbmFsIG1hcmtldCwgaXQgc2hvdWxkIHJlbHkg b24gdGhlIGRlZmluaXRpb24gb2YgdGhlIHRlcm1zIHJlY29nbml6ZWQgYnkgdGhlIElUVS1SLiBJ IHdvdWxkIHN1Z2dlc3QgdGhlIHVzZSBvZiDigJhsaWNlbnNlZOKAmSBhbmQg4oCYbGljZW5zZS1l eGVtcHTigJkgd2l0aCBhIGZvb3Rub3RlIGluZGljYXRpbmcgdGhhdCB0aGUgdGVybSDigJh1bmxp Y2Vuc2Vk4oCZIGlzIHVzZWQgaW4gdGhlIFVTQSBpbnN0ZWFkIG9mIHRoZSB1c3VhbCDigJhsaWNl bnNlLWV4ZW1wdOKAmS4NCg0KR2VyYWxkDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRv OnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBh d3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpw YXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg== --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567643194SCVEXCH2marve_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAw IDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0K CXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAueWl2OTEzNjI3MTEybXNvbm9y bWFsLCBsaS55aXY5MTM2MjcxMTJtc29ub3JtYWwsIGRpdi55aXY5MTM2MjcxMTJtc29ub3JtYWwN Cgl7bXNvLXN0eWxlLW5hbWU6eWl2OTEzNjI3MTEybXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQs IGxpLnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQsIGRpdi55aXY5MTM2MjcxMTJtc29jaHBkZWZh dWx0DQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQ7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2OTEzNjI3MTEybXNv aHlwZXJsaW5rDQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMm1zb2h5cGVybGluazt9DQpz cGFuLnlpdjkxMzYyNzExMm1zb2h5cGVybGlua2ZvbGxvd2VkDQoJe21zby1zdHlsZS1uYW1lOnlp djkxMzYyNzExMm1zb2h5cGVybGlua2ZvbGxvd2VkO30NCnNwYW4ueWl2OTEzNjI3MTEyZW1haWxz dHlsZTE5DQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMmVtYWlsc3R5bGUxOTt9DQpwLnlp djkxMzYyNzExMm1zb25vcm1hbDEsIGxpLnlpdjkxMzYyNzExMm1zb25vcm1hbDEsIGRpdi55aXY5 MTM2MjcxMTJtc29ub3JtYWwxDQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMm1zb25vcm1h bDE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4ueWl2 OTEzNjI3MTEybXNvaHlwZXJsaW5rMQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5MTM2MjcxMTJtc29o eXBlcmxpbmsxOw0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLnlpdjkxMzYyNzExMm1zb2h5cGVybGlua2ZvbGxvd2VkMQ0KCXttc28tc3R5bGUtbmFtZTp5 aXY5MTM2MjcxMTJtc29oeXBlcmxpbmtmb2xsb3dlZDE7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi55aXY5MTM2MjcxMTJlbWFpbHN0eWxlMTkxDQoJ e21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMmVtYWlsc3R5bGUxOTE7DQoJZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpwLnlpdjkxMzYyNzExMm1z b2NocGRlZmF1bHQxLCBsaS55aXY5MTM2MjcxMTJtc29jaHBkZWZhdWx0MSwgZGl2LnlpdjkxMzYy NzExMm1zb2NocGRlZmF1bHQxDQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMm1zb2NocGRl ZmF1bHQxOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LnlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5 MTM2MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCg0KPGJv ZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0KDQo8ZGl2IGNsYXNzPVNlY3Rp b24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpj b2xvcjojMUY0OTdEJz5MaWdodGx5IMKgbGljZW5zZWQgYW5kIGxpY2Vuc2UgZXhlbXB0IChvciB1 bmxpY2Vuc2VkIGluIEZDQw0KdmVybmFjdWxhcikgaGF2ZSBwcmlvciDigJMgdGhhdCB3YXMgd2h5 IEkgd2FzIHByb3Bvc2luZyB0aGF0IHdlIHNob3VsZCBpbmNsdWRlIGENCmRlZmluaXRpb24gZm9y IHRoZSBnZW9sb2NhdGlvbiBiYXNlZCB3aGl0ZSBzcGFjZSBhY2Nlc3MgdGhhdCBwYXdzIGlzIHN1 cHBvcnRpbmcNCmFzIGEgbmV3IGRlZmluaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0 OTdEJz5QYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojN0Y3RjdGJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29s b3I6IzdGN0Y3Ric+UGF1bCBBLiBMYW1iZXJ0IHwgTWFydmVsbCBTZW1pY29uZHVjdG9yIHwgKzEt NjUwLTc4Ny05MTQxPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYgc3R5bGU9 J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiInPiBNLksuU2FqZWV2DQpbbWFpbHRvOm1rc2FqaUB5YWhvby5jb21dIDxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDEyIDg6MTIgQU08YnI+DQo8 Yj5Ubzo8L2I+IFBhdWwgTGFtYmVydDsgUm9zZW4sIEJyaWFuOyBwYXdzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbcGF3c10gRGlzY3Vzc2lvbiBvbiAnbGljZW5zZS1leGVtcHQn IHZzICd1bmxpY2Vuc2VkJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNw YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPkEgYml0DQpjb25mdXNlZCBzZWVpbmcg dGhlICd1bmxpY2Vuc2VkJyBiYW5kIGRpc2N1c3Npb24gaGVyZS4gV2lsbCBhIHdoaXRlIHNwYWNl DQpkYXRhYmFzZSBiZSBtYWludGFpbmluZyBkZXRhaWxzIG9mIGRldmljZXMvY2hhbm5lbCBhbGxv Y2F0aW9ucyBvZiB1bmxpY2Vuc2VkDQpiYW5kIG9wZXJhdGlvbiBvZiBkZXZpY2VzPyAoaXMgaXQg cmVhbGx5IGZlYXNpYmxlLCBhcyB1bmxpY2Vuc2VkIGJhbmQgY2FuIGJlDQp1c2VkIGJ5IGFueSBk ZXZpY2Ugd2l0aG91dCBhbnkgc3BlY2lmaWMgY2hhbm5lbHMgYWxsb2NhdGlvbiwgZXRjLi4uLikg T3Igd2lsbA0KdGhlIGRhdGFiYXNlcyBsaW1pdCB0aGVpciBvcGVyYXRpb24gdG8ganVzdCB0aGUg Jm5ic3A7bGljZW5zZWQvbGlnaHRseSBsaWNlbnNlZA0KYmFuZCBvcGVyYXRpb25zPyBPciBpcyBp dCBqdXN0IHRoYXQgd2UgYXJlIG9ubHkgZGVmaW5pbmcgdGhlc2UgdGVybXMgaGVyZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48aT48c3BhbiBzdHlsZT0nY29sb3I6I0Mw MDAwMCc+QmVzdA0KUmVnYXJkcyw8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0 ZSc+PGk+PHNwYW4NCnN0eWxlPSdjb2xvcjojQzAwMDAwJz5TYWplZXYgTWFuaWtrb3RoPGJyPg0K TW9iaWxlOiArOTE5NjYzMzExMzc4PGJyPg0KRW1haWw6IG1rc2FqaUBpZWVlLm9yZzxicj4NCjxh IGhyZWY9Imh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL21rc2FqZWV2IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL3d3dy5saW5rZWRpbi5jb20vaW4vbWtzYWplZXY8L2E+PC9zcGFuPjwvaT48c3Bh bg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05v cm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hp dGUnPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+DQoNCjxociBzaXplPTEgd2lkdGg9IjEwMCUiIGFsaWdu PWNlbnRlcj4NCg0KPC9zcGFuPjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2Jh Y2tncm91bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPiBQYXVsDQpMYW1iZXJ0ICZsdDtwYXVsQG1hcnZlbGwuY29tJmd0 Ozxicj4NCjxiPlRvOjwvYj4gJnF1b3Q7Um9zZW4sIEJyaWFuJnF1b3Q7ICZsdDtCcmlhbi5Sb3Nl bkBuZXVzdGFyLmJpeiZndDs7DQomcXVvdDtwYXdzQGlldGYub3JnJnF1b3Q7ICZsdDtwYXdzQGll dGYub3JnJmd0OyA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgMzEgSmFudWFyeSAyMDEyLCA0 OjQ3PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcGF3c10gRGlzY3Vzc2lvbiBvbiAnbGljZW5z ZS1leGVtcHQnIHZzICd1bmxpY2Vuc2VkJzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IGlkPXlpdjkxMzYyNzExMj4NCg0KPGRpdj4N Cg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZndDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdj b2xvcjpibGFjayc+IFVoLCB3aGl0ZXNwYWNlIGRldmljZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6V2lu Z2RpbmdzO2NvbG9yOiMxRjQ5N0QnPko8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJz cDsgPC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dy b3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NYXliZSDigKYgYnV0IGlmIHdlIGFy ZSB0YWxraW5nDQphYm91dCB0aGUg4oCcbGljZW5zZeKAnSBpdCBtaWdodCBiZSAmbmJzcDvigJxE YXRhYmFzZSBMaWNlbnNlZOKAnSwg4oCcRGF0YWJhc2UNCkxpY2Vuc2UtRXhlbXB04oCdLCBvciAm bmJzcDvigJxXaGl0ZSBTcGFjZSBMaWNlbnNlZOKAnTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlZW1zIGxpa2Ugd2Ug aGFkIHNvbWUgcmVhbGx5DQpleGNlbGxlbnQgZGVmaW5pdGlvbnMg4oCTIGJ1dCBoYXBwZW5lZCB0 byBiZSBtaXNzaW5nIHRoZSBjYXRlZ29yeSB0aGF0IHdlIGFyZQ0KdHJ5aW5nIHRvIHN1cHBvcnQu PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0K DQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5k OndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9 J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+4oCcVW5saWNlbnNlZOKAnSBpbiBGQ0MgdGVybXMgYWxzbw0KaGFzIGEgY29u bm90YXRpb24gb2YgbXVsdGlwbGUgdXNlcnMgYW5kIHJvYnVzdG5lc3MuJm5ic3A7IERldmljZXMg b3BlcmF0aW5nDQrigJx1bmxpY2Vuc2Vk4oCdIGFyZSBub3QgY29uY2VybmVkIGFib3V0IHBvdGVu dGlhbCBpbnRlcmZlcmVuY2Ugd2l0aCBvdGhlcg0KdW5saWNlbnNlZCBkZXZpY2VzLiZuYnNwOyBU aGVyZSBhcmUgcG90ZW50aWFsbHkgbXVsdGlwbGUgYW5kIHRoZXkgZ2VuZXJhbGx5DQpuZWVkIHRv IHBsYXkgd2VsbCB0b2dldGhlci4mbmJzcDsgTGljZW5zZWQgZGV2aWNlcyBhcmUgdHlwaWNhbGx5 IGEgc2luZ2xlIG93bmVyDQp0byBmYWNpbGl0YXRlIGEgbGV2ZWwgb2Ygc2VydmljZSBiYXNlZCBv biBhIG1vcmUgY29vcmRpbmF0ZWQgbW9kZWwuPC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNlZW1zIGxpa2UgYWxsIGRl dmljZXMgYXJlDQpsaWNlbnNlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSB0aGF0IHRoZSBhaXItd2Fy ZXMgYXJlIGNvbnRyb2xsZWQgYW5kDQphbGxvY2F0ZWQuJm5ic3A7IEV2ZW4gdW5saWNlbnNlZCBv ciBsaWNlbnNlZCBleGVtcHQgYWxsb2NhdGlvbnMgaGF2ZQ0KbGltaXRhdGlvbnMgYW5kIGRldmlj ZSBjb25mb3JtYW5jZSB0ZXN0aW5nLiZuYnNwOyBJdOKAmXMganVzdCB0aGF0IHRoZSBlbmQtdXNl cg0KZG9lcyBub3QgbmVlZCB0byBleHBsaWNpdGx5IGZpbGUgZm9yIGEgbGljZW5zZSBpbiB0aGVz ZSBiYW5kcy48L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3Nw YW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3Bh bg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMgYW4gYXJjaGl0ZWN0dXJlIOKAkyBhbGwNCmRldmljZXMg aGF2ZSBhIGxpY2Vuc2UsIGFuZCB0aGF0IHNvbWUganVzdCBoYXBwZW4gdG8gaGF2ZSBwYWlkIG1v bmV5IG9yIGJlZW4NCmdpdmVuIGEgbW9ub3BvbHkgYnkgYW4gYXV0aG9yaXR5IHRvIGhhdmUgYSBz aW5nbGUgdXNlciBsaWNlbnNlLiZuYnNwOyBTb21lIG9mDQp0aGUgbGljZW5zZXMgY2FuIGJlIHNo b3J0IGxpdmVkIGFuZCBuZWVkIHRvIGJlIGRpc3RyaWJ1dGVkLiZuYnNwOyBTb21lIGFyZQ0KaW1w bGljaXQgYmFzZWQgb24gdGhlIGNvbmZvcm1hbmNlIHRlc3RzIHRoYXQgdGhlIGRldmljZSBtdXN0 IHBhc3MuJm5ic3A7IFRoZQ0KbGljZW5zZXMgdGhhdCBwYXdzIGlzIGFkZHJlc3NpbmcgYXJlIG9u ZXMgdGhhdCBjYW4gYmUgbW9kaWZpZWQgYnkgc29tZSBmb3JtIG9mDQpJUCBjb21tdW5pY2F0aW9u cyAoYWthIGRhdGFiYXNlIGxvb2t1cCkuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tn cm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+U28g4oCmIGFzIGFuIGF0dGVtcHQg Zm9yIHRleHQg4oCmLjwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFu PjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0 ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5XaGl0ZXNwYWNlIGxpY2Vuc2VkOjwvc3Bhbj48L2I+ PHNwYW4NCmNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPk9wZXJhdGlv bg0Kb2YgUkYgZGV2aWNlcyBpbiBhIGZyZXF1ZW5jeSBiYW5kIHdoZXJlIGF1dGhvcml6ZWQgb3Bl cmF0aW9uIGlzIGRldGVybWluZWQNCmJhc2VkIG9uIGEgZGV2aWNlcyBsb2NhdGlvbiwgZGV2aWNl IHR5cGUgYW5kIG9wZXJhdGluZyB0aW1lIHBlcmlvZC4mbmJzcDsNCkNvb3JkaW5hdGlvbiBvZiB0 aGlzIG1vZGUgb2Ygb3BlcmF0aW9uIHdpbGwgdHlwaWNhbGx5IGJlIG1hbmFnZWQgYnkgZGF0YWJh c2VzDQp0cmFja2luZyBMaWNlbnNlZCBvcGVyYXRpb24gaW4gdGhlIHNhbWUgYmFuZHMuPC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRl Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9y OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QYXVsPC9zcGFuPjxz cGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3Vu ZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojN0Y3RjdGJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxl PSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOiM3RjdGN0YnPlBhdWwgQS4gTGFtYmVydCB8IE1hcnZlbGwNClNlbWljb25kdWN0b3IgfCAr MS02NTAtNzg3LTkxNDE8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbic+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IFJvc2VuLA0KQnJpYW4gW21haWx0bzpCcmlhbi5Sb3Nl bkBuZXVzdGFyLmJpel0gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgSmFudWFyeSAzMCwgMjAx MiAyOjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBQYXVsIExhbWJlcnQ8YnI+DQo8Yj5DYzo8L2I+IE5h bmN5IEJyYXZpbjsgTWFseWFyLCBKb2huIFA7IHBhd3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtwYXdzXSBEaXNjdXNzaW9uIG9uICdsaWNlbnNlLWV4ZW1wdCcgdnMgJ3VubGlj ZW5zZWQnPC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6Ymxh Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2Nv bG9yOmJsYWNrJz5VaCwNCndoaXRlc3BhY2UgZGV2aWNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0n Y29sb3I6YmxhY2snPlNvcnJ5LA0KY291bGRuJ3QgcmVzaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBz dHlsZT0nY29sb3I6YmxhY2snPk9uIEphbg0KMzAsIDIwMTIsIGF0IDU6NDQgUE0sIFBhdWwgTGFt YmVydCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdDti YWNrZ3JvdW5kOndoaXRlJz48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+V2hhdCBpcyB0aGUgY29ycmVjdCB0ZXJtIGZvcg0Kc29tZXRoaW5nIHRoYXQgaXMg b3BlcmF0aW5nIGFzIGEgbGljZW5zZS1leGVtcHQgZGV2aWNlIOKAkyB5ZXQgaGFzIGJlZW4gZ2l2 ZW4NCnNob3J0IHRlcm0gYXV0aG9yaXphdGlvbiB0byBzaGFyZSBhIGNoYW5uZWwgd2l0aCBvdGhl ciBsaWNlbnNlLWV4ZW1wdCBkZXZpY2VzDQpiYXNlZCBvbiBhIHF1ZXJ5IHRvIGEgcmVnaW9uYWwg YXV0aG9yaXRpZXMgZGF0YWJhc2UgaW4gYSBwb3J0aW9uIG9mIHNwZWN0cnVtDQp0aGF0IG1heSBh bHNvIGluY2x1ZGUgbGljZW5zZWQgb3IgbGlnaHQtbGljZW5zZWQgZGV2aWNlcyBhdCBvdGhlciB0 aW1lcyBvciBpbg0Kb3RoZXIgYXJlYXMuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+ PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5QYXVsPC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUn PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzdGN0Y3Ric+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6 YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rp dj4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ow0KYm9yZGVyLWNvbG9yOmluaXRpYWwnPg0KDQo8 ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRp diBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDMuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW47DQpib3JkZXItY29sb3I6aW5pdGlhbCBpbml0aWFsJz4N Cg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4NCmNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2Nv bG9yOmJsYWNrJz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGENCmhy ZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzLWJv dW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4NCmNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L3NwYW4+W21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddPHNwYW4N CmNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGI+ T24gQmVoYWxmIE9mPHNwYW4NCmNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFj ZT4mbmJzcDs8L3NwYW4+PC9iPkdlcmFsZCBDaG91aW5hcmQ8YnI+DQo8Yj5TZW50OjwvYj48c3Bh biBjbGFzcz15aXY5MTM2MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPk1v bmRheSwNCkphbnVhcnkgMzAsIDIwMTIgMzozMCBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFz cz15aXY5MTM2MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPjxhDQpocmVm PSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9eWl2OTEzNjI3MTEyYXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5bcGF3c10NCkRpc2N1c3Npb24gb24gJ2xpY2Vuc2UtZXhl bXB0JyB2cyAndW5saWNlbnNlZCc8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5BbGwsPC9zcGFuPjxzcGFuDQpz dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwv ZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJz cDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7 Y29sb3I6bmF2eSc+SGVyZSBpcyBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZQ0KdGVybXM6PC9zcGFu PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rp dj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2 eSc+Jm5ic3A7PC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOm5hdnknPkxpY2Vuc2VkOjwvc3Bhbj48L2I+PHNwYW4NCmNsYXNzPXlp djkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPlNwZWN0cnVtIHRoYXQNCmlzIGFjcXVp cmVkIGJ5IGFuIG9wZXJhdG9yIG92ZXIgYSBnaXZlbiBzZXJ2aWNlIGFyZWEgZm9yIGEgZ2l2ZW4g dGltZSBwZXJpb2QuDQombmJzcDtUaGlzIGlzIHVzdWFsbHkgZG9uZSB0aHJvdWdoIGF1Y3Rpb25z ICh0aGluayBvZiB0aGUgVGVsY29zKSwgYmVhdXR5DQpjb250ZXN0LCBmaXJzdC1jb21lIC8gZmly c3Qtc2VydmVkIG9yIGJ5IGdvdmVybm1lbnQgYWxsb2NhdGlvbiAoZS5nLiwgcHVibGljDQpzZXJ2 aWNlKS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91 bmQ6d2hpdGUnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+TGlnaHRseSBsaWNlbnNlZDo8L3NwYW4+ PC9iPjxzcGFuDQpjbGFzcz15aXY5MTM2MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5TcGVj aWFsDQpjYXNlIHdoZXJlIHRoZWZyZXF1ZW5jeSBhbGxvY2F0aW9uIGlzIGRvbmUgdGhyb3VnaCBm aXJzdC1jb21lIC8gZmlyc3Qtc2VydmVkDQpwcm9jZXNzIGZvciBhIGdpdmVuIHRpbWUgZnJhbWUg b3ZlciBhIHJlbGF0aXZlbHkgbGltaXRlZCBzZXJ2aWNlIGFyZWEuIFRoZQ0KYW5udWFsIGxpY2Vu c2UgZmVlIGlzIHVzdWFsbHkgc21hbGwgdG8gZmFjaWxpdGF0ZSB0aGUgZGVwbG95bWVudCBvZiBh IHNlcnZpY2UgdGhhdA0Kd291bGQgbm90IG5vcm1hbGx5IGJlIGVjb25vbWljYWxseSBhdHRyYWN0 aXZlLiAmbmJzcDtTbWFsbCBsb2NhbCBvcGVyYXRvcnMNCndvdWxkIGJlIGludGVyZXN0ZWQgYnkg dGhpcyAoZS5nLiwgcnVyYWwgYnJvYWRiYW5kIGluPHNwYW4NCmNsYXNzPXlpdjkxMzYyNzExMmFw cGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+Q2FuYWRhKSBhbmQgbm90IGJpZyBUZWxj b3MNCnRoYXQgd291bGQgbm9ybWFsbHkgd29yayB3aXRoIGZ1bGwgbGljZW5zaW5nIHRocm91Z2gg YXVjdGlvbiBvdmVyIGxhcmdlIHNlcnZpY2UNCmFyZWFzLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29s b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48 c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpu YXZ5Jz5MaWNlbnNlLWV4ZW1wdDo8L3NwYW4+PC9iPjxzcGFuDQpjbGFzcz15aXY5MTM2MjcxMTJh cHBsZS1jb252ZXJ0ZWQtc3BhY2U+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5PcGVyYXRpb24NCm9mIFJGIGRldmljZXMgaW4gYSBmcmVx dWVuY3kgYmFuZCB3aGVyZSBubyBmb3JtYWwgbGljZW5zaW5nIHByb2Nlc3MgaXMgbmVlZGVkDQpz dWNoIGFzIGluIHRoZSAyLjQgR0h6IElTTSBiYW5kLiBJbiB0aGU8c3Bhbg0KY2xhc3M9eWl2OTEz NjI3MTEyYXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj5VU0EsIHRoaXMgdGVybSBp cyB1c2VkIGZvcg0KYSBzcGVjaWZpYyB0eXBlIG9mIG9wZXJhdGlvbi4gVGhlIEZDQyBzaG91bGQg YmUgY29udGFjdGVkIHRvIGNsYXJpZnkgaXQuPC9zcGFuPjxzcGFuDQpzdHlsZT0nY29sb3I6Ymxh Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdi YWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48c3Bhbg0K c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8 L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5V bmxpY2Vuc2VkOjwvc3Bhbj48L2I+PHNwYW4NCmNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZl cnRlZC1zcGFjZT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4N CnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi O2NvbG9yOm5hdnknPklsbGVnYWwgb3BlcmF0aW9uDQpvZiBhbiBSRiBkZXZpY2UgdGhhdCBjYW4g dHJhbnNtaXQgaW4gYSBmcmVxdWVuY3kgYmFuZCB3aXRob3V0IGEgZHVseSBpc3N1ZWQNCmxpY2Vu c2UuICZuYnNwO0luIHRoZTxzcGFuIGNsYXNzPXlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L3NwYW4+VVNBLA0KdGhpcyB0ZXJtIGlzIHVzZWQgdG8gbWVhbiDigJxsaWNl bnNlLWV4ZW1wdCwmcXVvdDsgc2VlIGFib3ZlLjwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJs YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n YmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz4mbmJzcDs8L3NwYW4+PHNwYW4N CnN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0K PC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+VG8g bXkga25vd2xlZGdlLCB0aGUgdGVybQ0K4oCcdW5saWNlbnNlZOKAnSBpcyB1c2VkIG9ubHkgaW4g dGhlPHNwYW4gY2xhc3M9eWl2OTEzNjI3MTEyYXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj5VU0E8c3Bhbg0KY2xhc3M9eWl2OTEzNjI3MTEyYXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj50byBkZXNjcmliZSBhIGxlZ2FsDQpvcGVyYXRpb24gYmVjYXVzZSB0aGUgdGVy bSDigJxsaWNlbnNlLWV4ZW1wdOKAnSBoYXMgYmVlbiB1c2VkIGZvciBhbm90aGVyIHNwZWNpZmlj DQpwdXJwb3NlLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwvc3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNr Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFj a2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz5TaW5jZSB0aGUgUEFXUyBhZGRyZXNz ZXMgdGhlDQppbnRlcmZhY2UgdG8gdGhlIGRhdGFiYXNlIGZvciB0aGUgaW50ZXJuYXRpb25hbCBt YXJrZXQsIGl0IHNob3VsZCByZWx5IG9uIHRoZQ0KZGVmaW5pdGlvbiBvZiB0aGUgdGVybXMgcmVj b2duaXplZCBieSB0aGUgSVRVLVIuIEkgd291bGQgc3VnZ2VzdCB0aGUgdXNlIG9mDQrigJhsaWNl bnNlZOKAmSBhbmQg4oCYbGljZW5zZS1leGVtcHTigJkgd2l0aCBhIGZvb3Rub3RlIGluZGljYXRp bmcgdGhhdCB0aGUgdGVybQ0K4oCYdW5saWNlbnNlZOKAmSBpcyB1c2VkIGluIHRoZSBVU0EgaW5z dGVhZCBvZiB0aGUgdXN1YWwg4oCYbGljZW5zZS1leGVtcHTigJkuPC9zcGFuPjxzcGFuDQpzdHls ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPiZuYnNwOzwv c3Bhbj48c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoN CjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nYmFja2dyb3VuZDp3aGl0ZSc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xv cjpuYXZ5Jz5HZXJhbGQ8L3NwYW4+PHNwYW4NCnN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286 cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTMuNXB0Ow0KZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6YmxhY2snPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvc3Bhbj48 c3Bhbg0Kc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2 Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2JhY2tncm91bmQ6d2hpdGUnPjxzcGFuIHN0eWxlPSdjb2xv cjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDsNCmZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnBhd3MgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzQGll dGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3 czwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdiYWNrZ3JvdW5kOndoaXRlJz48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4N Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlJz48c3Bhbg0Kc3R5bGU9J2Nv bG9yOmJsYWNrJz48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnBhd3MgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnBhd3NA aWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwv ZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_7BAC95F5A7E67643AAFB2C31BEE662D01567643194SCVEXCH2marve_-- From scott.probasco@nokia.com Tue Jan 31 10:56:40 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0856811E8075 for ; Tue, 31 Jan 2012 10:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDHQWLNR9H9x for ; Tue, 31 Jan 2012 10:56:38 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 64AF921F85CD for ; Tue, 31 Jan 2012 10:56:36 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0VIuUmj012872 for ; Tue, 31 Jan 2012 20:56:35 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 20:56:31 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Tue, 31 Jan 2012 19:56:30 +0100 From: To: Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4EoKmZU77rKmJUG0BaZYFFCPnA== Date: Tue, 31 Jan 2012 18:56:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.163.149] Content-Type: multipart/alternative; boundary="_000_CB4D7595FC36scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2012 18:56:31.0617 (UTC) FILETIME=[0BBEFF10:01CCE04A] X-Nokia-AV: Clean Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 18:56:40 -0000 --_000_CB4D7595FC36scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions, awar= d (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A primary user of white space spectrum which is afforded protection against interference by secondary users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specific location and time. This spectrum is then assigned by location regulati= ons for use as licensed-exempt spectrum under control of a white space data= base. White Space Device (WSD) A device which is a secondary user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limits imposed by this license-exempt ruling, his oper= ation is therefore illegal and he is then considered to be running an =93un= licensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB4D7595FC36scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5F078CAF409FEF42BB138A2EF5120550@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi,

I changed the subject line from " Re: [paws] Discussion on 'licen= se-exempt' vs 'unlicensed'  ". Here I try to propose some changes= to the draft based on the email discussion.

Below is a copy of chapter 2.2. Terminology. I have inserted new terms= for 'licensed' and 'license-exempt' and made changes to the term 'white sp= ace'. I have tried to work from the perspective that the document should ac= curately explain the subject with aim that a reader can understand the use cases and the subsequent requirem= ents. No doubt we could include much more text on this topic of spectrum al= location, assignment, licensing and usage.

I hope this captures the key points of the discussion. Please do reply= if something is still missing.

Kind Regards,
Scott


2.2.  Terminology

   Database

      In the context of white space and cognitive = radio technologies,
      the database is an entity which contains cur= rent information about
      available spectrum at any given location and= other types of
      information.

   Device ID

      A unique number for each master device and s= lave device that
      identifies the manufacturer, model number an= d serial number.

<Insert>
   Licensed Spectrum

      Spectrum that is acquired by an operator ove= r a given service area
      for a given time period.  This is usual= ly done through auctions, award
      (beauty contest), acquisition from secondary= market, company merger &
      acquisition,  first-come / first-served= or by government allocation
      (e.g., public service).
 
   License-exempt Spectrum

      Spectrum that is not assigned to any specifi= c user. One example is the 2.4 Ghz ISM band, where RF devices
      operate without a formal licensing process. = In the USA, license-exempt spectrum is
      Typically referred to as "unlicensed&qu= ot; spectrum. In this document the terms
      license-exempt and unlicensed are used inter= changeably.

</Insert>

   Location Based Service

      An application or device which provides data= , information or
      service to a user based on their location.

   Master Device

      A device which queries the WS Database to fi= nd out the available
      operating channels.

   Protected Entity

      A primary user of white space spectrum which= is afforded
      protection against interference by secondary= users (white space
      devices) for its use in a given area and tim= e.

   Protected Contour

      The exclusion area for a Protected Entity, h= eld in the database
      and expressed as a polygon with geospatial p= oints as the vertices.

   Slave Device

      A device which uses the spectrum made availa= ble by a master
      device.

   TV White Space

      TV white space refers specifically to radio = spectrum which has
      been allocated for TV broadcast, but is not = occupied by a TV
      broadcast, or other licensed user (such as a= wireless microphone),
      at a specific location and time.

   White Space

      Radio spectrum which has been allocated <= Delete>for some primary use</Delete><Insert>and assigned for= licensed use</Insert>, but
      is not fully occupied by that <Delete>= primary use</Delete><Insert> licensed use </Insert> at a = specific location
      and time. <Insert>This spectrum is the= n assigned by location regulations for use as licensed-exempt spectrum unde= r control of a white space database.</Insert>

   White Space Device (WSD)

      A device which is a secondary user of some p= art of white space
      spectrum.  A white space device can be = an access point, base
      station, a portable device or similar.  = ;In this context, a white
      space device is required to query a database= with its location to
      obtain information about available spectrum.=



From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca<= /a>>
Date: Tue, 31 Jan 2012 10:07:30 -05= 00
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: Re: [paws] Discussion on '= license-exempt' vs 'unlicensed'

Nancy,

 

This is not that simple.  In fact= , the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to mor= e than one thing.

 

If the qualifier applies to a frequenc= y band, different options exist. As an example, in the ITU-R context, an = =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its= use.  It is therefore un-allocated to a specific service so far and t= hus it is an =93unlicensed=94 frequency band<= /b>. Once the ITU-R allocates this band to one or many services on a primar= y or secondary basis, then the administrations can thendecide under what ki= ng of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis of= licensed operation (with different options to do the assignment: auction, = first come/first served, etc.) or allow operation with an exemption of li= censes, thus =93license-exempt=94such as in the 2.4 GHz ISM band= . This is also called =93unlicensed=94 in the USA.

 

If the qualifier applies to an operati= on, the operation can be exempt of license by the local administration, thu= s a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a= licensed band for which he has no license or in a license-exempt band for = which he does not meet the requirements such as operating according to the type of operation for which the band is= exempted from a license or he operates outside the technical limits impose= d by this license-exempt ruling, his operation is therefore illegal and he = is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to the transm= ission device, such device may be a =93license-exempt=94 device = if its operation does not require a specific license or registration with t= he local administration such as TV receivers of Wi-Fi devices in the 2.4 GH= z ISM band.  However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eB= ay and operates it, this is then an illegal device in the country and id de= -facto an =93unlicensed=94 device since it has not passed through the norma= l certification process.

 

Note that a =93license-exempt=94 devic= e still has to go through a certification process and meet the limits impos= ed by the local regulator for the =93license-exempt=94 operation in the given frequency band whereas= an =93unlicensed=94 device may not pass the certification process since it= has not been licensed to operation in the country.

 

This is why the qualifier =93unlicense= d=94 has to be treated with care and the footnote will need to be crafted v= ery carefully.

 

With respect to your second point, if = an administration only allows =93licensed=94 operation, the situation will = be much simpler to manage since specific conditions will be attached to these licenses.

 

Gerald

 

From: Nanc= y Bravin [mailto:nbravin@earthlink= .net]
Sent: Tuesday, 31 January, 2= 012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 

Gabor and Gerald, 

Since we are dealing on a global basis, can there a footnote to &qu= ot;unlicensed" we can use to indicate that "according to each cou= ntries regulatory requirements"  

How to get around the fact that some Countries are or will be "= ;licensed only" by their gov'ts?  Thanks=

Nancy

On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote:



Gabor,=

 =

I agree with your proposal.  This= seems to be reasonable.  However one needs to be careful with the word= =91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 =

Gerald=

 =

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, 20= 12 17:49
To: gerald.chouinard@symp= atico.ca; paws@ietf.org
Subject: RE: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 

= These lo= ok to be very precise definitions, however in everyday use I rarely hear pe= ople referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used. =

= &n= bsp;

= Therefor= e, may I suggest that the draft will include the following statement:=

= &n= bsp;

= The term= s unlicensed and license-exempt spectrum are used in this document intercha= ngeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as t= he ISM band.

= &n= bsp;

-          Gabor

= &n= bsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chou= inard
Sent: Monday, January 30, 20= 12 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion o= n 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understanding of the terms:=

 

Licensed: Spectrum that is acquired by an operator over a given service area for a g= iven time period.  This is usually done through auctions (think of the= Telcos), beauty contest, first-come / first-served or by government alloca= tion (e.g., public service).

 

Lightly licensed: Special case where thefrequency allocation is done through first-come / fi= rst-served process for a given time frame over a relatively limited service= area. The annual license fee is usually small to facilitate the deployment= of a service that would not normally be economically attractive.  Small local operators would be intereste= d by this (e.g., rural broadband in Canada) and not big Telcos that would normally = work with full licensing through auction over large service areas.

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing proc= ess is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of o= peration. The FCC should be contacted to clarify it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a frequency band wi= thout a duly issued license.  In the USA, this term is used to mean =93license-exemp= t," see above.

 

To my knowledge, the term =93unlicense= d=94 is used only in the USA to describe a legal operation because the t= erm =93license-exempt=94 has been used for another specific purpose.

 =

Since the PAWS addresses the interface= to the database for the international market, it should rely on the defini= tion of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exe= mpt=92 with a footnote indicating that the term =91unlicensed=92 is used in= the USA instead of the usual =91license-exempt=92.<= u1:p>

 =

Gerald

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

 

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB4D7595FC36scottprobasconokiacom_-- From paul@marvell.com Tue Jan 31 11:15:37 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70711E8080 for ; Tue, 31 Jan 2012 11:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErQONkvPlS8D for ; Tue, 31 Jan 2012 11:15:36 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id DF23F11E8072 for ; Tue, 31 Jan 2012 11:15:35 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTyg90fAOV3LwYo3N6nQaNwQd7mlXoJZS@postini.com; Tue, 31 Jan 2012 11:15:35 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 31 Jan 2012 11:13:52 -0800 From: Paul Lambert To: Stephen Farrell , "Basavaraj.Patil@nokia.com" , "paws@ietf.org" Date: Tue, 31 Jan 2012 11:13:51 -0800 Thread-Topic: [paws] Threats, Services and Predicatable Availability Thread-Index: Aczfp9nmQhS/QzK5S1GYIKp0Vp743QAorNqg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D015676431B1@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567642F92@SC-VEXCH2.marvell.com> <4F272932.5040802@cs.tcd.ie> In-Reply-To: <4F272932.5040802@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Threats, Services and Predicatable Availability X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 19:15:37 -0000 One more observation on threat modeling. Discovering the database is a ser= vice: 4) Support discovery of all authorized databases services for a geographic = region. Associated threat event would be: - Modification of paws protocol messages in transit to prevent discovery o= f authorized databases When there are multiple authorized database services we need to make sure t= hat all authorized services are available to end devices. =20 This implies a trust hierarchy with the regulatory authority (Gov based) as= a root for a region. New regions are not going to be easy to add ... whic= h is good since any new region also requires some level of regional conform= ance. Paul >-----Original Message----- >From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >Sent: Monday, January 30, 2012 3:35 PM >To: Paul Lambert >Cc: Basavaraj.Patil@nokia.com; paws@ietf.org >Subject: Re: [paws] Threats, Services and Predicatable Availability > > >Sorry to keep on on the same thing, but it doesn't seem >to be resonating much;-) > >The charter says: "Robust privacy and security mechanisms >are needed..." > >I'm guessing its possible an analysis starting from your >suggestions below should produce a good result wrt security >but maybe less so for privacy (which is less well >understood by us all). > >How about adding "Prevent unnecessary exposure of >personally identifying information (PII)" ? > >Note that the above could me met via encryption of >PII, (with possibly high-cost key management) or by >just not sending PII when you don't need to which is >fairly cheap if you're not forced by regulation to >send it. (Since some devices presumably are not >personally identifying but others are, then maybe >there's a simple enough answer in the end...) > >S > >On 01/30/2012 10:29 PM, Paul Lambert wrote: >> >> Hi Raj, >> >>> Do you have any proposals or text w.r.t the threat model writeup? >Also >>>from an IETF perspective regarding threat models, please see Peter's >>> email: http://www.ietf.org/mail- >archive/web/paws/current/msg00592.html >>> >>> -Raj >> >> I'll spend a little time formalizing the ideas I submitted below. >However, "threats" are part of a complete set of requirements and >looking at the current proposal, I feel we need to clarify the service >that we offer before we can say what are real threats. Specifically, >the threat: >> >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets to >a >>>>> white space database. >> >> This is not a threat as worded... but why? >> >> We need to define what we offer, and then things that prevent or break >these offered services are potential risks that can be mapped to >threats. As a start, I propose (which I hope is mostly in line with the >use cases) two main services with some subtopics: >> >> 1) Prevent Interference of License-exempt Use with Licensed Operation > >> - Support changes in channel, time Period and region for licensed >operation >> - Support predictable availability of licensed channels >> - Support the ability to disable specific vendor/model-types from >operation when >> they are determined to be causing interference >> 2) Enable Authorized Channel Utilization for License-exempt Operation > >> - Facilitate fixed use of channels >> - Facilitate mobile use of channels >> - Facilitate indoor use of channels >> - Support predictable availability of license-exempt channels >> - Support changing of authorized channels to prevent interference >with licensed usage >> >> So, threat event is something that has a result of preventing the >promised services. The threat event either causes unapproved >interference with licensed operation, or it prevents White Space >"license-exempt" operation. >> >> The "Support Predictable Availability" is something new I'd like to >introduce for discussion. There needs to be a expectation that once you >are using a channel that your use will not be terminated abruptly in an >unanticipated manner. Right now - we are creating mechanism to quickly >cutoff a device for any reason at all (for the use case of mobile >microphones). This is actually supposed to be a predictable event with >some type of scheduling. An license-exempt devices needs to be able to >determine how long it might operate under the regulations in a >particular channel/region. Building a system where you never know when >your communications might get cut off seems like a bad idea. >> >> >> >> Paul >> >> >>> >>> On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >>> >>>> It's good to have requirements based on such an analysis. This is >an >>>> interesting start, but we may be mixing threats, vulnerabilities and >>>> mechanisms. >>>> >>>> Threats are typically tied to an actor ... human or not. I'm not >sure >>>> it's worth going hard over to something like the NIST 800-30 >>> definitions >>>> of threats, but within this framework the threats are Governments, >>>> disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>>> quickly to the threat event and specifics of an attack, but should >at >>>> least expand threats to include natural events and connectivity >>> problems. >>>> Robustness or emergency modes might be interesting to consider. >>>> >>>> We also have a problem in this analysis of perspective - are we >>>> considering threats as viewed from regulatory agency or the end >device >>>> owner or both. We should consider both - but they are contradictory >>>> perspectives. Users want continuity of service. Governments (the >>>> regulators) want control of the airwaves. >>>> >>>> Most of the real threats that we have are nearly impossible to >prevent >>> at >>>> the protocol level. It's still worth examining the threats to see >>> where >>>> we stand. >>>> >>>> On the current document threats: >>>> >>>>> o It is assumed that the master device or the white space database >>>>> have NOT been compromised from a security standpoint. >>>>> >>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>> The master device needs to authenticate itself with the >white >>>>> space database prior to requesting channel information. The >>>>> attacker may try to get access to the secrets of the master >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets to >a >>>>> white space database. >>>> This does not seem consistent with the prior statement of "not >>>> compromised". >>>> Restatement >>>> >>>> Threat: User modifies a device to masquerade as another valid >certified >>>> device. >>>> >>>> This is an interesting case where threat/vulnerability/risk play >>>> together. The FCC or other regulatory agencies want traceability of >>>> devices. If a user wants to run a rogue radio, there is no reason >to >>>> access the database (low risk - no payoff). The only reason this >would >>>> be an interesting attack might be to avoid tracking and have some >>>> anonymity. >>>> >>>>> Threat 2: Spoofed white space database >>>>> A master device discovers a white space database(s) thru >which >>>>> it can query for channel information. The master device >needs >>>>> to ensure that the white space database with which it >>>>> communicates with is an authentic entity. The white space >>>>> database needs to provide its identity to the master device >>>>> which can confirm the validity/authenticty of the database. >An >>>>> attacker may attempt to spoof a white space database and >>>>> provide responses to a master device which are malicious and >>>>> result in the master device causing interference to the >primary >>>>> user of the spectrum. >>>> >>>> I think this is two types of threat events: >>>> - malicious denial of service or intentional interference with >>> incumbents >>>> - impersonation of white space database to enable operation of a >>> device >>>> that may >>>> not otherwise be possible (blocked device, unallocated channels). >>>> This may or may not >>>> interfere with incumbent devices >>>> >>>>> Threat 3: Modifying a query request >>>> ... >>>> >>>>> Threat 4: Modifying a query response >>>> Seems like these two could be lumped together ...MiTM modifies >protocol >>>> messages to: >>>> - deny service >>>> - interfere with incumbents >>>> - provide unauthorized channel usage (most likely risk IMHO) >>>> >>>>> Threat 5: Using query response information >>>>> An attacker may be a master device which is not certified >for >>>>> use by the relevant regulatory body. The attacker may listen >to >>>>> the communication between a valid master device and white >space >>>>> database and utilize the information about available >channels >>>>> in the response message by utilizing those channels. The >result >>>>> of such an attack is unauthorized use of channels by a >master >>>>> device which is not certified to operate. >>>> As stated this is a mechanism - a clearer statement might be. >>>> >>>> Threat: Unauthorized use of channels by an uncertified device. >>>> >>>> Anyone can already go to a database and find available channels. If >a >>>> device can operate without going to the database there is nothing >that >>>> paws can do to stop it operating in available or non-available >>> channels. >>>> >>>> Just to get some discussion going -here's a couple more possible >>> threats.. >>>> >>>> Threat: Third party tracking of white space device location >>>> Likely a valuable commodity to sell for advertizing with no >>> technical >>>> design or policy for privacy >>>> Threat: Database owner termination of device service for reasons >other >>>> than incumbent protection >>>> >>>> >>>> >>>> Paul >>>> >>>> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From gerald.chouinard@sympatico.ca Tue Jan 31 11:42:06 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2A311E812C for ; Tue, 31 Jan 2012 11:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=1.511, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFlY47N5z-mK for ; Tue, 31 Jan 2012 11:41:40 -0800 (PST) Received: from blu0-omc3-s24.blu0.hotmail.com (blu0-omc3-s24.blu0.hotmail.com [65.55.116.99]) by ietfa.amsl.com (Postfix) with ESMTP id A524411E811D for ; Tue, 31 Jan 2012 11:41:39 -0800 (PST) Received: from BLU0-SMTP4 ([65.55.116.74]) by blu0-omc3-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 11:41:38 -0800 X-Originating-IP: [174.95.243.143] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.243.143]) by BLU0-SMTP4.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 11:41:36 -0800 From: Gerald Chouinard To: , References: Date: Tue, 31 Jan 2012 14:41:36 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01CCE026.70483060" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM4EoKmZU77rKmJUG0BaZYFFCPnJYm3jmg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 31 Jan 2012 19:41:37.0229 (UTC) FILETIME=[586A9FD0:01CCE050] Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 19:42:07 -0000 ------=_NextPart_000_00D4_01CCE026.70483060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operation where the two first types of services are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white space allocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions, award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A primary user of white space spectrum which is afforded protection against interference by secondary users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specific location and time. This spectrum is then assigned by location regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondary user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_00D4_01CCE026.70483060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott,

Great proposal.  However, I am = still a bit nervous about the definitions of “Protected Entity” and = “White Space Devices (WSD)” where the notion of secondary use is included.  The = secondary status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic operation = where the two first types of services are not being used.  The use of = “lower priority opportunistic” service rather than “secondary” service = would be preferable to describe white space allocations.

 

Gerald =

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 = January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Hi,=

 

I changed the = subject line from " Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'  ". Here I try to propose some changes to the draft based on = the email discussion.

 

Below is a = copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this = captures the key points of the discussion. Please do reply if something is still missing.

 

Kind = Regards,

Scott

 

 

2.2. =  Terminology

 

   = Database

 

   =    In the context of white space and cognitive radio = technologies,

   =    the database is an entity which contains current information = about

   =    available spectrum at any given location and other types = of

   =    information.

 

   = Device ID

 

   =    A unique number for each master device and slave device = that

   =    identifies the manufacturer, model number and serial = number.

 

<Insert>=

   = Licensed Spectrum

 

   =    Spectrum that is acquired by an operator over a given service = area

   =    for a given time period.  This is usually done through = auctions, award

   =    (beauty contest), acquisition from secondary market, company = merger &

   =    acquisition,  first-come / first-served or by government = allocation

   =    (e.g., public service).

 

   License-exempt Spectrum

 

   =    Spectrum that is not assigned to any specific user. One example is = the 2.4 Ghz ISM band, where RF devices

   =    operate without a formal licensing process. In the = USA, license-exempt spectrum is

   =    Typically referred to as "unlicensed" spectrum. In this document the terms

   =    license-exempt and unlicensed are used = interchangeably.

 

</Insert>= ;

 

   = Location Based Service

 

   =    An application or device which provides data, information = or

   =    service to a user based on their = location.

 

   = Master Device

 

   =    A device which queries the WS Database to find out the = available

   =    operating channels.

 

   = Protected Entity

 

   =    A primary user of white space spectrum which is = afforded

   =    protection against interference by secondary users (white = space

   =    devices) for its use in a given area and = time.

 

   = Protected Contour

 

   =    The exclusion area for a Protected Entity, held in the = database

   =    and expressed as a polygon with geospatial points as the = vertices.

 

   = Slave Device

 

   =    A device which uses the spectrum made available by a = master

   =    device.

 

   = TV White Space

 

   =    TV white space refers specifically to radio spectrum which = has

   =    been allocated for TV broadcast, but is not occupied by a = TV

   =    broadcast, or other licensed user (such as a wireless = microphone),

   =    at a specific location and time.

 

   = White Space

 

   =    Radio spectrum which has been allocated <Delete>for some = primary use</Delete><Insert>and assigned for licensed = use</Insert>, but

   =    is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a = specific location

   =    and time. <Insert>This spectrum is then assigned by location regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   = White Space Device (WSD)

 

   =    A device which is a secondary user of some part of white = space

   =    spectrum.  A white space device can be an access point, = base

   =    station, a portable device or similar.  In this context, a = white

   =    space device is required to query a database with its location = to

   =    obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 = 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Nancy,

 

This is not that simple.  In = fact, the qualifiers “license-exempt” and “unlicensed” = can apply to more than one thing.

 

If the qualifier applies to a = frequency band, different options exist. As an example, in the ITU-R context, an “unlicensed” band is typically a new band, say in the 300 = GHz, for which no request has been made for its use.  It is therefore un-allocated to = a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this band to one or = many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will ‘assign’ this = band foroperation. They may decide to allow the use of the band on the basis of licensed = operation (with different options to do the assignment: auction, first come/first = served, etc.) or allow operation with an = exemption of licenses, thus “license-exempt”such as in the 2.4 = GHz ISM band. This is also called “unlicensed” in the USA.

 

If the qualifier applies to an = operation, the operation can be exempt of license by the local administration, thus = a “license-exempt” = operation. If, however, someone decides to start an RF transmission operation in a licensed band = for which he has no license or in a license-exempt band for which he does = not meet the requirements such as operating according to the type of operation = for which the band is exempted from a license or he operates outside the technical = limits imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an “unlicensed” = operation.

 

If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license = or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone smuggles a = device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id = de-facto an “unlicensed” device since it has not passed through the = normal certification process.

 

Note that a = “license-exempt” device still has to go through a certification process and meet the limits imposed by = the local regulator for the “license-exempt” operation in the = given frequency band whereas an “unlicensed” device may not pass the = certification process since it has not been licensed to operation in the = country.

 

This is why the qualifier = “unlicensed” has to be treated with care and the footnote will need to be crafted very = carefully.

 

With respect to your second point, = if an administration only allows “licensed” operation, the = situation will be much simpler to manage since specific conditions will be attached to these = licenses.

 

Gerald

 

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 = January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and = Gerald, 

Since we are dealing on a global = basis, can there a footnote to "unlicensed" we can use to indicate = that "according to each countries regulatory requirements" =  

How to get around the fact that = some Countries are or will be "licensed only" by their gov'ts? =  Thanks

Nancy

On Jan 30, 2012, at 4:13 PM, = Gerald Chouinard wrote:




Gabor,

 

I agree with your proposal.  Thisseems to be reasonable.  However one needs to be careful with = the word‘unlicensed’ which may mean ‘illegal’ = operation of an RF device in many administrations.

 

Gerald

 

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] =
Sent: Monday, 30 January, = 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] = Discussion on 'license-exempt' vs = 'unlicensed'

 

These look = to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as ‘license-exempt’, in most cases the = term ‘unlicensed-band’ is used. =

 =

Therefore, = may I suggest that the draft will include the following = statement:

 =

The terms = unlicensed and license-exempt spectrum are used in this document interchangeably = and refer to a spectrum in which no formal licensing process is needed for RF = devices to operate in, such as the ISM = band.

 =

-          Gabor<= /u3:p>

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of ext Gerald = Chouinard
Sent: Monday, January 30, = 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] = Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

Here is my understanding of the = terms:

 

= Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

= Lightly licensed: Special case = where thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. The annual = license fee is usually small to facilitate the deployment of a service that would = not normally be economically attractive.  Small local operators would = be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through = auction over large service areas.

 

= License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

 

= Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

 

To my knowledge, the term = “unlicensed” is used only in the USA to describe a legal operation because the term = “license-exempt” has been used for another specific = purpose.

 

Since the PAWS addresses the = interface to the database for the international market, it should rely on the = definition of the terms recognized by the ITU-R. I would suggest the use of = ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term = ‘unlicensed’ is used in the USA instead of the usual = ‘license-exempt’.

 

Gerald

__________________________________= _____________
paws mailing list
paws@ietf.org
https://www.ietf.org/= mailman/listinfo/paws


 

_________________________________= ______________ paws mailing list paws@ietf.org https://www.ietf.org/= mailman/listinfo/paws

------=_NextPart_000_00D4_01CCE026.70483060-- From scott.probasco@nokia.com Tue Jan 31 12:12:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5EB21F846F for ; Tue, 31 Jan 2012 12:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj5Cbd+Q6Q0F for ; Tue, 31 Jan 2012 12:12:18 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E535521F84C9 for ; Tue, 31 Jan 2012 12:12:15 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0VKC7dI015401; Tue, 31 Jan 2012 22:12:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 22:12:07 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Tue, 31 Jan 2012 21:12:06 +0100 From: To: , Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4EoKmZU77rKmJUG0BaZYFFCPnJYm3jmg//+U/AA= Date: Tue, 31 Jan 2012 20:12:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.163.149] Content-Type: multipart/alternative; boundary="_000_CB4DA30BFCB6scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2012 20:12:07.0112 (UTC) FILETIME=[9B1C9C80:01CCE054] X-Nokia-AV: Clean Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 20:12:21 -0000 --_000_CB4DA30BFCB6scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operation where the two = first types of services are not being used. The use of =93lower priority o= pportunistic=94 service rather than =93secondary=94 service would be prefer= able to describe white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limits imposed by this license-exempt ruling, his oper= ation is therefore illegal and he is then considered to be running an =93un= licensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB4DA30BFCB6scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Gerald,

Good to avoid overloading the term "secondary". I have made = additional proposed changes to the text below based on your suggestion. &qu= ot;Lower priority opportunistic service" could indeed by used, but I a= m guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and licens= e-exempt spectrum, I used these words. Do these changes remove your concern= s?

I also corrected "location" to "local" in previous= text proposed for "White Space".

Kind Regards,
Scott

From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca<= /a>>
Date: Tue, 31 Jan 2012 14:41:36 -05= 00
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and r= equirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology= , Prior Work)

Scott,

Great proposal.  However, I am st= ill a bit nervous about the definitions of =93Protected Entity=94 and =93Wh= ite Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary status is use= d in the ITU-R Radio Regulations for a different purpose.  In fact, it= is possible that a band has already primary and secondary services allotte= d to it and that the White Space operation is a tertiary opportunistic operation where the two first types of service= s are not being used.  The use of =93lower priority opportunistic=94 s= ervice rather than =93secondary=94 service would be preferable to describe = white space allocations.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of s= cott.probasco@nokia.com
Sent: Tuesday, 31 January, 2= 012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use case= s and requirements I-D: sections 1 to 3 (Introduction, Conventions and Term= inology, Prior Work)

 

Hi,

 <= /o:p>

I changed th= e subject line from " Re: [paws] Discussion on 'license-exempt' vs 'un= licensed'  ". Here I try to propose some changes to the draft based on the email discussion.

 <= /o:p>

Below is a c= opy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' a= nd 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the doc= ument should accurately explain the subject with aim that a reader can unde= rstand the use cases and the subsequent requirements. No doubt we could inc= lude much more text on this topic of spectrum allocation, assignment, licensing and usage.=

 <= /o:p>

I hope this = captures the key points of the discussion. Please do reply if something is = still missing.

 <= /o:p>

Kind Regards= ,

Scott

 <= /o:p>

 <= /o:p>

2.2.  T= erminology

 <= /o:p>

  = Database

 <= /o:p>

  =    In the context of white space and cognitive radio technologie= s,

  =    the database is an entity which contains current information = about

  =    available spectrum at any given location and other types of

  =    information.

 <= /o:p>

  = Device ID

 <= /o:p>

  =    A unique number for each master device and slave device that<= o:p>

  =    identifies the manufacturer, model number and serial number.<= o:p>

 <= /o:p>

<Insert&g= t;

  = Licensed Spectrum

 <= /o:p>

  =    Spectrum that is acquired by an operator over a given service= area

  =    for a given time period.  This is usually done through a= uctions,award

  =    (beauty contest), acquisition from secondary market, company = merger &

  =    acquisition,  first-come / first-served or by government= allocation

  =    (e.g., public service).

 <= /o:p>

  = License-exempt Spectrum

 <= /o:p>

  =    Spectrum that is not assigned to any specific user. One examp= le is the 2.4 Ghz ISM band, where RF devices

  =    operate without a formal licensing process. In the USA, license-exempt spectrum is

  =    Typically referred to as "unlicensed" spectrum. In = this document the terms

  =    license-exempt and unlicensed are used interchangeably.<= /o:p>

 <= /o:p>

</Insert&= gt;

 <= /o:p>

  = Location Based Service

 <= /o:p>

  =    An application or device which provides data, information or<= o:p>

  =    service to a user based on their location.<= /font>

 <= /o:p>

  = Master Device

 <= /o:p>

  =    A device which queries the WS Database to find out the availa= ble

  =    operating channels.

 <= /o:p>

  = Protected Entity

 <= /o:p>

  =    <Insert>A licensed user of spectrum, when the licensed = spectrum has been assigned as white space spectrum.</Insert> <Dele= te>A primary</Delete><Insert>A licensed</Insert> user of whit= e space spectrum <Delete>which</Delete> is afforded<= /span>

  =    protection against interference by <Delete>secondary<= ;/Delete><Insert>license-exempt white space</Insert> users &= lt;Delete>(white space

  =    devices) for its use</Delete> in a given area and time.=

 <= /o:p>

  = Protected Contour

 <= /o:p>

  =    The exclusion area for a Protected Entity, held in the databa= se

  =    and expressed as a polygon with geospatial points as the vert= ices.

 <= /o:p>

  = Slave Device

 <= /o:p>

  =    A device which uses the spectrum made available by a master

  =    device.

 <= /o:p>

  = TV White Space

 <= /o:p>

  =    TV white space refers specifically to radio spectrum which ha= s

  =    been allocated for TV broadcast, but is not occupied by a TV<= o:p>

  =    broadcast, or other licensed user (such as a wireless microph= one),

  =    at a specific location and time.

 <= /o:p>

  = White Space

 <= /o:p>

  =    Radio spectrum which has been allocated <Delete>for som= e primary use</Delete><Insert>and assigned for licensed use<= /Insert>, but

  =    is not fully occupied by that <Delete>primary use</D= elete><Insert> licensed use </Insert> at a specificlocation<= o:p>

  =    and time. <Insert>This spectrum is then assigned by <= ;Delete>location</Delete><Insert>local</Insert> regula= tions for use as licensed-exempt spectrum under control of a white space database.</Inse= rt>

 <= /o:p>

  = White Space Device (WSD)

 <= /o:p>

  =   A device which is a <Delete>secondary</Delete><= Insert>license-exempt</Insert> user of some part of white space

  =    spectrum.  A white space device can be an access point, = base

  =    station, a portable device or similar.  In this context,= a white

  =    space device is required to query a database with its locatio= n to

  =    obtain information about available spectrum.

 <= /o:p>

 <= /o:p>

 <= /o:p>

From: = ext Gerald= Chouinard <gerald.chou= inard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07= :30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 <= /o:p>

Nancy,

 

This is not that simple.  In fact= , the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to mor= e than one thing.

 

If the qualifier applies to a frequenc= y band, different options exist. As an example, in the ITU-R context, an = =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its= use.  It is therefore un-allocated to a specific service so far and t= hus it is an =93unlicensed=94 frequency band<= /b>. Once the ITU-R allocates this band to one or many services on a primar= y or secondary basis, then the administrations can thendecide under what ki= ng of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis of= licensed operation (with different options to do the assignment: auction, = first come/first served, etc.) or allow operation with an exemption of li= censes, thus =93license-exempt=94such as in the 2.4 GHz ISM band= . This is also called =93unlicensed=94 in the USA.

 

If the qualifier applies to an operati= on, the operation can be exempt of license by the local administration, thu= s a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a= licensed band for which he has no license or in a license-exempt band for = which he does not meet the requirements such as operating according to the type of operation for which the band is= exempted from a license or he operates outside the technical limits impose= d by this license-exempt ruling, his operation is therefore illegal and he = is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to the transm= ission device, such device may be a =93license-exempt=94 device = if its operation does not require a specific license or registration with t= he local administration such as TV receivers of Wi-Fi devices in the 2.4 GH= z ISM band.  However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eB= ay and operates it, this is then an illegal device in the country and id de= -facto an =93unlicensed=94 device since it has not passed through the norma= l certification process.

 

Note that a =93license-exempt=94 devic= e still has to go through a certification process and meet the limits impos= ed by the local regulator for the =93license-exempt=94 operation in the given frequency band whereas= an =93unlicensed=94 device may not pass the certification process since it= has not been licensed to operation in the country.

 

This is why the qualifier =93unlicense= d=94 has to be treated with care and the footnote will need to be crafted v= ery carefully.

 

With respect to your second point, if = an administration only allows =93licensed=94 operation, the situation will = be much simpler to manage since specific conditions will be attached to these licenses.= =

 

Gerald

 

= From: Nancy Bravin [mailto:nbravin@eart= hlink.net]
Sent: Tuesday, 31 January, 2= 012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 =

Gabor and Gerald, <= u1:p>

Since we are dealing on = a global basis, can there a footnote to "unlicensed" we can use t= o indicate that "according to each countries regulatory requirements"  

How to get around the fa= ct that some Countries are or will be "licensed only" by their go= v'ts?  Thanks

Nancy

On Jan 30, 2012, at 4:13= PM, Gerald Chouinard wrote:




Gabor,

 

I agree with your proposal.  This= seems to be reasonable.  However one needs to be careful with the word= =91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 

Gerald

 

= From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, 20= 12 17:49
To: gerald.chouinard@symp= atico.ca; paws@ietf.org
Subject: RE: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 

= These lo= ok to be very precise definitions, however in everyday use I rarely hear pe= ople referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used. = =

= &n= bsp;

= Therefor= e, may I suggest that the draft will include the following statement:=

= &n= bsp;

= The term= s unlicensed and license-exempt spectrum are used in this document intercha= ngeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as t= he ISM band.<= span style=3D"color:black">

= &n= bsp;

- &= nbsp;        Gabor

= &n= bsp;

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chou= inard
Sent: Monday, January 30, 20= 12 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion o= n 'license-exempt' vs 'unlicensed'<= font color=3D"black"><= /p>

 

All,= =

 

Here is my understanding of the terms:=

 

Licensed: Spectrum that is acquired by an operator over a given service area for a g= iven time period.  This is usually done through auctions (think of the= Telcos), beauty contest, first-come / first-served or by government alloca= tion (e.g., public service).

 

Lightly licensed: Special case where thefrequency allocation is done through first-come / fi= rst-served process for a given time frame over a relatively limited service= area. The annual license fee is usually small to facilitate the deployment= of a service that would not normally be economically attractive.  Small local operators would be intereste= d by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through au= ction over large service areas.

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing proc= ess is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be cont= acted to clarify it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a frequency band wi= thout a duly issued license.  In the USA, this term is used to mean =93license-exempt," see above.=

 

To my knowledge, the term =93unlicense= d=94 is used only in the USA to describe a legal operation because the term =93license-exempt=94 has be= en used for another specific purpose.

 

Since the PAWS addresses the interface= to the database for the international market, it should rely on the defini= tion of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exe= mpt=92 with a footnote indicating that the term =91unlicensed=92 is used in= the USA instead of the usual =91license-exempt=92.

 

Gerald

________________________= _______________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws


 =

____________= ___________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB4DA30BFCB6scottprobasconokiacom_-- From gerald.chouinard@sympatico.ca Tue Jan 31 14:33:27 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB0F21F863C for ; Tue, 31 Jan 2012 14:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us2kq6DDq9TP for ; Tue, 31 Jan 2012 14:33:20 -0800 (PST) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7C21F8639 for ; Tue, 31 Jan 2012 14:33:19 -0800 (PST) Received: from BLU0-SMTP91 ([65.55.116.72]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 14:33:19 -0800 X-Originating-IP: [70.26.237.132] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.237.132]) by BLU0-SMTP91.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jan 2012 14:33:14 -0800 From: Gerald Chouinard To: , References: Date: Tue, 31 Jan 2012 17:33:13 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01CCE03E.6A11FE20" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM4EoKmZU77rKmJUG0BaZYFFCPnJYm3jmg//+U/ACAAJk9YA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 31 Jan 2012 22:33:15.0243 (UTC) FILETIME=[5282DBB0:01CCE068] Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 22:33:28 -0000 ------=_NextPart_000_00E7_01CCE03E.6A11FE20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Scott, Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied by that licensed use at a specific location and time. This spectrum is then assigned allowed by local regulations for use to be used opportunistically as licensed-exempt spectrum under control of a white space database. This way, it is understood that the database does not "assign" white space devices for them to choose from. Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do these changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White Space". Kind Regards, Scott From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operation where the two first types of services are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white space allocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws ------=_NextPart_000_00E7_01CCE03E.6A11FE20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 

Radio = spectrum which has been allocated and assigned for licensed use, but is = not fully occupied by that licensed use at a specific location and = time. This spectrum is then <delete>assigned<delete> = <insert>allowed<insert> by local regulations <delete>for use<delete> = <insert>to be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: Tuesday, 31 = January, 2012 15:12
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Hi = Gerald,

 

Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that = we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 

I also = corrected "location" to "local" in previous text proposed for "White Space".

 

Kind = Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 = 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Scott,

Great proposal.  However, I am = still a bit nervous about the definitions of “Protected Entity” = and “White Space Devices (WSD)” where the notion of secondary = use is included.  The secondary status is used in the ITU-R Radio = Regulations for a different purpose.  In fact, it is possible that a band has = already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operation where the two first = types of services are not being used.  The use of “lower priority = opportunistic” service rather than “secondary” service would be preferable = to describe white space allocations.

 

Gerald =

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 = January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Hi,

 

I changed the = subject line from " Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'  ". Here I try to propose some changes to the draft based on = the email discussion.

 

Below is a = copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this = captures the key points of the discussion. Please do reply if something is still = missing.

 

Kind = Regards,

Scott

 

 

2.2. =  Terminology

 

   = Database

 

   =    In the context of white space and cognitive radio = technologies,

   =    the database is an entity which contains current information = about

   =    available spectrum at any given location and other types = of

   =    information.

 

   = Device ID

 

   =    A unique number for each master device and slave device = that

   =    identifies the manufacturer, model number and serial = number.

 

<Insert>=

   = Licensed Spectrum

 

   =    Spectrum that is acquired by an operator over a given service = area

   =    for a given time period.  This is usually done through = auctions,award

   =    (beauty contest), acquisition from secondary market, company = merger &

   =    acquisition,  first-come / first-served or by government = allocation

   =    (e.g., public service).

 

   License-exempt Spectrum

 

   =    Spectrum that is not assigned to any specific user. One example is = the 2.4 Ghz ISM band, where RF devices

   =    operate without a formal licensing process. In the = USA, license-exempt spectrum is

   =    Typically referred to as "unlicensed" spectrum. In this document the terms

   =    license-exempt and unlicensed are used = interchangeably.

 

</Insert>= ;

 

   = Location Based Service

 

   =    An application or device which provides data, information = or

   =    service to a user based on their = location.

 

   = Master Device

 

   =    A device which queries the WS Database to find out the = available

   =    operating channels.

 

   = Protected Entity

 

   =    <Insert>A licensed user of spectrum, when the licensed = spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A licensed</Insert> user of = white space spectrum <Delete>which</Delete> is = afforded

   =    protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

   =    devices) for its use</Delete> in a given area and = time.

 

   = Protected Contour

 

   =    The exclusion area for a Protected Entity, held in the = database

   =    and expressed as a polygon with geospatial points as the = vertices.

 

   = Slave Device

 

   =    A device which uses the spectrum made available by a = master

   =    device.

 

   = TV White Space

 

   =    TV white space refers specifically to radio spectrum which = has

   =    been allocated for TV broadcast, but is not occupied by a = TV

   =    broadcast, or other licensed user (such as a wireless = microphone),

   =    at a specific location and time.

 

   = White Space

 

   =    Radio spectrum which has been allocated <Delete>for some = primary use</Delete><Insert>and assigned for licensed = use</Insert>, but

   =    is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

   =    and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   = White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

   =    spectrum.  A white space device can be an access point, = base

   =    station, a portable device or similar.  In this context, a = white

   =    space device is required to query a database with its location = to

   =    obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 = 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Nancy,

 

This is not that simple.  In = fact, the qualifiers “license-exempt” and “unlicensed” = can apply to more than one thing.

 

If the qualifier applies to a = frequency band, different options exist. As an example, in the ITU-R context, an “unlicensed” band is typically a new band, say in the 300 = GHz, for which no request has been made for its use.  It is therefore = un-allocated to a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime it = will ‘assign’ this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different options = to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus “license-exempt”such as in the 2.4 GHz ISM band. = This is also called “unlicensed” in the USA.

 

If the qualifier applies to an = operation, the operation can be exempt of license by the local administration, thus = a “license-exempt” = operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an = “unlicensed” operation.

 

If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license = or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone smuggles a = device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id = de-facto an “unlicensed” device since it has not passed through the = normal certification process.

 

Note that a = “license-exempt” device still has to go through a certification process and meet the = limits imposed by the local regulator for the “license-exempt” = operation in the given frequency band whereas an “unlicensed” device = may not pass the certification process since it has not been licensed to = operation in the country.

 

This is why the qualifier “unlicensed” has to be treated with care and the footnote = will need to be crafted very carefully.

 

With respect to your second point, = if an administration only allows “licensed” operation, the = situation will be much simpler to manage since specific conditions will be attached to = these licenses.

 

Gerald

 

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 = January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and = Gerald, 

Since we are dealing on a global = basis, can there a footnote to "unlicensed" we can use to indicate = that "according to each countries regulatory requirements" =  

How to get around the fact that = some Countries are or will be "licensed only" by their gov'ts? =  Thanks

Nancy

On Jan 30, 2012, at 4:13 PM, = Gerald Chouinard wrote:





Gabor,

 

I agree with your proposal.  Thisseems to be reasonable.  However one needs to be careful with = the word‘unlicensed’ which may mean ‘illegal’ = operation of an RF device in many = administrations.

 

Gerald

 

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] =
Sent: Monday, 30 January, = 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] = Discussion on 'license-exempt' vs = 'unlicensed'

 

These look = to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as ‘license-exempt’, in most cases the = term ‘unlicensed-band’ is used. =

 =

Therefore, = may I suggest that the draft will include the following = statement:

 =

The terms = unlicensed and license-exempt spectrum are used in this document interchangeably = and refer to a spectrum in which no formal licensing process is needed for RF = devices to operate in, such as the ISM = band.

 =

-          Gabor<= /u5:p>

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of ext Gerald = Chouinard
Sent: Monday, January 30, = 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] = Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

Here is my understanding of the = terms:

 

= Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period.  This is usually done through auctions = (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service).

 

= Lightly licensed: Special case = where thefrequency allocation is done through first-come / first-served = process for a given time frame over a relatively limited service area. The annual = license fee is usually small to facilitate the deployment of a service that would = not normally be economically attractive.  Small local operators would = be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through = auction over large service areas.

 

= License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

 

= Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

 

To my knowledge, the = term “unlicensed” is used only in the USA to describe a legal operation because the term = “license-exempt” has been used for another specific = purpose.

 

Since the PAWS addresses the = interface to the database for the international market, it should rely on the = definition of the terms recognized by the ITU-R. I would suggest the use of ‘licensed’ and ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the = USA instead of the usual = ‘license-exempt’.

 

Gerald

_____________________= __________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/= mailman/listinfo/paws



 

______________= _________________________________ paws mailing list paws@ietf.org https://www.ietf.org/= mailman/listinfo/paws

------=_NextPart_000_00E7_01CCE03E.6A11FE20-- From scott.probasco@nokia.com Tue Jan 31 14:50:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115F111E8076 for ; Tue, 31 Jan 2012 14:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbKoM-FuVAGs for ; Tue, 31 Jan 2012 14:50:06 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD7E1F0C46 for ; Tue, 31 Jan 2012 14:50:05 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0VMo1S4006760 for ; Wed, 1 Feb 2012 00:50:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 00:50:00 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Tue, 31 Jan 2012 23:50:00 +0100 From: To: Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4EoKmZU77rKmJUG0BaZYFFCPnJYm3jmg//+U/ACAAJk9YP//ktAA Date: Tue, 31 Jan 2012 22:49:58 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.163.149] Content-Type: multipart/alternative; boundary="_000_CB4DCAE6FCEDscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2012 22:50:00.0671 (UTC) FILETIME=[A9CAFEF0:01CCE06A] X-Nokia-AV: Clean Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 22:50:09 -0000 --_000_CB4DCAE6FCEDscottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Gerald, Thank you for the proposed text, this looks good to me. I will implement th= is, assuming no further comments. Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 17:33:13 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of =93white space=94 as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed by = local regulations for use to be used opportunistica= lly as licensed-exempt spectrum under control of a white space data= base. This way, it is understood that the database does not =93assign=94 white sp= ace devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operation where the two = first types of services are not being used. The use of =93lower priority o= pportunistic=94 service rather than =93secondary=94 service would be prefer= able to describe white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. LicensedSpectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of whitespace spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limits imposed by this license-exempt ruling, his oper= ation is therefore illegal and he is then considered to be running an =93un= licensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term=93unlicensed=94 is used only in the USA to descri= be a legal operation because the term =93license-exempt=94 has been used fo= r another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB4DCAE6FCEDscottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4782C9C72858AB4F801B0F73C2AE239A@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hello Gerald,

Thank you for the proposed text, this looks good to me. I will impleme= nt this, assuming no further comments.

Kind Regards,
Scott

From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca<= /a>>
Date: Tue, 31 Jan 2012 17:33:13 -05= 00
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and r= equirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology= , Prior Work)

Scott,

 

Very good improvements. I would sugges= t to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of =93white space=94 as follows:

 

White Space<= u1:p>

 =

Radio spectr= um which has been allocated and assigned for licensed use, but= is not fully occupied by that licensed use at a specific location and time. This spectrum is then <de= lete>assigned<delete> <insert>allowed<insert> by local= regulations <delete>for use<delete> <insert>to be used o= pportunistically<insert> as licensed-exempt spectrum under control of= a white space database.</Insert>

 

This way, it is understood that the da= tabase does not =93assign=94 white space devices for them to choose from.

 

Gerald

From: scott.probasco@nokia.com [<= a href=3D"mailto:scott.probasco@nokia.com">mailto:scott.probasco@nokia.com<= /a>]
Sent: Tuesday, 31 January, 2= 012 15:12
To: gerald.chouinard@sympa= tico.ca; paws@ietf.org
Subject: Re: [paws] Use case= s and requirements I-D: sections 1 to 3 (Introduction, Conventions and Term= inology, Prior Work)

 

Hi Gerald,

 <= /o:p>

Good to avoi= d overloading the term "secondary". I have made additional propos= ed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but= I am guessing that we would need some explanation of what that means. Sinc= e we now have descriptions of licensed spectrum and license-exempt spectrum= , I used these words. Do these changes remove your concerns?

 <= /o:p>

I also corre= cted "location" to "local" in previous text proposed fo= r "White Space".

 <= /o:p>

Kind Regards= ,

Scott

 <= /o:p>

From: = ext Gerald= Chouinard <gerald.chou= inard@sympatico.ca>
Date: Tue, 31 Jan 2012 14:41= :36 -0500
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use case= s and requirements I-D: sections 1 to 3 (Introduction, Conventions and Term= inology, Prior Work)

 <= /o:p>

Scott,

Great proposal.  However, I am st= ill a bit nervous about the definitions of =93Protected Entity=94 and =93Wh= ite Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary status is use= d in the ITU-R Radio Regulations for a different purpose.  In fact, it= is possible that a band has already primary and secondary services allotte= d to it and that the White Space operation is a tertiary opportunistic operation where the two first types of service= s are not being used.  The use of =93lower priority opportunistic=94 s= ervice rather than =93secondary=94 service would be preferable to describe = white space allocations.

 

Gerald

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2= 012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use case= s and requirements I-D: sections 1 to 3 (Introduction, Conventions and Term= inology, Prior Work)

 =

Hi,

 =

I changed th= e subject line from " Re: [paws] Discussion on 'license-exempt' vs 'un= licensed'  ". Here I try to propose some changes to the draft based on the email discussion.

 =

Below is a c= opy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' a= nd 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the doc= ument should accurately explain the subject with aim that a reader can unde= rstand the use cases and the subsequent requirements. No doubt we could inc= lude much more text on this topic of spectrum allocation, assignment, licensing and usage.

 =

I hope this = captures the key points of the discussion. Please do reply if something is = still missing.

 =

Kind Regards= ,

Scott<= /u1:p>=

 =

 =

2.2.  T= erminology

 =

  = Database

 =

  =    In the context of white space and cognitive radio technologie= s,

  =    the database is an entity which contains current information = about

  =    available spectrum at any given location and other types of=

  =    information.=

 =

  = Device ID

 =

  =    A unique number for each master device and slave device that<= u1:p>

  =    identifies the manufacturer, model number and serial number.<= u1:p>

 =

<Insert&g= t;

  = LicensedSpectrum

 =

  =    Spectrum that is acquired by an operator over a given service= area

  =    for a given time period.  This is usually done through a= uctions,award

  =    (beauty contest), acquisition from secondary market, company = merger &

  =    acquisition,  first-come / first-served or by government= allocation

  =    (e.g., public service).

 =

  = License-exempt Spectrum

 =

  =    Spectrum that is not assigned to any specific user. One examp= le is the 2.4 Ghz ISM band, where RF devices

  =    operate without a formal licensing process. In the USA, license-exempt spectrum is

  =    Typically referred to as "unlicensed" spectrum. In = this document the terms

  =    license-exempt and unlicensed are used interchangeably.=

 =

</Insert&= gt;

 =

  = Location Based Service

 =

  =    An application or device which provides data, information or<= u1:p>

  =    service to a user based on their location.

 =

  = Master Device

 =

  =    A device which queries the WS Database to find out the availa= ble

  =    operating channels.

 =

  = Protected Entity

 =

  =    <Insert>A licensed user of spectrum, when the licensed = spectrum has been assigned as white space spectrum.</Insert> <Dele= te>A primary</Delete><Insert>A licensed</Insert> user of whit= espace spectrum <Delete>which</Delete> is afforded= =

  =    protection against interference by <Delete>secondary<= ;/Delete><Insert>license-exempt white space</Insert> users &= lt;Delete>(white space

  =    devices) for its use</Delete> in a given area and time.=

 =

  = Protected Contour

 =

  =    The exclusion area for a Protected Entity, held in the databa= se

  =    and expressed as a polygon with geospatial points as the vert= ices.

 =

  = Slave Device

 =

  =    A device which uses the spectrum made available by a master=

  =    device.

 =

  = TV White Space

 =

  =    TV white space refers specifically to radio spectrum which ha= s

  =    been allocated for TV broadcast, but is not occupied by a TV<= u1:p>

  =    broadcast, or other licensed user (such as a wireless microph= one),

  =    at a specific location and time.

 =

  = White Space

 =

  =    Radio spectrum which has been allocated <Delete>for som= e primary use</Delete><Insert>and assigned for licensed use<= /Insert>, but

  =    is not fully occupied by that <Delete>primary use</D= elete><Insert> licensed use </Insert> at a specificlocation<= u1:p>

  =    and time. <Insert>This spectrum is then assigned by <= ;Delete>location</Delete><Insert>local</Insert> regula= tions for use as licensed-exempt spectrum under control of a white space database.</Inse= rt>

 =

  = White Space Device (WSD)<= span style=3D"color:black">

 =

  =   A device which is a <Delete>secondary</Delete><= Insert>license-exempt</Insert> user of some part of white space<= o:p>

  =    spectrum.  A white space device can be an access point, = base

  =    station, a portable device or similar.  In this context,= a white

  =    space device is required to query a database with its locatio= n to

  =    obtain information about available spectrum.

 =

 =

 =

From: = ext Gerald Chouinard <gerald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07= :30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 =

Nancy,

 

This is not that simple.  In fact= , the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to mor= e than one thing.

 

If the qualifier applies to a frequenc= y band, different options exist. As an example, in the ITU-R context, an = =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its= use.  It is therefore un-allocated to a specific service so far and t= hus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates = this band to one or many services on a primary or secondary basis, then the= administrations can thendecide under what king of regime it will =91assign= =92 this band foroperation. They may decide to allow the use of the band on the basis of= licensed operation (with different options to do the assignment: auction, = first come/first served, etc.) or allow operation with an exemption of li= censes, thus =93license-exempt=94such as in the 2.4 GHz ISM band= . This is also called =93unlicensed=94 in the USA.<= font color=3D"black">

 

If the qualifier applies to an operati= on, the operation can be exempt of license by the local administration, thu= s a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a= licensed band for which he has no license or in a license-exempt band for = which he does not meet the requirements such as operating according to the type of operation for which the band is= exempted from a license or he operates outside the technical limits impose= d by this license-exempt ruling, his operation is therefore illegal and he = is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to the transm= ission device, such device may be a =93license-exempt=94 device = if its operation does not require a specific license or registration with t= he local administration such as TV receivers of Wi-Fi devices in the 2.4 GH= z ISM band.  However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eB= ay and operates it, this is then an illegal device in the country and id de= -facto an =93unlicensed=94 device since it has not passed through the norma= l certification process.

 

Note that a =93license-exempt=94 devic= e still has to go through a certification process and meet the limits impos= ed by the local regulator for the =93license-exempt=94 operation in the given frequency band whereas= an =93unlicensed=94 device may not pass the certification process since it= has not been licensed to operation in the country.

 

This is why the qualifier =93unlicense= d=94 has to be treated with care and the footnote will need to be crafted v= ery carefully.

 

With respect to your second point, if = an administration only allows =93licensed=94 operation, the situation will = be much simpler to manage since specific conditions will be attached to these licenses.=

 

Gerald

 

= From: Nancy Bravin [mailto:nbravin@eart= hlink.net]
Sent: Tuesday, 31 January, 2= 012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 

Gabor and Gerald, <= u3:p>

Since we are dealing on = a global basis, can there a footnote to "unlicensed" we can use t= o indicate that "according to each countries regulatory requirements"  

How to get around the fa= ct that some Countries are or will be "licensed only" by their go= v'ts?  Thanks

Nancy

On Jan 30, 2012, at 4:13= PM, Gerald Chouinard wrote:





Gabor,

 

I agree with your proposal.  This= seems to be reasonable.  However one needs to be careful with the word= =91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 

Gerald

 

= From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, 20= 12 17:49
To: gerald.chouinard@symp= atico.ca; paws@ietf.org
Subject: RE: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'

 

= These lo= ok to be very precise definitions, however in everyday use I rarely hear pe= ople referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used. =

= &n= bsp;

= Therefor= e, may I suggest that the draft will include the following statement:=

= &n= bsp;

= The term= s unlicensed and license-exempt spectrum are used in this document intercha= ngeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as t= he ISM band.<= span style=3D"color:black">

= &n= bsp;

- &= nbsp;        Gabor

= &n= bsp;

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chou= inard
Sent: Monday, January 30, 20= 12 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion o= n 'license-exempt' vs 'unlicensed'<= font color=3D"black">

 

All,= =

 

Here is my understanding of the terms:=

 

Licensed: Spectrum that is acquired by an operator over a given service area for a g= iven time period.  This is usually done through auctions (think of the= Telcos), beauty contest, first-come / first-served or by government alloca= tion (e.g., public service).

 

Lightly licensed: Special case where thefrequency allocation is done through first-come / fi= rst-served process for a given time frame over a relatively limited service= area. The annual license fee is usually small to facilitate the deployment= of a service that would not normally be economically attractive.  Small local operators would be intereste= d by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through au= ction over large service areas.

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing proc= ess is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be cont= acted to clarify it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a frequency band wi= thout a duly issued license.  In the USA, this term is used to mean =93license-exempt," see above.

 

To my knowledge, the term= =93unlicensed=94 is used only in the USA to describe a legal operation because the term =93license-exempt=94 has be= en used for another specific purpose.

 

Since the PAWS addresses the interface= to the database for the international market, it should rely on the defini= tion of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exe= mpt=92 with a footnote indicating that the term =91unlicensed=92 is used in= the USA instead of the usual =91license-exempt=92.

 

Gerald

___________= ____________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws



 = ;

____________= ___________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_CB4DCAE6FCEDscottprobasconokiacom_-- From stephen.farrell@cs.tcd.ie Tue Jan 31 14:54:56 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FCE11E807F for ; Tue, 31 Jan 2012 14:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.219 X-Spam-Level: X-Spam-Status: No, score=-102.219 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHVPABYYVIiu for ; Tue, 31 Jan 2012 14:54:55 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id B145311E8076 for ; Tue, 31 Jan 2012 14:54:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 95EC6171C96; Tue, 31 Jan 2012 22:54:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1328050492; bh=GxAT9GjuBTG3ba pPTVICFsXxQY48nlL+0DjrwUx7YLs=; b=ls5/bZDBdexgES1IHZXSBd4R9/S+9Q fYTfDu7SR67bKc9kthRY5T7gBcqbUlFeFuUfF+O9ucv3gdYyj39jNfuSEXeNT6N/ DsdFpBuJaZuHuuwmN2Idkob1aUQkAv5FXhBq+2VLc1x/x1n01nqt5h3LgigbHHY8 6W1qiUeEw21WXM/4cPZ05m1EGGmVSWDB36GlL/W9x3T2PM41YlaJP/4FfdDERU0v BGL9klncDdL0rzQqrc5Qc+zg3FikRT2TYj+KaMPj00sr20D+RjwarVRfzaBn1NyX 8rwCiZDtPMYtMaitL0ooGLEeQJcJEw3Cc4n5ltrcp81oRfF7wzkJcpnQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Q0QA9OG2qmB8; Tue, 31 Jan 2012 22:54:52 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.42.181.141]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 203EA171C71; Tue, 31 Jan 2012 22:54:51 +0000 (GMT) Message-ID: <4F287131.9050409@cs.tcd.ie> Date: Tue, 31 Jan 2012 22:54:41 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Paul Lambert References: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567642F92@SC-VEXCH2.marvell.com> <4F272932.5040802@cs.tcd.ie> <7BAC95F5A7E67643AAFB2C31BEE662D015676431B1@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015676431B1@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] Threats, Services and Predicatable Availability X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 22:54:56 -0000 On 01/31/2012 07:13 PM, Paul Lambert wrote: > > One more observation on threat modeling. Discovering the database is a service: > > 4) Support discovery of all authorized databases services for a geographic region. Good one. (And presumably withstanding related spoofs will turn out to be desired too.) > Associated threat event would be: > - Modification of paws protocol messages in transit to prevent discovery of authorized databases > > > When there are multiple authorized database services we need to make sure that all authorized services are available to end devices. > > This implies a trust hierarchy with the regulatory authority (Gov based) as a root for a region. New regions are not going to be easy to add ... which is good since any new region also requires some level of regional conformance. Well, a hierarchy is a design choice for later I guess. (But clearly one that'll be a natural idea for some of the involved parties.) S > > Paul > > > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Monday, January 30, 2012 3:35 PM >> To: Paul Lambert >> Cc: Basavaraj.Patil@nokia.com; paws@ietf.org >> Subject: Re: [paws] Threats, Services and Predicatable Availability >> >> >> Sorry to keep on on the same thing, but it doesn't seem >> to be resonating much;-) >> >> The charter says: "Robust privacy and security mechanisms >> are needed..." >> >> I'm guessing its possible an analysis starting from your >> suggestions below should produce a good result wrt security >> but maybe less so for privacy (which is less well >> understood by us all). >> >> How about adding "Prevent unnecessary exposure of >> personally identifying information (PII)" ? >> >> Note that the above could me met via encryption of >> PII, (with possibly high-cost key management) or by >> just not sending PII when you don't need to which is >> fairly cheap if you're not forced by regulation to >> send it. (Since some devices presumably are not >> personally identifying but others are, then maybe >> there's a simple enough answer in the end...) >> >> S >> >> On 01/30/2012 10:29 PM, Paul Lambert wrote: >>> >>> Hi Raj, >>> >>>> Do you have any proposals or text w.r.t the threat model writeup? >> Also >>> >from an IETF perspective regarding threat models, please see Peter's >>>> email: http://www.ietf.org/mail- >> archive/web/paws/current/msg00592.html >>>> >>>> -Raj >>> >>> I'll spend a little time formalizing the ideas I submitted below. >> However, "threats" are part of a complete set of requirements and >> looking at the current proposal, I feel we need to clarify the service >> that we offer before we can say what are real threats. Specifically, >> the threat: >>> >>>>>> device which can be used maliciously. The effect of such an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets to >> a >>>>>> white space database. >>> >>> This is not a threat as worded... but why? >>> >>> We need to define what we offer, and then things that prevent or break >> these offered services are potential risks that can be mapped to >> threats. As a start, I propose (which I hope is mostly in line with the >> use cases) two main services with some subtopics: >>> >>> 1) Prevent Interference of License-exempt Use with Licensed Operation >> >>> - Support changes in channel, time Period and region for licensed >> operation >>> - Support predictable availability of licensed channels >>> - Support the ability to disable specific vendor/model-types from >> operation when >>> they are determined to be causing interference >>> 2) Enable Authorized Channel Utilization for License-exempt Operation >> >>> - Facilitate fixed use of channels >>> - Facilitate mobile use of channels >>> - Facilitate indoor use of channels >>> - Support predictable availability of license-exempt channels >>> - Support changing of authorized channels to prevent interference >> with licensed usage >>> >>> So, threat event is something that has a result of preventing the >> promised services. The threat event either causes unapproved >> interference with licensed operation, or it prevents White Space >> "license-exempt" operation. >>> >>> The "Support Predictable Availability" is something new I'd like to >> introduce for discussion. There needs to be a expectation that once you >> are using a channel that your use will not be terminated abruptly in an >> unanticipated manner. Right now - we are creating mechanism to quickly >> cutoff a device for any reason at all (for the use case of mobile >> microphones). This is actually supposed to be a predictable event with >> some type of scheduling. An license-exempt devices needs to be able to >> determine how long it might operate under the regulations in a >> particular channel/region. Building a system where you never know when >> your communications might get cut off seems like a bad idea. >>> >>> >>> >>> Paul >>> >>> >>>> >>>> On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >>>> >>>>> It's good to have requirements based on such an analysis. This is >> an >>>>> interesting start, but we may be mixing threats, vulnerabilities and >>>>> mechanisms. >>>>> >>>>> Threats are typically tied to an actor ... human or not. I'm not >> sure >>>>> it's worth going hard over to something like the NIST 800-30 >>>> definitions >>>>> of threats, but within this framework the threats are Governments, >>>>> disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>>>> quickly to the threat event and specifics of an attack, but should >> at >>>>> least expand threats to include natural events and connectivity >>>> problems. >>>>> Robustness or emergency modes might be interesting to consider. >>>>> >>>>> We also have a problem in this analysis of perspective - are we >>>>> considering threats as viewed from regulatory agency or the end >> device >>>>> owner or both. We should consider both - but they are contradictory >>>>> perspectives. Users want continuity of service. Governments (the >>>>> regulators) want control of the airwaves. >>>>> >>>>> Most of the real threats that we have are nearly impossible to >> prevent >>>> at >>>>> the protocol level. It's still worth examining the threats to see >>>> where >>>>> we stand. >>>>> >>>>> On the current document threats: >>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>>> The master device needs to authenticate itself with the >> white >>>>>> space database prior to requesting channel information. The >>>>>> attacker may try to get access to the secrets of the master >>>>>> device which can be used maliciously. The effect of such an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets to >> a >>>>>> white space database. >>>>> This does not seem consistent with the prior statement of "not >>>>> compromised". >>>>> Restatement >>>>> >>>>> Threat: User modifies a device to masquerade as another valid >> certified >>>>> device. >>>>> >>>>> This is an interesting case where threat/vulnerability/risk play >>>>> together. The FCC or other regulatory agencies want traceability of >>>>> devices. If a user wants to run a rogue radio, there is no reason >> to >>>>> access the database (low risk - no payoff). The only reason this >> would >>>>> be an interesting attack might be to avoid tracking and have some >>>>> anonymity. >>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> A master device discovers a white space database(s) thru >> which >>>>>> it can query for channel information. The master device >> needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master device >>>>>> which can confirm the validity/authenticty of the database. >> An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious and >>>>>> result in the master device causing interference to the >> primary >>>>>> user of the spectrum. >>>>> >>>>> I think this is two types of threat events: >>>>> - malicious denial of service or intentional interference with >>>> incumbents >>>>> - impersonation of white space database to enable operation of a >>>> device >>>>> that may >>>>> not otherwise be possible (blocked device, unallocated channels). >>>>> This may or may not >>>>> interfere with incumbent devices >>>>> >>>>>> Threat 3: Modifying a query request >>>>> ... >>>>> >>>>>> Threat 4: Modifying a query response >>>>> Seems like these two could be lumped together ...MiTM modifies >> protocol >>>>> messages to: >>>>> - deny service >>>>> - interfere with incumbents >>>>> - provide unauthorized channel usage (most likely risk IMHO) >>>>> >>>>>> Threat 5: Using query response information >>>>>> An attacker may be a master device which is not certified >> for >>>>>> use by the relevant regulatory body. The attacker may listen >> to >>>>>> the communication between a valid master device and white >> space >>>>>> database and utilize the information about available >> channels >>>>>> in the response message by utilizing those channels. The >> result >>>>>> of such an attack is unauthorized use of channels by a >> master >>>>>> device which is not certified to operate. >>>>> As stated this is a mechanism - a clearer statement might be. >>>>> >>>>> Threat: Unauthorized use of channels by an uncertified device. >>>>> >>>>> Anyone can already go to a database and find available channels. If >> a >>>>> device can operate without going to the database there is nothing >> that >>>>> paws can do to stop it operating in available or non-available >>>> channels. >>>>> >>>>> Just to get some discussion going -here's a couple more possible >>>> threats.. >>>>> >>>>> Threat: Third party tracking of white space device location >>>>> Likely a valuable commodity to sell for advertizing with no >>>> technical >>>>> design or policy for privacy >>>>> Threat: Database owner termination of device service for reasons >> other >>>>> than incumbent protection >>>>> >>>>> >>>>> >>>>> Paul >>>>> >>>>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> > From brian.rosen@neustar.biz Tue Jan 31 17:22:53 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E2821F844B for ; Tue, 31 Jan 2012 17:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3TElx-ks1GQ for ; Tue, 31 Jan 2012 17:22:51 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6D921F844A for ; Tue, 31 Jan 2012 17:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328059406; x=1643410401; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=WXutZA0IXEoueKJmLNzRf 8RnNw3NooPwGWYnL/nu4h0=; b=WI9ax738ZIpvtU+RL2bK6ETdXkhuAKWj0WAd7 Ow7Zy8sXOKffmN0frB+1iESfWOn8MZjHLHa8xPcngyxqGRh5g== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.4730013; Tue, 31 Jan 2012 20:23:25 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Tue, 31 Jan 2012 20:22:45 -0500 From: "Rosen, Brian" To: 'Stephen Farrell' , 'Paul Lambert' Date: Tue, 31 Jan 2012 20:22:44 -0500 Thread-Topic: [paws] Threats, Services and Predicatable Availability Thread-Index: Aczga19GMnGcJo43QrC9xmLSbs2kUQAFKBR0 Message-ID: <27AA2A3F470FC14E8E04A5A3699BDDBF081EAC884C@STNTEXCH01.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: +zQTianwBe+N3brPhDMu7w== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] Threats, Services and Predicatable Availability X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 01:22:53 -0000 V2UgaGF2ZSBuaWNlIHRvb2xzIHRvIGRpc2NvdmVyIHRoZSByaWdodCBkYXRhYmFzZS4gIEkgZG9u J3QgdGhpbmsgd2Ugd2lsbCBuZWVkIHRvIHVzZSBhbnl0aGluZyBidXQgTG9TVCwgUkZDNTIyMiwg dG8gZGlzY292ZXIgdGhlIHJpZ2h0IG9uZS4gIFF1ZXJ5IHdpdGggeW91ciBsb2NhdGlvbiBhbmQg YSBzZXJ2aWNlIHVybiByZWxhdGVkIHRvIHRoZSB0eXBlIG9mIGRldmljZS9iYW5kL3doYXRldmVy IGFuZCBnZXQgYmFjayBhIGxpc3Qgb2YgVVJJcyB0byB0aGUgZGF0YWJhc2UuICBJdCdzIHRoZSBi YXNlIG9mIGVtZXJnZW5jeSBjYWxsIHJvdXRpbmcsIGFub3RoZXIgZ292ZXJubWVudCBzZXJ2aWNl LCBzbyBtYWtpbmcgaXQgc2VjdXJlIHNob3VsZCBiZSBzdHJhaWdodGZvcndhcmQuCgpCcmlhbgoK DQoNCiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogCVN0ZXBoZW4gRmFycmVsbCBb bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQpTZW50OglUdWVzZGF5LCBKYW51YXJ5 IDMxLCAyMDEyIDA1OjU1IFBNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0KVG86CVBhdWwgTGFtYmVy dA0KQ2M6CXBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6CVJlOiBbcGF3c10gVGhyZWF0cywgU2Vydmlj ZXMgYW5kIFByZWRpY2F0YWJsZSBBdmFpbGFiaWxpdHkNCg0KDQoNCk9uIDAxLzMxLzIwMTIgMDc6 MTMgUE0sIFBhdWwgTGFtYmVydCB3cm90ZToNCj4NCj4gT25lIG1vcmUgb2JzZXJ2YXRpb24gb24g dGhyZWF0IG1vZGVsaW5nLiAgRGlzY292ZXJpbmcgdGhlIGRhdGFiYXNlIGlzIGEgc2VydmljZToN Cj4NCj4gNCkgU3VwcG9ydCBkaXNjb3Zlcnkgb2YgYWxsIGF1dGhvcml6ZWQgZGF0YWJhc2VzIHNl cnZpY2VzIGZvciBhIGdlb2dyYXBoaWMgcmVnaW9uLg0KDQpHb29kIG9uZS4gKEFuZCBwcmVzdW1h Ymx5IHdpdGhzdGFuZGluZyByZWxhdGVkIHNwb29mcyB3aWxsIHR1cm4gb3V0IHRvDQpiZSBkZXNp cmVkIHRvby4pDQoNCj4gQXNzb2NpYXRlZCB0aHJlYXQgZXZlbnQgd291bGQgYmU6DQo+ICAgLSBN b2RpZmljYXRpb24gb2YgcGF3cyBwcm90b2NvbCBtZXNzYWdlcyBpbiB0cmFuc2l0IHRvIHByZXZl bnQgZGlzY292ZXJ5IG9mIGF1dGhvcml6ZWQgZGF0YWJhc2VzDQo+DQo+DQo+IFdoZW4gdGhlcmUg YXJlIG11bHRpcGxlIGF1dGhvcml6ZWQgZGF0YWJhc2Ugc2VydmljZXMgd2UgbmVlZCB0byBtYWtl IHN1cmUgdGhhdCBhbGwgYXV0aG9yaXplZCBzZXJ2aWNlcyBhcmUgYXZhaWxhYmxlIHRvIGVuZCBk ZXZpY2VzLg0KPg0KPiBUaGlzIGltcGxpZXMgYSB0cnVzdCBoaWVyYXJjaHkgd2l0aCB0aGUgcmVn dWxhdG9yeSBhdXRob3JpdHkgKEdvdiBiYXNlZCkgYXMgYSByb290IGZvciBhIHJlZ2lvbi4gTmV3 IHJlZ2lvbnMgYXJlIG5vdCBnb2luZyB0byBiZSBlYXN5IHRvIGFkZCAuLi4gIHdoaWNoIGlzIGdv b2Qgc2luY2UgYW55IG5ldyByZWdpb24gYWxzbyByZXF1aXJlcyBzb21lIGxldmVsIG9mIHJlZ2lv bmFsIGNvbmZvcm1hbmNlLg0KDQpXZWxsLCBhIGhpZXJhcmNoeSBpcyBhIGRlc2lnbiBjaG9pY2Ug Zm9yIGxhdGVyIEkgZ3Vlc3MuIChCdXQgY2xlYXJseQ0Kb25lIHRoYXQnbGwgYmUgYSBuYXR1cmFs IGlkZWEgZm9yIHNvbWUgb2YgdGhlIGludm9sdmVkIHBhcnRpZXMuKQ0KDQpTDQoNCj4NCj4gUGF1 bA0KPg0KPg0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFN0ZXBo ZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+PiBTZW50OiBN b25kYXksIEphbnVhcnkgMzAsIDIwMTIgMzozNSBQTQ0KPj4gVG86IFBhdWwgTGFtYmVydA0KPj4g Q2M6IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb207IHBhd3NAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6 IFJlOiBbcGF3c10gVGhyZWF0cywgU2VydmljZXMgYW5kIFByZWRpY2F0YWJsZSBBdmFpbGFiaWxp dHkNCj4+DQo+Pg0KPj4gU29ycnkgdG8ga2VlcCBvbiBvbiB0aGUgc2FtZSB0aGluZywgYnV0IGl0 IGRvZXNuJ3Qgc2VlbQ0KPj4gdG8gYmUgcmVzb25hdGluZyBtdWNoOy0pDQo+Pg0KPj4gVGhlIGNo YXJ0ZXIgc2F5czogIlJvYnVzdCBwcml2YWN5IGFuZCBzZWN1cml0eSBtZWNoYW5pc21zDQo+PiBh cmUgbmVlZGVkLi4uIg0KPj4NCj4+IEknbSBndWVzc2luZyBpdHMgcG9zc2libGUgYW4gYW5hbHlz aXMgc3RhcnRpbmcgZnJvbSB5b3VyDQo+PiBzdWdnZXN0aW9ucyBiZWxvdyBzaG91bGQgcHJvZHVj ZSBhIGdvb2QgcmVzdWx0IHdydCBzZWN1cml0eQ0KPj4gYnV0IG1heWJlIGxlc3Mgc28gZm9yIHBy aXZhY3kgKHdoaWNoIGlzIGxlc3Mgd2VsbA0KPj4gdW5kZXJzdG9vZCBieSB1cyBhbGwpLg0KPj4N Cj4+IEhvdyBhYm91dCBhZGRpbmcgIlByZXZlbnQgdW5uZWNlc3NhcnkgZXhwb3N1cmUgb2YNCj4+ IHBlcnNvbmFsbHkgaWRlbnRpZnlpbmcgaW5mb3JtYXRpb24gKFBJSSkiID8NCj4+DQo+PiBOb3Rl IHRoYXQgdGhlIGFib3ZlIGNvdWxkIG1lIG1ldCB2aWEgZW5jcnlwdGlvbiBvZg0KPj4gUElJLCAo d2l0aCBwb3NzaWJseSBoaWdoLWNvc3Qga2V5IG1hbmFnZW1lbnQpIG9yIGJ5DQo+PiBqdXN0IG5v dCBzZW5kaW5nIFBJSSB3aGVuIHlvdSBkb24ndCBuZWVkIHRvIHdoaWNoIGlzDQo+PiBmYWlybHkg Y2hlYXAgaWYgeW91J3JlIG5vdCBmb3JjZWQgYnkgcmVndWxhdGlvbiB0bw0KPj4gc2VuZCBpdC4g KFNpbmNlIHNvbWUgZGV2aWNlcyBwcmVzdW1hYmx5IGFyZSBub3QNCj4+IHBlcnNvbmFsbHkgaWRl bnRpZnlpbmcgYnV0IG90aGVycyBhcmUsIHRoZW4gbWF5YmUNCj4+IHRoZXJlJ3MgYSBzaW1wbGUg ZW5vdWdoIGFuc3dlciBpbiB0aGUgZW5kLi4uKQ0KPj4NCj4+IFMNCj4+DQo+PiBPbiAwMS8zMC8y MDEyIDEwOjI5IFBNLCBQYXVsIExhbWJlcnQgd3JvdGU6DQo+Pj4NCj4+PiBIaSBSYWosDQo+Pj4N Cj4+Pj4gRG8geW91IGhhdmUgYW55IHByb3Bvc2FscyBvciB0ZXh0IHcuci50IHRoZSB0aHJlYXQg bW9kZWwgd3JpdGV1cD8NCj4+IEFsc28NCj4+PiA+ZnJvbSBhbiBJRVRGIHBlcnNwZWN0aXZlIHJl Z2FyZGluZyB0aHJlYXQgbW9kZWxzLCBwbGVhc2Ugc2VlIFBldGVyJ3MNCj4+Pj4gZW1haWw6IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4+IGFyY2hpdmUvd2ViL3Bhd3MvY3VycmVudC9tc2cw MDU5Mi5odG1sDQo+Pj4+DQo+Pj4+IC1SYWoNCj4+Pg0KPj4+IEknbGwgc3BlbmQgYSBsaXR0bGUg dGltZSBmb3JtYWxpemluZyB0aGUgaWRlYXMgSSBzdWJtaXR0ZWQgYmVsb3cuDQo+PiBIb3dldmVy LCAidGhyZWF0cyIgYXJlIHBhcnQgb2YgYSBjb21wbGV0ZSBzZXQgb2YgcmVxdWlyZW1lbnRzIGFu ZA0KPj4gbG9va2luZyBhdCB0aGUgY3VycmVudCBwcm9wb3NhbCwgSSBmZWVsIHdlIG5lZWQgdG8g Y2xhcmlmeSB0aGUgc2VydmljZQ0KPj4gdGhhdCB3ZSBvZmZlciBiZWZvcmUgd2UgY2FuIHNheSB3 aGF0IGFyZSByZWFsIHRocmVhdHMuICBTcGVjaWZpY2FsbHksDQo+PiB0aGUgdGhyZWF0Og0KPj4+ DQo+Pj4+Pj4gICAgICAgICBkZXZpY2Ugd2hpY2ggY2FuIGJlIHVzZWQgbWFsaWNpb3VzbHkuIFRo ZSBlZmZlY3Qgb2Ygc3VjaCBhbg0KPj4+Pj4+ICAgICAgICAgYXR0YWNrIGJlaW5nIHN1Y2Nlc3Nm dWwgd291bGQgcmVzdWx0IGluIGEgbWFsaWNpb3VzIGNsaWVudA0KPj4+Pj4+ICAgICAgICAgcmVw bGF5aW5nIHRoZSBzdG9sZW4gYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzZWNyZXRzIHRv DQo+PiBhDQo+Pj4+Pj4gICAgICAgICB3aGl0ZSBzcGFjZSBkYXRhYmFzZS4NCj4+Pg0KPj4+IFRo aXMgaXMgbm90IGEgdGhyZWF0IGFzIHdvcmRlZC4uLiBidXQgd2h5Pw0KPj4+DQo+Pj4gV2UgbmVl ZCB0byBkZWZpbmUgd2hhdCB3ZSBvZmZlciwgYW5kIHRoZW4gdGhpbmdzIHRoYXQgcHJldmVudCBv ciBicmVhaw0KPj4gdGhlc2Ugb2ZmZXJlZCBzZXJ2aWNlcyBhcmUgcG90ZW50aWFsIHJpc2tzIHRo YXQgY2FuIGJlIG1hcHBlZCB0bw0KPj4gdGhyZWF0cy4gIEFzIGEgc3RhcnQsIEkgcHJvcG9zZSAo d2hpY2ggSSBob3BlIGlzIG1vc3RseSBpbiBsaW5lIHdpdGggdGhlDQo+PiB1c2UgY2FzZXMpIHR3 byBtYWluIHNlcnZpY2VzIHdpdGggc29tZSBzdWJ0b3BpY3M6DQo+Pj4NCj4+PiAxKSAgUHJldmVu dCBJbnRlcmZlcmVuY2Ugb2YgTGljZW5zZS1leGVtcHQgVXNlIHdpdGggTGljZW5zZWQgT3BlcmF0 aW9uDQo+Pg0KPj4+IAktIFN1cHBvcnQgY2hhbmdlcyBpbiBjaGFubmVsLCB0aW1lIFBlcmlvZCBh bmQgcmVnaW9uIGZvciBsaWNlbnNlZA0KPj4gb3BlcmF0aW9uDQo+Pj4gCS0gU3VwcG9ydCBwcmVk aWN0YWJsZSBhdmFpbGFiaWxpdHkgb2YgbGljZW5zZWQgY2hhbm5lbHMNCj4+PiAJLSBTdXBwb3J0 IHRoZSBhYmlsaXR5IHRvIGRpc2FibGUgc3BlY2lmaWMgdmVuZG9yL21vZGVsLXR5cGVzIGZyb20N Cj4+IG9wZXJhdGlvbiB3aGVuDQo+Pj4gICAgICAgICAgIHRoZXkgYXJlIGRldGVybWluZWQgdG8g YmUgY2F1c2luZyBpbnRlcmZlcmVuY2UNCj4+PiAyKSAgRW5hYmxlIEF1dGhvcml6ZWQgQ2hhbm5l bCBVdGlsaXphdGlvbiBmb3IgTGljZW5zZS1leGVtcHQgT3BlcmF0aW9uDQo+Pg0KPj4+IAktIEZh Y2lsaXRhdGUgZml4ZWQgdXNlIG9mIGNoYW5uZWxzDQo+Pj4gCS0gRmFjaWxpdGF0ZSBtb2JpbGUg dXNlIG9mIGNoYW5uZWxzDQo+Pj4gCS0gRmFjaWxpdGF0ZSBpbmRvb3IgdXNlIG9mIGNoYW5uZWxz DQo+Pj4gCS0gU3VwcG9ydCBwcmVkaWN0YWJsZSBhdmFpbGFiaWxpdHkgb2YgbGljZW5zZS1leGVt cHQgY2hhbm5lbHMNCj4+PiAJLSBTdXBwb3J0IGNoYW5naW5nIG9mIGF1dGhvcml6ZWQgY2hhbm5l bHMgdG8gcHJldmVudCBpbnRlcmZlcmVuY2UNCj4+IHdpdGggbGljZW5zZWQgdXNhZ2UNCj4+Pg0K Pj4+IFNvLCB0aHJlYXQgZXZlbnQgaXMgc29tZXRoaW5nIHRoYXQgaGFzIGEgcmVzdWx0IG9mIHBy ZXZlbnRpbmcgdGhlDQo+PiBwcm9taXNlZCBzZXJ2aWNlcy4gIFRoZSB0aHJlYXQgZXZlbnQgZWl0 aGVyIGNhdXNlcyB1bmFwcHJvdmVkDQo+PiBpbnRlcmZlcmVuY2Ugd2l0aCBsaWNlbnNlZCBvcGVy YXRpb24sIG9yIGl0IHByZXZlbnRzIFdoaXRlIFNwYWNlDQo+PiAibGljZW5zZS1leGVtcHQiIG9w ZXJhdGlvbi4NCj4+Pg0KPj4+IFRoZSAiU3VwcG9ydCBQcmVkaWN0YWJsZSBBdmFpbGFiaWxpdHki IGlzIHNvbWV0aGluZyBuZXcgSSdkIGxpa2UgdG8NCj4+IGludHJvZHVjZSBmb3IgZGlzY3Vzc2lv bi4gIFRoZXJlIG5lZWRzIHRvIGJlIGEgZXhwZWN0YXRpb24gdGhhdCBvbmNlIHlvdQ0KPj4gYXJl IHVzaW5nIGEgY2hhbm5lbCB0aGF0IHlvdXIgdXNlIHdpbGwgbm90IGJlIHRlcm1pbmF0ZWQgYWJy dXB0bHkgaW4gYW4NCj4+IHVuYW50aWNpcGF0ZWQgbWFubmVyLiAgUmlnaHQgbm93IC0gd2UgYXJl IGNyZWF0aW5nIG1lY2hhbmlzbSB0byBxdWlja2x5DQo+PiBjdXRvZmYgYSBkZXZpY2UgZm9yIGFu eSByZWFzb24gYXQgYWxsIChmb3IgdGhlIHVzZSBjYXNlIG9mIG1vYmlsZQ0KPj4gbWljcm9waG9u ZXMpLiBUaGlzIGlzIGFjdHVhbGx5IHN1cHBvc2VkIHRvIGJlIGEgcHJlZGljdGFibGUgZXZlbnQg d2l0aA0KPj4gc29tZSB0eXBlIG9mIHNjaGVkdWxpbmcuICBBbiBsaWNlbnNlLWV4ZW1wdCBkZXZp Y2VzIG5lZWRzIHRvIGJlIGFibGUgdG8NCj4+IGRldGVybWluZSBob3cgbG9uZyBpdCBtaWdodCBv cGVyYXRlIHVuZGVyIHRoZSByZWd1bGF0aW9ucyBpbiBhDQo+PiBwYXJ0aWN1bGFyIGNoYW5uZWwv cmVnaW9uLiAgQnVpbGRpbmcgYSBzeXN0ZW0gd2hlcmUgeW91IG5ldmVyIGtub3cgd2hlbg0KPj4g eW91ciBjb21tdW5pY2F0aW9ucyBtaWdodCBnZXQgY3V0IG9mZiBzZWVtcyBsaWtlIGEgYmFkIGlk ZWEuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gUGF1bA0KPj4+DQo+Pj4NCj4+Pj4NCj4+Pj4gT24gMS8y Ny8xMiA1OjI0IFBNLCAiZXh0IFBhdWwgTGFtYmVydCI8cGF1bEBtYXJ2ZWxsLmNvbT4gICB3cm90 ZToNCj4+Pj4NCj4+Pj4+IEl0J3MgZ29vZCB0byBoYXZlIHJlcXVpcmVtZW50cyBiYXNlZCBvbiBz dWNoIGFuIGFuYWx5c2lzLiAgVGhpcyBpcw0KPj4gYW4NCj4+Pj4+IGludGVyZXN0aW5nIHN0YXJ0 LCBidXQgd2UgbWF5IGJlIG1peGluZyB0aHJlYXRzLCB2dWxuZXJhYmlsaXRpZXMgYW5kDQo+Pj4+ PiBtZWNoYW5pc21zLg0KPj4+Pj4NCj4+Pj4+IFRocmVhdHMgYXJlIHR5cGljYWxseSB0aWVkIHRv IGFuIGFjdG9yIC4uLiBodW1hbiBvciBub3QuICBJJ20gbm90DQo+PiBzdXJlDQo+Pj4+PiBpdCdz IHdvcnRoIGdvaW5nIGhhcmQgb3ZlciB0byBzb21ldGhpbmcgbGlrZSB0aGUgTklTVCA4MDAtMzAN Cj4+Pj4gZGVmaW5pdGlvbnMNCj4+Pj4+IG9mIHRocmVhdHMsIGJ1dCB3aXRoaW4gdGhpcyBmcmFt ZXdvcmsgdGhlIHRocmVhdHMgYXJlIEdvdmVybm1lbnRzLA0KPj4+Pj4gZGlzZ3J1bnRsZWQgaW5z aWRlcnMsIHRzdW5hbWlzIGV0Yy4gQmVpbmcgdGhlIElFVEYgd2UgY2FuIGp1bXAgbW9yZQ0KPj4+ Pj4gcXVpY2tseSB0byB0aGUgdGhyZWF0IGV2ZW50IGFuZCBzcGVjaWZpY3Mgb2YgYW4gYXR0YWNr LCBidXQgc2hvdWxkDQo+PiBhdA0KPj4+Pj4gbGVhc3QgZXhwYW5kIHRocmVhdHMgdG8gaW5jbHVk ZSBuYXR1cmFsIGV2ZW50cyBhbmQgY29ubmVjdGl2aXR5DQo+Pj4+IHByb2JsZW1zLg0KPj4+Pj4g Um9idXN0bmVzcyBvciBlbWVyZ2VuY3kgbW9kZXMgbWlnaHQgYmUgaW50ZXJlc3RpbmcgdG8gY29u c2lkZXIuDQo+Pj4+Pg0KPj4+Pj4gV2UgYWxzbyBoYXZlIGEgcHJvYmxlbSBpbiB0aGlzIGFuYWx5 c2lzIG9mIHBlcnNwZWN0aXZlIC0gYXJlIHdlDQo+Pj4+PiBjb25zaWRlcmluZyB0aHJlYXRzIGFz IHZpZXdlZCBmcm9tIHJlZ3VsYXRvcnkgYWdlbmN5IG9yIHRoZSBlbmQNCj4+IGRldmljZQ0KPj4+ Pj4gb3duZXIgb3IgYm90aC4gIFdlIHNob3VsZCBjb25zaWRlciBib3RoIC0gYnV0IHRoZXkgYXJl IGNvbnRyYWRpY3RvcnkNCj4+Pj4+IHBlcnNwZWN0aXZlcy4gIFVzZXJzIHdhbnQgY29udGludWl0 eSBvZiBzZXJ2aWNlLiAgR292ZXJubWVudHMgKHRoZQ0KPj4+Pj4gcmVndWxhdG9ycykgd2FudCBj b250cm9sIG9mIHRoZSBhaXJ3YXZlcy4NCj4+Pj4+DQo+Pj4+PiBNb3N0IG9mIHRoZSByZWFsIHRo cmVhdHMgdGhhdCB3ZSBoYXZlIGFyZSBuZWFybHkgaW1wb3NzaWJsZSB0bw0KPj4gcHJldmVudA0K Pj4+PiBhdA0KPj4+Pj4gdGhlIHByb3RvY29sIGxldmVsLiAgSXQncyBzdGlsbCB3b3J0aCBleGFt aW5pbmcgdGhlIHRocmVhdHMgdG8gc2VlDQo+Pj4+IHdoZXJlDQo+Pj4+PiB3ZSBzdGFuZC4NCj4+ Pj4+DQo+Pj4+PiBPbiB0aGUgY3VycmVudCBkb2N1bWVudCB0aHJlYXRzOg0KPj4+Pj4NCj4+Pj4+ PiBvIEl0IGlzIGFzc3VtZWQgdGhhdCB0aGUgbWFzdGVyIGRldmljZSBvciB0aGUgd2hpdGUgc3Bh Y2UgZGF0YWJhc2UNCj4+Pj4+PiAgICBoYXZlIE5PVCBiZWVuIGNvbXByb21pc2VkIGZyb20gYSBz ZWN1cml0eSBzdGFuZHBvaW50Lg0KPj4+Pj4+DQo+Pj4+Pj4gVGhyZWF0IDE6IE9idGFpbiBtYXN0 ZXIgZGV2aWNlIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24gc2VjcmV0cw0KPj4+Pj4+ICAg ICAgICAgVGhlIG1hc3RlciBkZXZpY2UgbmVlZHMgdG8gYXV0aGVudGljYXRlIGl0c2VsZiB3aXRo IHRoZQ0KPj4gd2hpdGUNCj4+Pj4+PiAgICAgICAgIHNwYWNlIGRhdGFiYXNlIHByaW9yIHRvIHJl cXVlc3RpbmcgY2hhbm5lbCBpbmZvcm1hdGlvbi4gVGhlDQo+Pj4+Pj4gICAgICAgICBhdHRhY2tl ciBtYXkgdHJ5IHRvIGdldCBhY2Nlc3MgdG8gdGhlIHNlY3JldHMgb2YgdGhlIG1hc3Rlcg0KPj4+ Pj4+ICAgICAgICAgZGV2aWNlIHdoaWNoIGNhbiBiZSB1c2VkIG1hbGljaW91c2x5LiBUaGUgZWZm ZWN0IG9mIHN1Y2ggYW4NCj4+Pj4+PiAgICAgICAgIGF0dGFjayBiZWluZyBzdWNjZXNzZnVsIHdv dWxkIHJlc3VsdCBpbiBhIG1hbGljaW91cyBjbGllbnQNCj4+Pj4+PiAgICAgICAgIHJlcGxheWlu ZyB0aGUgc3RvbGVuIGF1dGhlbnRpY2F0aW9uL2F1dGhvcml6YXRpb24gc2VjcmV0cyB0bw0KPj4g YQ0KPj4+Pj4+ICAgICAgICAgd2hpdGUgc3BhY2UgZGF0YWJhc2UuDQo+Pj4+PiBUaGlzIGRvZXMg bm90IHNlZW0gY29uc2lzdGVudCB3aXRoIHRoZSBwcmlvciBzdGF0ZW1lbnQgb2YgIm5vdA0KPj4+ Pj4gY29tcHJvbWlzZWQiLg0KPj4+Pj4gUmVzdGF0ZW1lbnQNCj4+Pj4+DQo+Pj4+PiBUaHJlYXQ6 IFVzZXIgbW9kaWZpZXMgYSBkZXZpY2UgdG8gbWFzcXVlcmFkZSBhcyBhbm90aGVyIHZhbGlkDQo+ PiBjZXJ0aWZpZWQNCj4+Pj4+IGRldmljZS4NCj4+Pj4+DQo+Pj4+PiBUaGlzIGlzIGFuIGludGVy ZXN0aW5nIGNhc2Ugd2hlcmUgdGhyZWF0L3Z1bG5lcmFiaWxpdHkvcmlzayBwbGF5DQo+Pj4+PiB0 b2dldGhlci4gIFRoZSBGQ0Mgb3Igb3RoZXIgcmVndWxhdG9yeSBhZ2VuY2llcyB3YW50IHRyYWNl YWJpbGl0eSBvZg0KPj4+Pj4gZGV2aWNlcy4gIElmIGEgdXNlciB3YW50cyB0byBydW4gYSByb2d1 ZSByYWRpbywgdGhlcmUgaXMgbm8gcmVhc29uDQo+PiB0bw0KPj4+Pj4gYWNjZXNzIHRoZSBkYXRh YmFzZSAobG93IHJpc2sgLSBubyBwYXlvZmYpLiAgVGhlIG9ubHkgcmVhc29uIHRoaXMNCj4+IHdv dWxkDQo+Pj4+PiBiZSBhbiBpbnRlcmVzdGluZyBhdHRhY2sgbWlnaHQgYmUgdG8gYXZvaWQgdHJh Y2tpbmcgYW5kIGhhdmUgc29tZQ0KPj4+Pj4gYW5vbnltaXR5Lg0KPj4+Pj4NCj4+Pj4+PiBUaHJl YXQgMjogU3Bvb2ZlZCB3aGl0ZSBzcGFjZSBkYXRhYmFzZQ0KPj4+Pj4+ICAgICAgICAgQSBtYXN0 ZXIgZGV2aWNlIGRpc2NvdmVycyBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlKHMpIHRocnUNCj4+IHdo aWNoDQo+Pj4+Pj4gICAgICAgICBpdCBjYW4gcXVlcnkgZm9yIGNoYW5uZWwgaW5mb3JtYXRpb24u IFRoZSBtYXN0ZXIgZGV2aWNlDQo+PiBuZWVkcw0KPj4+Pj4+ICAgICAgICAgdG8gZW5zdXJlIHRo YXQgdGhlIHdoaXRlIHNwYWNlIGRhdGFiYXNlIHdpdGggd2hpY2ggaXQNCj4+Pj4+PiAgICAgICAg IGNvbW11bmljYXRlcyB3aXRoIGlzIGFuIGF1dGhlbnRpYyBlbnRpdHkuIFRoZSB3aGl0ZSBzcGFj ZQ0KPj4+Pj4+ICAgICAgICAgZGF0YWJhc2UgbmVlZHMgdG8gcHJvdmlkZSBpdHMgaWRlbnRpdHkg dG8gdGhlIG1hc3RlciBkZXZpY2UNCj4+Pj4+PiAgICAgICAgIHdoaWNoIGNhbiBjb25maXJtIHRo ZSB2YWxpZGl0eS9hdXRoZW50aWN0eSBvZiB0aGUgZGF0YWJhc2UuDQo+PiBBbg0KPj4+Pj4+ICAg ICAgICAgYXR0YWNrZXIgbWF5IGF0dGVtcHQgdG8gc3Bvb2YgYSB3aGl0ZSBzcGFjZSBkYXRhYmFz ZSBhbmQNCj4+Pj4+PiAgICAgICAgIHByb3ZpZGUgcmVzcG9uc2VzIHRvIGEgbWFzdGVyIGRldmlj ZSB3aGljaCBhcmUgbWFsaWNpb3VzIGFuZA0KPj4+Pj4+ICAgICAgICAgcmVzdWx0IGluIHRoZSBt YXN0ZXIgZGV2aWNlIGNhdXNpbmcgaW50ZXJmZXJlbmNlIHRvIHRoZQ0KPj4gcHJpbWFyeQ0KPj4+ Pj4+ICAgICAgICAgdXNlciBvZiB0aGUgc3BlY3RydW0uDQo+Pj4+Pg0KPj4+Pj4gSSB0aGluayB0 aGlzIGlzIHR3byB0eXBlcyBvZiB0aHJlYXQgZXZlbnRzOg0KPj4+Pj4gLSBtYWxpY2lvdXMgZGVu aWFsIG9mIHNlcnZpY2Ugb3IgaW50ZW50aW9uYWwgaW50ZXJmZXJlbmNlIHdpdGgNCj4+Pj4gaW5j dW1iZW50cw0KPj4+Pj4gLSBpbXBlcnNvbmF0aW9uIG9mIHdoaXRlIHNwYWNlIGRhdGFiYXNlIHRv IGVuYWJsZSBvcGVyYXRpb24gb2YgYQ0KPj4+PiBkZXZpY2UNCj4+Pj4+IHRoYXQgbWF5DQo+Pj4+ PiAgICAgbm90IG90aGVyd2lzZSBiZSBwb3NzaWJsZSAoYmxvY2tlZCBkZXZpY2UsIHVuYWxsb2Nh dGVkIGNoYW5uZWxzKS4NCj4+Pj4+IFRoaXMgbWF5IG9yIG1heSBub3QNCj4+Pj4+ICAgICBpbnRl cmZlcmUgd2l0aCBpbmN1bWJlbnQgZGV2aWNlcw0KPj4+Pj4NCj4+Pj4+PiBUaHJlYXQgMzogTW9k aWZ5aW5nIGEgcXVlcnkgcmVxdWVzdA0KPj4+Pj4gLi4uDQo+Pj4+Pg0KPj4+Pj4+IFRocmVhdCA0 OiBNb2RpZnlpbmcgYSBxdWVyeSByZXNwb25zZQ0KPj4+Pj4gU2VlbXMgbGlrZSB0aGVzZSB0d28g Y291bGQgYmUgbHVtcGVkIHRvZ2V0aGVyIC4uLk1pVE0gbW9kaWZpZXMNCj4+IHByb3RvY29sDQo+ Pj4+PiBtZXNzYWdlcyB0bzoNCj4+Pj4+IC0gZGVueSBzZXJ2aWNlDQo+Pj4+PiAtIGludGVyZmVy ZSB3aXRoIGluY3VtYmVudHMNCj4+Pj4+IC0gcHJvdmlkZSB1bmF1dGhvcml6ZWQgY2hhbm5lbCB1 c2FnZSAobW9zdCBsaWtlbHkgcmlzayBJTUhPKQ0KPj4+Pj4NCj4+Pj4+PiBUaHJlYXQgNTogVXNp bmcgcXVlcnkgcmVzcG9uc2UgaW5mb3JtYXRpb24NCj4+Pj4+PiAgICAgICAgIEFuIGF0dGFja2Vy IG1heSBiZSBhIG1hc3RlciBkZXZpY2Ugd2hpY2ggaXMgbm90IGNlcnRpZmllZA0KPj4gZm9yDQo+ Pj4+Pj4gICAgICAgICB1c2UgYnkgdGhlIHJlbGV2YW50IHJlZ3VsYXRvcnkgYm9keS4gVGhlIGF0 dGFja2VyIG1heSBsaXN0ZW4NCj4+IHRvDQo+Pj4+Pj4gICAgICAgICB0aGUgY29tbXVuaWNhdGlv biBiZXR3ZWVuIGEgdmFsaWQgbWFzdGVyIGRldmljZSBhbmQgd2hpdGUNCj4+IHNwYWNlDQo+Pj4+ Pj4gICAgICAgICBkYXRhYmFzZSBhbmQgdXRpbGl6ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgYXZh aWxhYmxlDQo+PiBjaGFubmVscw0KPj4+Pj4+ICAgICAgICAgaW4gdGhlIHJlc3BvbnNlIG1lc3Nh Z2UgYnkgdXRpbGl6aW5nIHRob3NlIGNoYW5uZWxzLiBUaGUNCj4+IHJlc3VsdA0KPj4+Pj4+ICAg ICAgICAgb2Ygc3VjaCBhbiBhdHRhY2sgaXMgdW5hdXRob3JpemVkIHVzZSBvZiBjaGFubmVscyBi eSBhDQo+PiBtYXN0ZXINCj4+Pj4+PiAgICAgICAgIGRldmljZSB3aGljaCBpcyBub3QgY2VydGlm aWVkIHRvIG9wZXJhdGUuDQo+Pj4+PiBBcyBzdGF0ZWQgdGhpcyBpcyBhIG1lY2hhbmlzbSAtIGEg Y2xlYXJlciBzdGF0ZW1lbnQgbWlnaHQgYmUuDQo+Pj4+Pg0KPj4+Pj4gVGhyZWF0OiBVbmF1dGhv cml6ZWQgdXNlIG9mIGNoYW5uZWxzIGJ5IGFuIHVuY2VydGlmaWVkIGRldmljZS4NCj4+Pj4+DQo+ Pj4+PiBBbnlvbmUgY2FuIGFscmVhZHkgZ28gdG8gYSBkYXRhYmFzZSBhbmQgZmluZCBhdmFpbGFi bGUgY2hhbm5lbHMuICBJZg0KPj4gYQ0KPj4+Pj4gZGV2aWNlIGNhbiBvcGVyYXRlIHdpdGhvdXQg Z29pbmcgdG8gdGhlIGRhdGFiYXNlIHRoZXJlIGlzIG5vdGhpbmcNCj4+IHRoYXQNCj4+Pj4+IHBh d3MgY2FuIGRvIHRvIHN0b3AgaXQgb3BlcmF0aW5nIGluIGF2YWlsYWJsZSBvciBub24tYXZhaWxh YmxlDQo+Pj4+IGNoYW5uZWxzLg0KPj4+Pj4NCj4+Pj4+IEp1c3QgdG8gZ2V0IHNvbWUgZGlzY3Vz c2lvbiBnb2luZyAtaGVyZSdzIGEgY291cGxlIG1vcmUgcG9zc2libGUNCj4+Pj4gdGhyZWF0cy4u DQo+Pj4+Pg0KPj4+Pj4gVGhyZWF0OiBUaGlyZCBwYXJ0eSB0cmFja2luZyBvZiB3aGl0ZSBzcGFj ZSBkZXZpY2UgbG9jYXRpb24NCj4+Pj4+ICAgICBMaWtlbHkgYSB2YWx1YWJsZSBjb21tb2RpdHkg dG8gc2VsbCBmb3IgYWR2ZXJ0aXppbmcgd2l0aCBubw0KPj4+PiB0ZWNobmljYWwNCj4+Pj4+IGRl c2lnbiBvciBwb2xpY3kgZm9yIHByaXZhY3kNCj4+Pj4+IFRocmVhdDogRGF0YWJhc2Ugb3duZXIg dGVybWluYXRpb24gb2YgZGV2aWNlIHNlcnZpY2UgZm9yIHJlYXNvbnMNCj4+IG90aGVyDQo+Pj4+ PiB0aGFuIGluY3VtYmVudCBwcm90ZWN0aW9uDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBQ YXVsDQo+Pj4+Pg0KPj4+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+PiBwYXdzQGlldGYu b3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4N Cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdz IG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzDQo= From jussi.kahtava@nokia.com Tue Jan 31 23:31:46 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6A121F858B for ; Tue, 31 Jan 2012 23:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgzwTwuzoMqm for ; Tue, 31 Jan 2012 23:31:38 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4121F8587 for ; Tue, 31 Jan 2012 23:31:36 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q117VW8n015360; Wed, 1 Feb 2012 09:31:32 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Feb 2012 09:31:22 +0200 Received: from 008-AM1MPN1-021.mgdnok.nokia.com ([169.254.1.72]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Wed, 1 Feb 2012 08:31:20 +0100 From: To: , , Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4GhgAXLRm0MfH0eU5prccikhbJYnpdQQ Date: Wed, 1 Feb 2012 07:31:20 +0000 Message-ID: <23293D9BB25E0B48A038B78C7D1D0D5C01E6017B@008-AM1MPN1-021.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-titus-version: 3.3.8.1 x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IlSg3hK9M9mVMN2K3MvzSbjtQa2toVpBPtyLk4og9KxBsi40Kc95VVKZK1DdUx8YToB6V86kKxYpCM9ugZkDUqE/ImmA1gFKKRNmK+2EdsEDuElXX95zqBjt02OMK71UR7Vwd27KeIi9zRI8ldfKpHElQNp5D94PL14FEg/eT1rRDXXDAqGsUymnQ8LElzS5bOUoCd5Rt1GhieAy4zHQ8CnNrLhVqG2f5li0ud2CWkrIjz0l7zaVncPdv/52ZulkQBMOqQEtFSebvTrAySpKA+RA4pgqxyA4BzgnMZf/UurpMvA50m0qbQ3ItWzOnKXClgOaGZH8bnglLJ8VX1vUffc= x-headerinfofordlp: None x-originating-ip: [172.26.105.133] Content-Type: multipart/alternative; boundary="_000_23293D9BB25E0B48A038B78C7D1D0D5C01E6017B008AM1MPN1021mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Feb 2012 07:31:22.0030 (UTC) FILETIME=[7EEF94E0:01CCE0B3] X-Nokia-AV: Clean Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 07:31:46 -0000 --_000_23293D9BB25E0B48A038B78C7D1D0D5C01E6017B008AM1MPN1021mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed by = local regulations for use to be used opportunistica= lly as licensed-exempt spectrum under control of a white space data= base. This way, it is understood that the database does not "assign" white space = devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= "Protected Entity" and "White Space Devices (WSD)" where the notion of sec= ondary use is included. The secondary status is used in the ITU-R Radio Re= gulations for a different purpose. In fact, it is possible that a band has= already primary and secondary services allotted to it and that the White S= pace operation is a tertiary opportunistic operation where the two first ty= pes of services are not being used. The use of "lower priority opportunist= ic" service rather than "secondary" service would be preferable to describe= white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unl= icensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an "unlicensed" band is typically a new ba= nd, say in the 300 GHz, for which no request has been made for its use. It= is therefore un-allocated to a specific service so far and thus it is an "= unlicensed" frequency band. Once the ITU-R allocates this band to one or ma= ny services on a primary or secondary basis, then the administrations can t= hendecide under what king of regime it will 'assign' this band foroperation= . They may decide to allow the use of the band on the basis of licensed ope= ration (with different options to do the assignment: auction, first come/fi= rst served, etc.) or allow operation with an exemption of licenses, thus "l= icense-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicen= sed" in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a "license-exempt" operation. If, h= owever, someone decides to start an RF transmission operation in a licensed= band for which he has no license or in a license-exempt band for which he = does not meet the requirements such as operating according to the type of o= peration for which the band is exempted from a license or he operates outsi= de the technical limits imposed by this license-exempt ruling, his operatio= n is therefore illegal and he is then considered to be running an "unlicens= ed" operation. If the qualifier applies to the transmission device, such device may be a "= license-exempt" device if its operation does not require a specific license= or registration with the local administration such as TV receivers of Wi-F= i devices in the 2.4 GHz ISM band. However, if someone smuggles a device t= hat is not allowed in a country by, for example, buying it on eBay and oper= ates it, this is then an illegal device in the country and id de-facto an "= unlicensed" device since it has not passed through the normal certification= process. Note that a "license-exempt" device still has to go through a certification= process and meet the limits imposed by the local regulator for the "licens= e-exempt" operation in the given frequency band whereas an "unlicensed" dev= ice may not pass the certification process since it has not been licensed t= o operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the = footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licens= ed" operation, the situation will be much simpler to manage since specific = conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word'unlicensed' which may mean 'illegal' operation= of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as 'license-exempt', in most cases the t= erm 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_23293D9BB25E0B48A038B78C7D1D0D5C01E6017B008AM1MPN1021mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That statement is valid f= or TV White Spaces on UHF frequencies but does not necessarily apply to all= under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt?

 <= /p>

Kind regards,<= /span>

Jussi

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Scott,

 

Very good impro= vements. I would suggest to insert the notion of opportunistic use of the s= pectrum by white space devices in the last sentence of the definition of “white space” as follows:

 

White Space<= /span>

 

Radio spectr= um which has been allocated and assigned for licensed use, but is not fully= occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <inser= t>allowed<insert> by local regulations <delete>for use<de= lete> <insert>to be used opportunistically<insert> as licens= ed-exempt spectrum under control of a white space database.</Insert><= o:p>

 

This way, it is= understood that the database does not “assign” white space dev= ices for them to choose from.

 

Gerald

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia= .com]
Sent: Tuesday, 31 January, 2012 15:12
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Hi Gerald,

 <= /o:p>

Good to avoi= d overloading the term "secondary". I have made additional propos= ed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that w= e would need some explanation of what that means. Since we now have descrip= tions of licensed spectrum and license-exempt spectrum, I used these words.= Do these changes remove your concerns?

 <= /o:p>

I also corre= cted "location" to "local" in previous text proposed fo= r "White Space".

 <= /o:p>

Kind Regards= ,

Scott

 <= /o:p>

From: ext= Gerald Chouinard <gera= ld.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@no= kia.com>, "paws@ietf.org&q= uot; <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

&nbs= p;

Scott,

Great propos= al.  However, I am still a bit nervous about the definitions of “= ;Protected Entity” and “White Space Devices (WSD)” where = the notion of secondary use is included.  The secondary status is used in the ITU-R= Radio Regulations for a different purpose.  In fact, it is possible t= hat a band has already primary and secondary services allotted to it and th= at the White Space operation is a tertiary opportunistic operation where the two first types of services are not bein= g used.  The use of “lower priority opportunistic” service= rather than “secondary” service would be preferable to describ= e white space allocations.

 

Gerald =

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Beha= lf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

 =

Hi,

 

I changed= the subject line from " Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.

 

Below is = a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed= ' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should= accurately explain the subject with aim that a reader can understand the u= se cases and the subsequent requirements. No doubt we could include much mo= re text on this topic of spectrum allocation, assignment, licensing and usage.

 

I hope th= is captures the key points of the discussion. Please do reply if something = is still missing.<= o:p>

 

Kind Rega= rds,

Scott=

 

 

2.2. &nbs= p;Terminology=

 

 &nb= sp; Database<= /o:p>

 

 &nb= sp;    In the context of white space and cognitive radio technolo= gies,

 &nb= sp;    the database is an entity which contains current informati= on about

 &nb= sp;    available spectrum at any given location and other types o= f

 &nb= sp;    information.

 

 &nb= sp; Device ID=

 

 &nb= sp;    A unique number for each master device and slave device th= at

 &nb= sp;    identifies the manufacturer, model number and serial numbe= r.

 

<Inser= t>

 &nb= sp; Licensed Spectrum

 

 &nb= sp;    Spectrum that is acquired by an operator over a given serv= ice area

 &nb= sp;    for a given time period.  This is usually done throug= h auctions,award

 &nb= sp;    (beauty contest), acquisition from secondary market, compa= ny merger &

 &nb= sp;    acquisition,  first-come / first-served or by governm= ent allocation

 &nb= sp;    (e.g., public service).

 

 &nb= sp; License-exempt Spectrum

 

 &nb= sp;    Spectrum that is not assigned to any specific user. One ex= ample is the 2.4 Ghz ISM band, where RF devices

 &nb= sp;    operate without a formal licensing process. In the USA, license-exempt spectrum is

 &nb= sp;    Typically referred to as "unlicensed" spectrum. = In this document the terms

 &nb= sp;    license-exempt and unlicensed are used interchangeably.

 

</Inse= rt><= /span>

 

 &nb= sp; Location Based Service

 

 &nb= sp;    An application or device which provides data, information = or

 &nb= sp;    service to a user based on their location.

 

 &nb= sp; Master Device<= o:p>

 

 &nb= sp;    A device which queries the WS Database to find out the ava= ilable<= /span>

 &nb= sp;    operating channels.

 

 &nb= sp; Protected Entity

 

 &nb= sp;    <Insert>A licensed user of spectrum, when the licens= ed spectrum has been assigned as white space spectrum.</Insert> <D= elete>A primary</Delete><Insert>A licensed</Insert> user of white space spectrum <Delete>which&l= t;/Delete> is afforded

 &nb= sp;    protection against interference by <Delete>secondary= </Delete><Insert>license-exempt white space</Insert> user= s <Delete>(white space

 &nb= sp;    devices) for its use</Delete> in a given area and ti= me.

 

 &nb= sp; Protected Contour

 

 &nb= sp;    The exclusion area for a Protected Entity, held in the dat= abase

 &nb= sp;    and expressed as a polygon with geospatial points as the v= ertices.

 

 &nb= sp; Slave Device

 

 &nb= sp;    A device which uses the spectrum made available by a maste= r

 &nb= sp;    device.

 

 &nb= sp; TV White Space=

 

 &nb= sp;    TV white space refers specifically to radio spectrum which= has

 &nb= sp;    been allocated for TV broadcast, but is not occupied by a = TV

 &nb= sp;    broadcast, or other licensed user (such as a wireless micr= ophone),

 &nb= sp;    at a specific location and time.

 

 &nb= sp; White Space

 

 &nb= sp;    Radio spectrum which has been allocated <Delete>for = some primary use</Delete><Insert>and assigned for licensed use&= lt;/Insert>, but

 &nb= sp;    is not fully occupied by that <Delete>primary use<= ;/Delete><Insert> licensed use </Insert> at a specificlocati= on

 &nb= sp;    and time. <Insert>This spectrum is then assigned by = <Delete>location</Delete><Insert>local</Insert> reg= ulations for use as licensed-exempt spectrum under control of a white space database.</Insert>

 

 &nb= sp; White Space Device (WSD)

 

 &nb= sp;   A device which is a <Delete>secondary</Delete>&= lt;Insert>license-exempt</Insert> user of some part of white space= =

 &nb= sp;    spectrum.  A white space device can be an access poin= t, base=

 &nb= sp;    station, a portable device or similar.  In this conte= xt, a white

 &nb= sp;    space device is required to query a database with its loca= tion to=

 &nb= sp;    obtain information about available spectrum.=

 

 

 

From: ext= Gerald Chouinard <gera= ld.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@ear= thlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Nancy,

 

This is not = that simple.  In fact, the qualifiers “license-exempt” and= “unlicensed” can apply to more than one thing.

 

If the quali= fier applies to a frequency band, different options exist. As an example, i= n the ITU-R context, an “unlicensed” band is typically a new band, say in the 300 GHz, for which no request has been made for its use.&= nbsp; It is therefore un-allocated to a specific service so far and thus it= is an “unlicensed” frequency band. Once the ITU-R allocates th= is band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime i= t will ‘assign’ this band foroperation. They may decide to allo= w the use of the band on the basis of licensed operation (with different op= tions to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus ̶= 0;license-exempt”such as in the 2.4 GHz ISM band. This is also called= “unlicensed” in the USA.

 

If the quali= fier applies to an operation, the operation can be exempt of license by the= local administration, thus a “license-exempt” operation. If, however, someone decides to start an RF transmission operation in a li= censed band for which he has no license or in a license-exempt band for whi= ch he does not meet the requirements such as operating according to the typ= e of operation for which the band is exempted from a license or he operates outside the technical limits imp= osed by this license-exempt ruling, his operation is therefore illegal and = he is then considered to be running an “unlicensed” operation.<= /span><= /b>

 

If the quali= fier applies to the transmission device, such device may be a “licens= e-exempt” device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-F= i devices in the 2.4 GHz ISM band.  However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto an “unlicensed” device s= ince it has not passed through the normal certification process.=

 

Note that a = “license-exempt” device still has to go through a certification= process and meet the limits imposed by the local regulator for the “= license-exempt” operation in the given frequency band whereas an “unlicensed” = device may not pass the certification process since it has not been license= d to operation in the country.

 

This is why = the qualifier “unlicensed” has to be treated with care and the = footnote will need to be crafted very carefully.

 

With respect= to your second point, if an administration only allows “licensedR= 21; operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses.

 

Gerald

 

From: Nanc= y Bravin [mailto:nbravin@earthlink= .net]
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 =

Gabor = and Gerald, 

Since = we are dealing on a global basis, can there a footnote to "unlicensed&= quot; we can use to indicate that "according to each countries regulat= ory requirements"  

How to= get around the fact that some Countries are or will be "licensed only= " by their gov'ts?  Thanks

Nancy

On Jan= 30, 2012, at 4:13 PM, Gerald Chouinard wrote:




Gabor,

 

I agree with= your proposal.  Thisseems to be reasonable.  However one needs t= o be careful with the word‘unlicensed’ which may mean ‘il= legal’ operation of an RF device in many administrations.

 

Gerald

 

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Monday, 30 January, 2012 17:49
To: gerald.choui= nard@sympatico.ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 =

These l= ook to be very precise definitions, however in everyday use I rarely hear p= eople referring to ISM band as ‘license-exempt’, in most cases the term ‘unlicensed-band’ is used.

 <= /span><= /b>

Therefo= re, may I suggest that the draft will include the following statement:<= /p>

 <= /span><= /b>

The ter= ms unlicensed and license-exempt spectrum are used in this document interch= angeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band.<= /p>

 <= /span><= /b>

- &nb= sp;        Gabor<= /span>

 <= /span><= /b>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Beha= lf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 =

All,=

 <= /p>

Here is my u= nderstanding of the terms:

 

Licensed: Sp= ectrum that is acquired by an operator over a given service area for a give= n time period.  This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government= allocation (e.g., public service).

 

Lightly lice= nsed: Special case where thefrequency allocation is done through first-come= / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitat= e the deployment of a service that would not normally be economically attra= ctive.  Small local operators would be interested by this (e.g., rural= broadband in Canada) and not big Telcos that would normally work with full licensing through au= ction over large service areas.

 

License-exem= pt: Operation of RF devices in a frequency band where no formal licensing p= rocess is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be cont= acted to clarify it.

 

Unlicensed: = Illegal operation of an RF device that can transmit in a frequency band wit= hout a duly issued license.  In the USA, this term is used to mean “license-exempt," see above.

 

To my knowle= dge, the term “unlicensed” is used only in the USA to describe a legal operation because the term “license-exempt”= ; has been used for another specific purpose.

 

Since the PA= WS addresses the interface to the database for the international market, it= should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of ‘licensed’ and ‘li= cense-exempt’ with a footnote indicating that the term ‘unlicen= sed’ is used in the USA instead of the usual ‘license-exempt’.

 

Gerald

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


 =

_________= ______________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws

--_000_23293D9BB25E0B48A038B78C7D1D0D5C01E6017B008AM1MPN1021mg_--

= 3D"TV

3D"http://66.232.39.132/images/spacer_square_10px.jpg"
TV White Space Spectrum Technologies: Regulations=2C Standards and Applicati= ons explains how to use white space technology to enable the additional spect= rum access that is so badly needed around the world. In this forward-thinking book=2C prominent industry players=2C researchers=2C and standards develo= pers:

  • Examine IEEE and = FCC standards and regulations
  • Highlight pote= ntial business opportunities=2C including broadband Internet applications
  • Address deployment problems likely to arise
  • Discuss system requi= rements=2C spectrum sharing=2C privacy=2C and security

Learn how to use these technologies in practice