From nobody Mon Mar 3 09:00:52 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CD81A024B for ; Mon, 3 Mar 2014 09:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F3tys4a3RrG for ; Mon, 3 Mar 2014 09:00:48 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id A06CD1A026A for ; Mon, 3 Mar 2014 09:00:47 -0800 (PST) Received: from [194.106.220.51:50713] by server-3.bemta-14.messagelabs.com id DD/07-00432-C35B4135; Mon, 03 Mar 2014 17:00:44 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-11.tower-92.messagelabs.com!1393866043!5899584!1 X-Originating-IP: [194.33.160.63] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27273 invoked from network); 3 Mar 2014 17:00:43 -0000 Received: from unknown (HELO WOK-INTRA-EDG01.intra.ofcom.local) (194.33.160.63) by server-11.tower-92.messagelabs.com with AES128-SHA encrypted SMTP; 3 Mar 2014 17:00:43 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG01.intra.ofcom.local (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.3.136.1; Mon, 3 Mar 2014 17:00:42 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%14]) with mapi id 14.03.0136.001; Mon, 3 Mar 2014 17:00:42 +0000 From: Cesar Gutierrez To: "Rosen, Brian" , Gabor Bajko Thread-Topic: [paws] Revised ETSI standard Thread-Index: Ac8zHirAs+k5bdpqR2WDG2AKa+qGPwAK372AACKCKAAAym40IA== Date: Mon, 3 Mar 2014 17:00:45 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655B3CE9370@WOK-INTRA-EXC02.intra.ofcom.local> References: <5D3E853BEE49C848BB63047C794C8655B3CE574E@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/n_cASXww0dCPv78unwaxHsdKkxY Cc: "paws@ietf.org" Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 03 Mar 2014 17:00:51 -0000 Gabor, Brian, I think that what we would be looking for is a new parameter added to the S= pectrumSpec element. I suggest the following: Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter usage location: SpectrumSpec (Section 5.9) Specification document: Specifies the constraint on the device maximum tota= l EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The= values are represented by numeric strings, such as "0", "1", etc. Consul= t the documentation for the specification of the power constrain correspond= ing to each parameter value. It would be great if we could consider this at the WG meeting tomorrow. Thanks and regards, Cesar -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: 27 February 2014 15:51 To: Gabor Bajko Cc: Cesar Gutierrez; paws@ietf.org Subject: Re: [paws] Revised ETSI standard Can do. We'll cover this at the end of the -protocol discussion. Brian On Feb 26, 2014, at 6:22 PM, Gabor Bajko wrote: > The need for this requirement should be discussed on the list; and if > agreed, it can be incorporated by the editor into a future draft > version. > I won't be there in London, but perhaps, if you or someone else could > propose text this week, Brian could add it to next week's agenda. > > - Gabor > > On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez > wrote: >> Dear all, >> >> >> >> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe). >> Most of the changes relate to RF requirements, but there is also an >> additional information element that the database will have to communicat= e to the Master device. >> This element indicates whether simultaneous transmission over >> multiple channels must be restricted in power, and it can take the value= s of 0 and 1. >> >> >> >> EN 301 598 v1.0.9 can be found here: >> >> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf >> >> and the addition I am referring to is described in section 4.2.3.4 >> and in table 4. >> >> >> >> Is it still possible to incorporate this new information element to >> the PAWS specification? >> >> >> >> Thanks and regards, >> >> Cesar >> >> >> >> >> ________________________________ >> >> ********************************************************************* >> ********************************************* >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator >> of the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless >> expressly stated otherwise. >> ********************************************************************* >> ********************************************* >> >> _______________________________________________ >> 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 ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** From nobody Mon Mar 3 22:58:56 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0B61A03C3 for ; Mon, 3 Mar 2014 22:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.447 X-Spam-Level: X-Spam-Status: No, score=-0.447 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o_csTbbH3fE for ; Mon, 3 Mar 2014 22:58:50 -0800 (PST) Received: from ls-mx3.csir.co.za (mx-3.csir.co.za [146.64.10.248]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4521A03A9 for ; Mon, 3 Mar 2014 22:58:39 -0800 (PST) Received: from pta-emo.csir.co.za (pta-emo.csir.co.za [146.64.100.109]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s246wMk4028103 for ; Tue, 4 Mar 2014 08:58:24 +0200 Received: from PTA-EMO-MTA by pta-emo.csir.co.za with Novell_GroupWise; Tue, 04 Mar 2014 08:58:18 +0200 Message-Id: <531595A70200009E0008F0E1@pta-emo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Tue, 04 Mar 2014 08:58:15 +0200 From: "Luzango Mfupe" To: "Gabor Bajko" , "Brian Rosen" , "Cesar Gutierrez" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartC0F28B97.2__=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Tue, 04 Mar 2014 08:58:24 +0200 (SAST) X-CSIR-MailScanner-Information: Please contact the ISP for more information X-CSIR-MailScanner-ID: s246wMk4028103 X-CSIR-MailScanner: Found to be clean X-CSIR-MailScanner-From: lmfupe@csir.co.za X-CSIR-MailScanner-Watermark: 1394521105.22799@a65c/coIyItSOwlKXb0hdg Archived-At: http://mailarchive.ietf.org/arch/msg/paws/_rByE1iHiM532lCgfwuFojPPcj8 Cc: "paws@ietf.org" Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2014 06:58:55 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartC0F28B97.2__= Content-Type: multipart/alternative; boundary="=__PartC0F28B97.3__=" --=__PartC0F28B97.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Cesar, =20 What will be the implications regulatory-wise of not including this new ETS= I requirement in PAWS version 1?, is this not an optional requirement? Regards Luzango. >>> Cesar Gutierrez 03/03/2014 19:00 >>> Gabor, Brian, I think that what we would be looking for is a new parameter added to the S= pectrumSpec element. I suggest the following: Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter usage location: SpectrumSpec (Section 5.9) Specification document: Specifies the constraint on the device maximum tota= l EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The= values are represented by numeric strings, such as "0", "1", etc. Consul= t the documentation for the specification of the power constrain correspond= ing to each parameter value. It would be great if we could consider this at the WG meeting tomorrow. Thanks and regards, Cesar -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: 27 February 2014 15:51 To: Gabor Bajko Cc: Cesar Gutierrez; paws@ietf.org Subject: Re: [paws] Revised ETSI standard Can do. We'll cover this at the end of the -protocol discussion. Brian On Feb 26, 2014, at 6:22 PM, Gabor Bajko wrote: > The need for this requirement should be discussed on the list; and if > agreed, it can be incorporated by the editor into a future draft > version. > I won't be there in London, but perhaps, if you or someone else could > propose text this week, Brian could add it to next week's agenda. > > - Gabor > > On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez > wrote: >> Dear all, >> >> >> >> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe). >> Most of the changes relate to RF requirements, but there is also an >> additional information element that the database will have to communicat= e to the Master device. >> This element indicates whether simultaneous transmission over >> multiple channels must be restricted in power, and it can take the value= s of 0 and 1. >> >> >> >> EN 301 598 v1.0.9 can be found here: >> >> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf >> >> and the addition I am referring to is described in section 4.2.3.4 >> and in table 4. >> >> >> >> Is it still possible to incorporate this new information element to >> the PAWS specification? >> >> >> >> Thanks and regards, >> >> Cesar >> >> >> >> >> ________________________________ >> >> ********************************************************************* >> ********************************************* >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator >> of the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless >> expressly stated otherwise. >> ********************************************************************* >> ********************************************* >> >> _______________________________________________ >> 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 ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --=20 This message is subject to the CSIR's copyright terms and conditions, e-mai= l legal notice, and implemented Open Document Format (ODF) standard.=20 The full disclaimer details can be found at http://www.csir.co.za/disclaime= r.html. This message has been scanned for viruses and dangerous content by MailScan= ner,=20 and is believed to be clean. Please consider the environment before printing this email. --=__PartC0F28B97.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Hi Cesar,
 
What will be the implications regulatory-wise of not including this ne= w ETSI requirement in PAWS version 1?, is this not an optional re= quirement?
Regards
Luzango.

>>> Cesar Gutierrez <Cesar.Gutierrez@ofcom= .org.uk> 03/03/2014 19:00 >>>
Gabor, Brian,

I think t= hat what we would be looking for is a new parameter added to the SpectrumSp= ec element.

I suggest the following:

Parameter name: etsiEnSi= multaneousChannelOperationRestriction
Parameter usage location: Spectrum= Spec (Section 5.9)
Specification document: Specifies the constraint on t= he device maximum total EIRP, as defined by the ETSI Harmonised Standard&nb= sp; [ETSI-EN-301-598].  The values are represented by numeric strings,=   such as "0", "1", etc.  Consult the documentation for the speci= fication of the power constrain corresponding to each parameter value.
<= BR>
It would be great if we could consider this at the WG meeting tomorr= ow.

Thanks and regards,
Cesar


-----Original Message---= --
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: 27 Febru= ary 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; paws@ietf.org
= Subject: Re: [paws] Revised ETSI standard

Can do.  We'll cover = this at the end of the -protocol discussion.

Brian

On Feb 26,= 2014, at 6:22 PM, Gabor Bajko <gaborbajko@gmail.com> wrote:

&= gt; The need for this requirement should be discussed on the list; and if> agreed, it can be incorporated by the editor into a future draft
= > version.
> I won't be there in London, but perhaps, if you or so= meone else could
> propose text this week, Brian could add it to next= week's agenda.
>
> - Gabor
>
> On Wed, Feb 26, 201= 4 at 10:12 AM, Cesar Gutierrez
> <Cesar.Gutierrez@ofcom.org.uk>= wrote:
>> Dear all,
>>
>>
>>
>&g= t; There is a new version available of ETSI EN 301 598 (this is the
>= > standard that lays out the requirements for operation in Europe).
&= gt;> Most of the changes relate to RF requirements, but there is also an=
>> additional information element that the database will have to = communicate to the Master device.
>> This element indicates whethe= r simultaneous transmission over
>> multiple channels must be rest= ricted in power, and it can take the values of 0 and 1.
>>
>= >
>>
>> EN 301 598 v1.0.9 can be found here:
>&g= t;
>> http://www.etsi.org/deliver/etsi_en/301500_301599/301= 598/01.00.09_30/
>> en_301598v010009v.pdf
>>
>&= gt; and the addition I am referring to is described in section 4.2.3.4
&= gt;> and in table 4.
>>
>>
>>
>> Is = it still possible to incorporate this new information element to
>>= ; the PAWS specification?
>>
>>
>>
>> T= hanks and regards,
>>
>> Cesar
>>
>>>>
>>
>> ________________________________
>&= gt;
>> ***********************************************************= **********
>> *********************************************
>= ;> For more information visit www.ofcom.org.uk
>>
>> T= his email (and any attachments) is confidential and intended for the
>= ;> use of the addressee only.
>>
>> If you have receiv= ed this email in error please notify the originator
>> of the mess= age and delete it from your system.
>>
>> This email has = been scanned for viruses. However, you open any
>> attachments at = your own risk.
>>
>> Any views expressed in this message = are those of the individual
>> sender and do not represent the vie= ws or opinions of Ofcom unless
>> expressly stated otherwise.
&= gt;> *******************************************************************= **
>> *********************************************
>>>> _______________________________________________
>> paws = mailing list
>> paws@ietf.org
>> https://www.ietf.org/mailman/listinfo/paws
>>
>
> ____________________________________________= ___
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listin= fo/paws


________________________________

************= ***************************************************************************= ***************************
For more information visit www.ofcom.org.uk<= BR>
This email (and any attachments) is confidential and intended for th= e use of the addressee only.

If you have received this email in erro= r please notify the originator of the message and delete it from your syste= m.

This email has been scanned for viruses. However, you open any at= tachments at your own risk.

Any views expressed in this message are = those of the individual sender and do not represent the views or opinions o= f Ofcom unless expressly stated otherwise.
*****************************= ***************************************************************************= **********



--=20
This message is subject to the CSIR's copyright terms and conditions,= e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email. --=__PartC0F28B97.3__=-- --=__PartC0F28B97.2__=-- From nobody Tue Mar 4 02:59:21 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218AF1A067A for ; Tue, 4 Mar 2014 02:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzB3yuQo5ikq for ; Tue, 4 Mar 2014 02:59:13 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 9E62F1A02CE for ; Tue, 4 Mar 2014 02:59:12 -0800 (PST) Received: from [194.106.220.51:6416] by server-1.bemta-14.messagelabs.com id 15/99-29588-CF1B5135; Tue, 04 Mar 2014 10:59:08 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-6.tower-92.messagelabs.com!1393930741!14689217!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17152 invoked from network); 4 Mar 2014 10:59:01 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-6.tower-92.messagelabs.com with AES128-SHA encrypted SMTP; 4 Mar 2014 10:59:01 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 4 Mar 2014 10:59:01 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%14]) with mapi id 14.03.0136.001; Tue, 4 Mar 2014 10:59:00 +0000 From: Cesar Gutierrez To: Luzango Mfupe , Gabor Bajko , Brian Rosen Thread-Topic: [paws] Revised ETSI standard Thread-Index: AQHPN3cds+k5bdpqR2WDG2AKa+qGP5rQvSDA Date: Tue, 4 Mar 2014 10:59:04 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655B3CE98DD@WOK-INTRA-EXC02.intra.ofcom.local> References: <531595A70200009E0008F0E1@pta-emo.csir.co.za> In-Reply-To: <531595A70200009E0008F0E1@pta-emo.csir.co.za> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655B3CE98DDWOKINTRAEXC02in_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/mb12FJiH0OrenD1lktOxfBbhvkI Cc: "paws@ietf.org" Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2014 10:59:19 -0000 --_000_5D3E853BEE49C848BB63047C794C8655B3CE98DDWOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Luzango, Support for this parameter is mandatory in ETSI EN 301 598. A device manufa= cturer that chooses the route of compliance with the ETSI EN to put product= s in the EU market will have to implement it. Secondly, Ofcom will most lik= ely require WS databases and devices to support the parameter when we set u= p the licence exemption regime next year. This doesn't mean it must be supported in PAWS right now. Database provider= s and device manufacturers using PAWS could implement it as a proprietary a= ddendum. However, it would make a lot of sense to include it in PAWS at thi= s stage in my view. It would be preferable that the PAWS specification support all functionalit= y required by the current version of the ETSI EN. This version of the ETSI = EN is now at the stage of a vote by national standard organisations, and it= is very very unlikely to change. Additional functionality cannot be incorp= orated now - an new work item needs to be started in ETSI for this, and it = will take more than a year to get to a stable draft anyway. It is therefore= a good point in time to align both documents. In summary, regulatory-wise it is not an absolute must, but it will be high= ly advisable. Regards, Cesar From: Luzango Mfupe [mailto:LMfupe@csir.co.za] Sent: 04 March 2014 06:58 To: Gabor Bajko; Brian Rosen; Cesar Gutierrez Cc: paws@ietf.org Subject: Re: [paws] Revised ETSI standard Hi Cesar, What will be the implications regulatory-wise of not including this new ETS= I requirement in PAWS version 1?, is this not an optional requirement? Regards Luzango. >>> Cesar Gutierrez > 03/03/2014 19:00 >>> Gabor, Brian, I think that what we would be looking for is a new parameter added to the S= pectrumSpec element. I suggest the following: Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter usage location: SpectrumSpec (Section 5.9) Specification document: Specifies the constraint on the device maximum tota= l EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The= values are represented by numeric strings, such as "0", "1", etc. Consul= t the documentation for the specification of the power constrain correspond= ing to each parameter value. It would be great if we could consider this at the WG meeting tomorrow. Thanks and regards, Cesar -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: 27 February 2014 15:51 To: Gabor Bajko Cc: Cesar Gutierrez; paws@ietf.org Subject: Re: [paws] Revised ETSI standard Can do. We'll cover this at the end of the -protocol discussion. Brian On Feb 26, 2014, at 6:22 PM, Gabor Bajko > wrote: > The need for this requirement should be discussed on the list; and if > agreed, it can be incorporated by the editor into a future draft > version. > I won't be there in London, but perhaps, if you or someone else could > propose text this week, Brian could add it to next week's agenda. > > - Gabor > > On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez > > wrote= : >> Dear all, >> >> >> >> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe). >> Most of the changes relate to RF requirements, but there is also an >> additional information element that the database will have to communicat= e to the Master device. >> This element indicates whether simultaneous transmission over >> multiple channels must be restricted in power, and it can take the value= s of 0 and 1. >> >> >> >> EN 301 598 v1.0.9 can be found here: >> >> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf >> >> and the addition I am referring to is described in section 4.2.3.4 >> and in table 4. >> >> >> >> Is it still possible to incorporate this new information element to >> the PAWS specification? >> >> >> >> Thanks and regards, >> >> Cesar >> >> >> >> >> ________________________________ >> >> ********************************************************************* >> ********************************************* >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator >> of the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless >> expressly stated otherwise. >> ********************************************************************* >> ********************************************* >> >> _______________________________________________ >> 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 ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** -- This message is subject to the CSIR's copyright terms and conditions, e-mai= l legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaime= r.html. This message has been scanned for viruses and dangerous content by MailScan= ner, and is believed to be clean. Please consider the environment before printing this email. ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_5D3E853BEE49C848BB63047C794C8655B3CE98DDWOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Luzango,

Support for this paramete= r is mandatory in ETSI EN 301 598. A device manufacturer that chooses the r= oute of compliance with the ETSI EN to put products in the EU market will have to implement it. Secondly, Ofcom will most likely requ= ire WS databases and devices to support the parameter when we set up the li= cence exemption regime next year.

This doesn’t mean i= t must be supported in PAWS right now. Database providers and device manufa= cturers using PAWS could implement it as a proprietary addendum. However, it would make a lot of sense to include it in PAWS at this stage = in my view.

It would be preferable th= at the PAWS specification support all functionality required by the current= version of the ETSI EN. This version of the ETSI EN is now at the stage of a vote by national standard organisations, and it is v= ery very unlikely to change. Additional functionality cannot be incorporate= d now – an new work item needs to be started in ETSI for this, and it= will take more than a year to get to a stable draft anyway. It is therefore a good point in time to align both = documents.

In summary, regulatory-wi= se it is not an absolute must, but it will be highly advisable.

Regards,

Cesar

 

From: Luzango= Mfupe [mailto:LMfupe@csir.co.za]
Sent: 04 March 2014 06:58
To: Gabor Bajko; Brian Rosen; Cesar Gutierrez
Cc: paws@ietf.org
Subject: Re: [paws] Revised ETSI standard

 

Hi Cesar,

 

What will be the implications regulatory-wise of not including this = new ETSI requirement in PAWS version 1?, is this not an optional requirement?

Regards

Luzango.

>>> Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> 03/03/2014 19:00 >>> Gabor, Brian,

I think that what we would be looking for is a new parameter added to the S= pectrumSpec element.

I suggest the following:

Parameter name: etsiEnSimultaneousChannelOperationRestriction
Parameter usage location: SpectrumSpec (Section 5.9)
Specification document: Specifies the constraint on the device maximum tota= l EIRP, as defined by the ETSI Harmonised Standard  [ETSI-EN-301-598].=   The values are represented by numeric strings,  such as "0= ", "1", etc.  Consult the documentation for the specifi= cation of the power constrain corresponding to each parameter value.


It would be great if we could consider this at the WG meeting tomorrow.

Thanks and regards,
Cesar


-----Original Message-----
From: Rosen, Brian [mailto:Brian= .Rosen@neustar.biz]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; paws@ietf.org
Subject: Re: [paws] Revised ETSI standard

Can do.  We'll cover this at the end of the -protocol discussion.

Brian

On Feb 26, 2014, at 6:22 PM, Gabor Bajko <gaborbajko@gmail.com> wrote:

> The need for this requirement should be discussed on the list; and if<= br> > agreed, it can be incorporated by the editor into a future draft
> version.
> I won't be there in London, but perhaps, if you or someone else could<= br> > propose text this week, Brian could add it to next week's agenda.
>
> - Gabor
>
> On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez
> <Cesar.Gutierrez@of= com.org.uk> wrote:
>> Dear all,
>>
>>
>>
>> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe).<= br> >> Most of the changes relate to RF requirements, but there is also a= n
>> additional information element that the database will have to comm= unicate to the Master device.
>> This element indicates whether simultaneous transmission over
>> multiple channels must be restricted in power, and it can take the= values of 0 and 1.
>>
>>
>>
>> EN 301 598 v1.0.9 can be found here:
>>
>> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf
>>
>> and the addition I am referring to is described in section 4.2.3.4=
>> and in table 4.
>>
>>
>>
>> Is it still possible to incorporate this new information element t= o
>> the PAWS specification?
>>
>>
>>
>> Thanks and regards,
>>
>> Cesar
>>
>>
>>
>>
>> ________________________________
>>
>> ******************************************************************= ***
>> *********************************************
>> For more information visit www= .ofcom.org.uk
>>
>> This email (and any attachments) is confidential and intended for = the
>> use of the addressee only.
>>
>> If you have received this email in error please notify the origina= tor
>> of the message and delete it from your system.
>>
>> This email has been scanned for viruses. However, you open any
>> attachments at your own risk.
>>
>> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless<= br> >> expressly stated otherwise.
>> ******************************************************************= ***
>> *********************************************
>>
>> _______________________________________________
>> paws mailing list
>> paws@ietf.org
>> https://www= .ietf.org/mailman/listinfo/paws
>>
>
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.iet= f.org/mailman/listinfo/paws


________________________________

***************************************************************************= ***************************************
For more information visit www.ofcom.or= g.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************


--
This message is subject to the CSIR's copyright terms and conditions, e-mai= l legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.


Please consider the environment before printing this email.



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_5D3E853BEE49C848BB63047C794C8655B3CE98DDWOKINTRAEXC02in_-- From nobody Tue Mar 4 10:40:49 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8011A01B0 for ; Tue, 4 Mar 2014 10:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2luc4-ta7BB for ; Tue, 4 Mar 2014 10:40:44 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDFB1A027D for ; Tue, 4 Mar 2014 10:40:44 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wn1so3057355obc.16 for ; Tue, 04 Mar 2014 10:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tXLeAndaonCRGf0kDbtM70cWmd6WTVtynuymlYyQWf0=; b=GphfKAHhcWQ5hc4b/xiAqIsJ2S1azuhxAdMuhItmc69XfcWLtZIBekjfxXOPDt1l4P oEOfuqDxmoiTOctg84HRBJHOrTzf8kacUX94piZVWGPMnIBQHmuAixU1i8EdEQOWkk96 bg4y791tFRDcHORXhf1QUtRtKO3PMpincgu6KfBBjHiATDjBgp+iv18tIG13iDC4K5A8 uG87x+5i9ybAEm4vXHzHr/ggDb4NfZxTx5L5tZXutz8veJzjSCZdq4GYy1fLlUoH0JXu SkNvv7evzothz6SuH4Vnt7UHcNUaXn+HPBC/TYS0o0n9JksmsjzRNMdpNttKZ5uvvlMT 5hLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tXLeAndaonCRGf0kDbtM70cWmd6WTVtynuymlYyQWf0=; b=KleJMY/NbHv7p5F7V778yVtsodlfTCFle9h0ligsDcTLvIYM0vxs9V/H8/tKZbfrre hH8wVvifp6eca45BFUYiTGjppsQr5ymu/Vtfm+ulfBp1Dt15ZEAQ29jU0EjUAgT/Gta4 Jt31stFfNFmbyvSWsiFPSxOR7N72G4I8bGMSrK4FH4eukekNqCFBpiM5yVt7pUmjjk3P 8VOlni3zE3ko8J2B5iz7w2bMpHFqD23j5fKH2PG5IdNlYN+Orig8ru6r98bdfmYBy1Fl mrCMB/DxSJ/2HIkhFiDR233dPuY1jMltqZWD1Y2RCJcySgHtFNxXX8bG+bmIj9qDg+oJ qAcw== X-Gm-Message-State: ALoCoQnXbFwN+Q2EuK1mpY1QQbTPhdnke+CHqLiqDvohXSommKeofLYl8RgIfiwrPOaNOb5Otz6WLl48aQ0cm0hKvUUYsxW9te9w1mg30Y90tJha2d4Xw/rWnOOF2NAXxpXJ6TuGa3Cx5CyCgWAu+NJPeRTZMbLxqKpBnEHHdUUcY1+o73IHgFsBI75SVa54Bo1FCjbS+Y+u MIME-Version: 1.0 X-Received: by 10.182.97.67 with SMTP id dy3mr808609obb.84.1393956572065; Tue, 04 Mar 2014 10:09:32 -0800 (PST) Received: by 10.182.45.166 with HTTP; Tue, 4 Mar 2014 10:09:31 -0800 (PST) In-Reply-To: <5D3E853BEE49C848BB63047C794C8655B3CE98DD@WOK-INTRA-EXC02.intra.ofcom.local> References: <531595A70200009E0008F0E1@pta-emo.csir.co.za> <5D3E853BEE49C848BB63047C794C8655B3CE98DD@WOK-INTRA-EXC02.intra.ofcom.local> Date: Tue, 4 Mar 2014 10:09:31 -0800 Message-ID: From: Vincent Chen To: Cesar Gutierrez Content-Type: multipart/alternative; boundary=047d7b2e4c024f8c5004f3cbcea3 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/wGoQAPL_wuub5jXvC03lvbxs6wM Cc: "paws@ietf.org" , Luzango Mfupe Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2014 18:40:48 -0000 --047d7b2e4c024f8c5004f3cbcea3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cesar, Looking at the ETSI EN 301 598 v1.0.9 doc, it looks like this parameter is optional: Within Table 4: "The default value is 0" Note 2: "If the simultaneous channel operation power restriction parameter is not provided, ..." So I would list this as an OPTIONAL parameter in section 9.2.2.2 (the IANA section for ETSI specifics). Does that sound right? Thanks. -vince On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez < Cesar.Gutierrez@ofcom.org.uk> wrote: > Luzango, > > Support for this parameter is mandatory in ETSI EN 301 598. A device > manufacturer that chooses the route of compliance with the ETSI EN to put > products in the EU market will have to implement it. Secondly, Ofcom will > most likely require WS databases and devices to support the parameter whe= n > we set up the licence exemption regime next year. > > This doesn=E2=80=99t mean it must be supported in PAWS right now. Databas= e > providers and device manufacturers using PAWS could implement it as a > proprietary addendum. However, it would make a lot of sense to include it > in PAWS at this stage in my view. > > It would be preferable that the PAWS specification support all > functionality required by the current version of the ETSI EN. This versio= n > of the ETSI EN is now at the stage of a vote by national standard > organisations, and it is very very unlikely to change. Additional > functionality cannot be incorporated now =E2=80=93 an new work item needs= to be > started in ETSI for this, and it will take more than a year to get to a > stable draft anyway. It is therefore a good point in time to align both > documents. > > In summary, regulatory-wise it is not an absolute must, but it will be > highly advisable. > > Regards, > > Cesar > > > > *From:* Luzango Mfupe [mailto:LMfupe@csir.co.za] > *Sent:* 04 March 2014 06:58 > *To:* Gabor Bajko; Brian Rosen; Cesar Gutierrez > *Cc:* paws@ietf.org > > *Subject:* Re: [paws] Revised ETSI standard > > > > Hi Cesar, > > > > What will be the implications regulatory-wise of not including this new > ETSI requirement in PAWS version 1?, is this not an optional requirement? > > Regards > > Luzango. > > >>> Cesar Gutierrez 03/03/2014 19:00 >>> > Gabor, Brian, > > I think that what we would be looking for is a new parameter added to the > SpectrumSpec element. > > I suggest the following: > > Parameter name: etsiEnSimultaneousChannelOperationRestriction > Parameter usage location: SpectrumSpec (Section 5.9) > Specification document: Specifies the constraint on the device maximum > total EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]= . > The values are represented by numeric strings, such as "0", "1", etc. > Consult the documentation for the specification of the power constrain > corresponding to each parameter value. > > > It would be great if we could consider this at the WG meeting tomorrow. > > Thanks and regards, > Cesar > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz > ] > Sent: 27 February 2014 15:51 > To: Gabor Bajko > Cc: Cesar Gutierrez; paws@ietf.org > Subject: Re: [paws] Revised ETSI standard > > Can do. We'll cover this at the end of the -protocol discussion. > > Brian > > On Feb 26, 2014, at 6:22 PM, Gabor Bajko wrote: > > > The need for this requirement should be discussed on the list; and if > > agreed, it can be incorporated by the editor into a future draft > > version. > > I won't be there in London, but perhaps, if you or someone else could > > propose text this week, Brian could add it to next week's agenda. > > > > - Gabor > > > > On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez > > wrote: > >> Dear all, > >> > >> > >> > >> There is a new version available of ETSI EN 301 598 (this is the > >> standard that lays out the requirements for operation in Europe). > >> Most of the changes relate to RF requirements, but there is also an > >> additional information element that the database will have to > communicate to the Master device. > >> This element indicates whether simultaneous transmission over > >> multiple channels must be restricted in power, and it can take the > values of 0 and 1. > >> > >> > >> > >> EN 301 598 v1.0.9 can be found here: > >> > >> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ > >> en_301598v010009v.pdf > >> > >> and the addition I am referring to is described in section 4.2.3.4 > >> and in table 4. > >> > >> > >> > >> Is it still possible to incorporate this new information element to > >> the PAWS specification? > >> > >> > >> > >> Thanks and regards, > >> > >> Cesar > >> > >> > >> > >> > >> ________________________________ > >> > >> ********************************************************************* > >> ********************************************* > >> For more information visit www.ofcom.org.uk > >> > >> This email (and any attachments) is confidential and intended for the > >> use of the addressee only. > >> > >> If you have received this email in error please notify the originator > >> of the message and delete it from your system. > >> > >> This email has been scanned for viruses. However, you open any > >> attachments at your own risk. > >> > >> Any views expressed in this message are those of the individual > >> sender and do not represent the views or opinions of Ofcom unless > >> expressly stated otherwise. > >> ********************************************************************* > >> ********************************************* > >> > >> _______________________________________________ > >> 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 > > > ________________________________ > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > > > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > > This message has been scanned for viruses and dangerous content by > *MailScanner* , > and is believed to be clean. > > > Please consider the environment before printing this email. > > ------------------------------ > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --047d7b2e4c024f8c5004f3cbcea3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Cesar,

Looking at the ETSI EN 301 598 v= 1.0.9 doc, it looks like this parameter is optional:

=C2=A0 Within Table 4: =C2=A0"The default value is 0"
=C2=A0 Note 2: "If the simultaneous channel operation power restrict= ion parameter is not provided, ..."

So I would list this as an OPTIONAL parameter in sectio= n 9.2.2.2 (the IANA section for ETSI specifics).
Does that sound = right?

Thanks.

-vince


On Tue,= Mar 4, 2014 at 2:59 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom= .org.uk> wrote:

Luzango,

Support for this parameter = is mandatory in ETSI EN 301 598. A device manufacturer that chooses the rou= te of compliance with the ETSI EN to put products in the EU market will have to implement it. Secondly, Ofcom will most likely requ= ire WS databases and devices to support the parameter when we set up the li= cence exemption regime next year.

This doesn=E2=80=99t mean i= t must be supported in PAWS right now. Database providers and device manufa= cturers using PAWS could implement it as a proprietary addendum. However, it would make a lot of sense to include it in PAWS at this stage = in my view.

It would be preferable that= the PAWS specification support all functionality required by the current v= ersion of the ETSI EN. This version of the ETSI EN is now at the stage of a vote by national standard organisations, and it is v= ery very unlikely to change. Additional functionality cannot be incorporate= d now =E2=80=93 an new work item needs to be started in ETSI for this, and = it will take more than a year to get to a stable draft anyway. It is therefore a good point in time to align both = documents.

In summary, regulatory-wise= it is not an absolute must, but it will be highly advisable.

Regards,

Cesar

=C2=A0

From: Luzango Mf= upe [mailto:LMfupe@c= sir.co.za]
Sent: 04 March 2014 06:58
To: Gabor Bajko; Brian Rosen; Cesar Gutierrez
Cc: paws@ietf.org=


Subject: Re: [paws] Revised ETSI standard

=C2=A0

Hi Cesar,

=C2=A0

What will be the implications regulatory-wise of not including this ne= w ETSI=C2=A0requirement=C2=A0in PAWS version 1?, is this not an optional requirement?

Regards

Luzango.

>>> Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> 03/03/2014 19:= 00 >>>
Gabor, Brian,

I think that what we would be looking for is a new parameter added to the S= pectrumSpec element.

I suggest the following:

Parameter name: etsiEnSimultaneousChannelOperationRestriction
Parameter usage location: SpectrumSpec (Section 5.9)
Specification document: Specifies the constraint on the device maximum tota= l EIRP, as defined by the ETSI Harmonised Standard=C2=A0 [ETSI-EN-301-598].= =C2=A0 The values are represented by numeric strings,=C2=A0 such as "0= ", "1", etc.=C2=A0 Consult the documentation for the specifi= cation of the power constrain corresponding to each parameter value.


It would be great if we could consider this at the WG meeting tomorrow.

Thanks and regards,
Cesar


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; paw= s@ietf.org
Subject: Re: [paws] Revised ETSI standard

Can do.=C2=A0 We'll cover this at the end of the -protocol discussion.<= br>
Brian

On Feb 26, 2014, at 6:22 PM, Gabor Bajko <gaborbajko@gmail.com> wrote:

> The need for this requirement should be discussed on the list; and if<= br> > agreed, it can be incorporated by the editor into a future draft
> version.
> I won't be there in London, but perhaps, if you or someone else co= uld
> propose text this week, Brian could add it to next week's agenda.<= br> >
> - Gabor
>
> On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez
> <= Cesar.Gutierrez@ofcom.org.uk> wrote:
>> Dear all,
>>
>>
>>
>> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe).<= br> >> Most of the changes relate to RF requirements, but there is also a= n
>> additional information element that the database will have to comm= unicate to the Master device.
>> This element indicates whether simultaneous transmission over
>> multiple channels must be restricted in power, and it can take the= values of 0 and 1.
>>
>>
>>
>> EN 301 598 v1.0.9 can be found here:
>>
>> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf
>>
>> and the addition I am referring to is described in section 4.2.3.4=
>> and in table 4.
>>
>>
>>
>> Is it still possible to incorporate this new information element t= o
>> the PAWS specification?
>>
>>
>>
>> Thanks and regards,
>>
>> Cesar
>>
>>
>>
>>
>> ________________________________
>>
>> ******************************************************************= ***
>> *********************************************
>> For more information visit www.ofcom.org.uk
>>
>> This email (and any attachments) is confidential and intended for = the
>> use of the addressee only.
>>
>> If you have received this email in error please notify the origina= tor
>> of the message and delete it from your system.
>>
>> This email has been scanned for viruses. However, you open any
>> attachments at your own risk.
>>
>> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless<= br> >> expressly stated otherwise.
>> ******************************************************************= ***
>> *********************************************
>>
>> _______________________________________________
>> 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


________________________________

***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************


--
This message is subject to the CSIR's copyright terms and conditions, e= -mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.


Please consider the environment before printing this email.



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************

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




--
-vince
--047d7b2e4c024f8c5004f3cbcea3-- From nobody Tue Mar 4 10:56:41 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40711A0255 for ; Tue, 4 Mar 2014 10:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMZdhyhb0GsK for ; Tue, 4 Mar 2014 10:56:31 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA151A017B for ; Tue, 4 Mar 2014 10:56:29 -0800 (PST) Received: from [85.158.137.35:39674] by server-11.bemta-3.messagelabs.com id BB/F6-04255-8D126135; Tue, 04 Mar 2014 18:56:24 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-7.tower-134.messagelabs.com!1393959383!26686278!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27158 invoked from network); 4 Mar 2014 18:56:24 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-7.tower-134.messagelabs.com with AES128-SHA encrypted SMTP; 4 Mar 2014 18:56:24 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.3.136.1; Tue, 4 Mar 2014 18:56:23 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%14]) with mapi id 14.03.0136.001; Tue, 4 Mar 2014 18:56:23 +0000 From: Cesar Gutierrez To: Vincent Chen Thread-Topic: [paws] Revised ETSI standard Thread-Index: AQHPN3cds+k5bdpqR2WDG2AKa+qGP5rQvSDAgAB9uYCAAAmR0A== Date: Tue, 4 Mar 2014 18:56:27 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655B3CE9E1B@WOK-INTRA-EXC02.intra.ofcom.local> References: <531595A70200009E0008F0E1@pta-emo.csir.co.za> <5D3E853BEE49C848BB63047C794C8655B3CE98DD@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655B3CE9E1BWOKINTRAEXC02in_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/tyLVQmvsdFgg6sneJ09SBau7zYQ Cc: "paws@ietf.org" , Luzango Mfupe Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 04 Mar 2014 18:56:40 -0000 --_000_5D3E853BEE49C848BB63047C794C8655B3CE9E1BWOKINTRAEXC02in_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmluY2UsDQoNCkkgcmVjb2duaXNlIHRoYXQgdGhlIEVUU0kgc3RhbmRhcmQgaXMgbm90IHZlcnkg Y2xlYXIgb24gdGhpcyBhbmQgcGVvcGxlIG1heSBlbmQgdXAgd2l0aCBkaWZmZXJlbnQgaW50ZXJw cmV0YXRpb25zLiBUaGUgaW50ZW50aW9uIGlzIHRoYXQgZGV2aWNlcyBtdXN0IHN1cHBvcnQgdGhh dCBwYXJhbWV0ZXIuIEhvd2V2ZXIsIGlmIHRoZSBkYXRhYmFzZSBkb2VzIG5vdCBzZW5kIGl0IHRo ZW4gdGhlIGRldmljZSBtdXN0IHJlYWN0IGFzIGlmIHRoZSBkZWZhdWx0IHZhbHVlIGhhZCBiZWVu IHByb3ZpZGVkLg0KDQpUaGUgcmF0aW9uYWxlIGlzIHRoYXQgdGhlIHBvd2VyIGNvbnN0cmFpbnQg aW5kaWNhdGVkIGJ5IGEgdmFsdWUgb2YgMSB3aWxsIG9ubHkgYmUgYWN0aXZhdGVkIGluIHNwZWNp YWwgb2NjYXNpb25zLCBmb3IgaW5zdGFuY2Ugd2hlbiB0aGVyZSBpcyBhIGhpZ2ggY29uY2VudHJh dGlvbiBvZiBkZXZpY2VzLiBUaGUgcmVzdCBvZiB0aGUgdGltZSB0aGUgdmFsdWUgd291bGQgYmUg ZWl0aGVyIDAgb3Igbm90IGNvbW11bmljYXRlZC4NCg0KVGhlIEVUU0kgc3RhbmRhcmQgIGRlYWxz IHdpdGggZGV2aWNlIHJlcXVpcmVtZW50cyBvbmx5LCBhbmQgZG9lcyB0d28gdGhpbmdzIGluIG15 IHZpZXc6DQoNCjEpICAgIGl0IHJlcXVpcmVzIHRoYXQgZGV2aWNlcyBzdXBwb3J0IHRoZSBwYXJh bWV0ZXIsIGFuZA0KDQoyKSAgICBpdCBzcGVjaWZpZXMgdGhlIGJlaGF2aW91ciBvZiB0aGUgZGV2 aWNlIGluIGJvdGggc2NlbmFyaW9zOiAxKSB0aGUgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGFuZCAy KSB0aGUgcGFyYW1ldGVyIGlzIG5vdCBwcm92aWRlZCAoanVzdCBpbiBjYXNlKS4NCg0KSSBhbSBu b3Qgc3VyZSB3aGV0aGVyIHRoaXMgbWFrZXMgdGhlIHBhcmFtZXRlciBvcHRpb25hbCBmcm9tIHRo ZSBwZXJzcGVjdGl2ZSBvZiBQQVdTLg0KDQpSZWdhcmRzLA0KQ2VzYXINCg0KRnJvbTogVmluY2Vu dCBDaGVuIFttYWlsdG86dmNoZW5AZ29vZ2xlLmNvbV0NClNlbnQ6IDA0IE1hcmNoIDIwMTQgMTg6 MTANClRvOiBDZXNhciBHdXRpZXJyZXoNCkNjOiBMdXphbmdvIE1mdXBlOyBHYWJvciBCYWprbzsg QnJpYW4gUm9zZW47IHBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcGF3c10gUmV2aXNlZCBF VFNJIHN0YW5kYXJkDQoNCkNlc2FyLA0KDQpMb29raW5nIGF0IHRoZSBFVFNJIEVOIDMwMSA1OTgg djEuMC45IGRvYywgaXQgbG9va3MgbGlrZSB0aGlzIHBhcmFtZXRlciBpcyBvcHRpb25hbDoNCg0K ICBXaXRoaW4gVGFibGUgNDogICJUaGUgZGVmYXVsdCB2YWx1ZSBpcyAwIg0KICBOb3RlIDI6ICJJ ZiB0aGUgc2ltdWx0YW5lb3VzIGNoYW5uZWwgb3BlcmF0aW9uIHBvd2VyIHJlc3RyaWN0aW9uIHBh cmFtZXRlciBpcyBub3QgcHJvdmlkZWQsIC4uLiINCg0KU28gSSB3b3VsZCBsaXN0IHRoaXMgYXMg YW4gT1BUSU9OQUwgcGFyYW1ldGVyIGluIHNlY3Rpb24gOS4yLjIuMiAodGhlIElBTkEgc2VjdGlv biBmb3IgRVRTSSBzcGVjaWZpY3MpLg0KRG9lcyB0aGF0IHNvdW5kIHJpZ2h0Pw0KDQpUaGFua3Mu DQoNCi12aW5jZQ0KDQpPbiBUdWUsIE1hciA0LCAyMDE0IGF0IDI6NTkgQU0sIENlc2FyIEd1dGll cnJleiA8Q2VzYXIuR3V0aWVycmV6QG9mY29tLm9yZy51azxtYWlsdG86Q2VzYXIuR3V0aWVycmV6 QG9mY29tLm9yZy51az4+IHdyb3RlOg0KTHV6YW5nbywNClN1cHBvcnQgZm9yIHRoaXMgcGFyYW1l dGVyIGlzIG1hbmRhdG9yeSBpbiBFVFNJIEVOIDMwMSA1OTguIEEgZGV2aWNlIG1hbnVmYWN0dXJl ciB0aGF0IGNob29zZXMgdGhlIHJvdXRlIG9mIGNvbXBsaWFuY2Ugd2l0aCB0aGUgRVRTSSBFTiB0 byBwdXQgcHJvZHVjdHMgaW4gdGhlIEVVIG1hcmtldCB3aWxsIGhhdmUgdG8gaW1wbGVtZW50IGl0 LiBTZWNvbmRseSwgT2Zjb20gd2lsbCBtb3N0IGxpa2VseSByZXF1aXJlIFdTIGRhdGFiYXNlcyBh bmQgZGV2aWNlcyB0byBzdXBwb3J0IHRoZSBwYXJhbWV0ZXIgd2hlbiB3ZSBzZXQgdXAgdGhlIGxp Y2VuY2UgZXhlbXB0aW9uIHJlZ2ltZSBuZXh0IHllYXIuDQpUaGlzIGRvZXNu4oCZdCBtZWFuIGl0 IG11c3QgYmUgc3VwcG9ydGVkIGluIFBBV1MgcmlnaHQgbm93LiBEYXRhYmFzZSBwcm92aWRlcnMg YW5kIGRldmljZSBtYW51ZmFjdHVyZXJzIHVzaW5nIFBBV1MgY291bGQgaW1wbGVtZW50IGl0IGFz IGEgcHJvcHJpZXRhcnkgYWRkZW5kdW0uIEhvd2V2ZXIsIGl0IHdvdWxkIG1ha2UgYSBsb3Qgb2Yg c2Vuc2UgdG8gaW5jbHVkZSBpdCBpbiBQQVdTIGF0IHRoaXMgc3RhZ2UgaW4gbXkgdmlldy4NCkl0 IHdvdWxkIGJlIHByZWZlcmFibGUgdGhhdCB0aGUgUEFXUyBzcGVjaWZpY2F0aW9uIHN1cHBvcnQg YWxsIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgYnkgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUg RVRTSSBFTi4gVGhpcyB2ZXJzaW9uIG9mIHRoZSBFVFNJIEVOIGlzIG5vdyBhdCB0aGUgc3RhZ2Ug b2YgYSB2b3RlIGJ5IG5hdGlvbmFsIHN0YW5kYXJkIG9yZ2FuaXNhdGlvbnMsIGFuZCBpdCBpcyB2 ZXJ5IHZlcnkgdW5saWtlbHkgdG8gY2hhbmdlLiBBZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgY2Fu bm90IGJlIGluY29ycG9yYXRlZCBub3cg4oCTIGFuIG5ldyB3b3JrIGl0ZW0gbmVlZHMgdG8gYmUg c3RhcnRlZCBpbiBFVFNJIGZvciB0aGlzLCBhbmQgaXQgd2lsbCB0YWtlIG1vcmUgdGhhbiBhIHll YXIgdG8gZ2V0IHRvIGEgc3RhYmxlIGRyYWZ0IGFueXdheS4gSXQgaXMgdGhlcmVmb3JlIGEgZ29v ZCBwb2ludCBpbiB0aW1lIHRvIGFsaWduIGJvdGggZG9jdW1lbnRzLg0KSW4gc3VtbWFyeSwgcmVn dWxhdG9yeS13aXNlIGl0IGlzIG5vdCBhbiBhYnNvbHV0ZSBtdXN0LCBidXQgaXQgd2lsbCBiZSBo aWdobHkgYWR2aXNhYmxlLg0KUmVnYXJkcywNCkNlc2FyDQoNCkZyb206IEx1emFuZ28gTWZ1cGUg W21haWx0bzpMTWZ1cGVAY3Npci5jby56YTxtYWlsdG86TE1mdXBlQGNzaXIuY28uemE+XQ0KU2Vu dDogMDQgTWFyY2ggMjAxNCAwNjo1OA0KVG86IEdhYm9yIEJhamtvOyBCcmlhbiBSb3NlbjsgQ2Vz YXIgR3V0aWVycmV6DQpDYzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCg0K U3ViamVjdDogUmU6IFtwYXdzXSBSZXZpc2VkIEVUU0kgc3RhbmRhcmQNCg0KSGkgQ2VzYXIsDQoN CldoYXQgd2lsbCBiZSB0aGUgaW1wbGljYXRpb25zIHJlZ3VsYXRvcnktd2lzZSBvZiBub3QgaW5j bHVkaW5nIHRoaXMgbmV3IEVUU0kgcmVxdWlyZW1lbnQgaW4gUEFXUyB2ZXJzaW9uIDE/LCBpcyB0 aGlzIG5vdCBhbiBvcHRpb25hbCByZXF1aXJlbWVudD8NClJlZ2FyZHMNCkx1emFuZ28uDQoNCj4+ PiBDZXNhciBHdXRpZXJyZXogPENlc2FyLkd1dGllcnJlekBvZmNvbS5vcmcudWs8bWFpbHRvOkNl c2FyLkd1dGllcnJlekBvZmNvbS5vcmcudWs+PiAwMy8wMy8yMDE0IDE5OjAwID4+Pg0KR2Fib3Is IEJyaWFuLA0KDQpJIHRoaW5rIHRoYXQgd2hhdCB3ZSB3b3VsZCBiZSBsb29raW5nIGZvciBpcyBh IG5ldyBwYXJhbWV0ZXIgYWRkZWQgdG8gdGhlIFNwZWN0cnVtU3BlYyBlbGVtZW50Lg0KDQpJIHN1 Z2dlc3QgdGhlIGZvbGxvd2luZzoNCg0KUGFyYW1ldGVyIG5hbWU6IGV0c2lFblNpbXVsdGFuZW91 c0NoYW5uZWxPcGVyYXRpb25SZXN0cmljdGlvbg0KUGFyYW1ldGVyIHVzYWdlIGxvY2F0aW9uOiBT cGVjdHJ1bVNwZWMgKFNlY3Rpb24gNS45KQ0KU3BlY2lmaWNhdGlvbiBkb2N1bWVudDogU3BlY2lm aWVzIHRoZSBjb25zdHJhaW50IG9uIHRoZSBkZXZpY2UgbWF4aW11bSB0b3RhbCBFSVJQLCBhcyBk ZWZpbmVkIGJ5IHRoZSBFVFNJIEhhcm1vbmlzZWQgU3RhbmRhcmQgIFtFVFNJLUVOLTMwMS01OThd LiAgVGhlIHZhbHVlcyBhcmUgcmVwcmVzZW50ZWQgYnkgbnVtZXJpYyBzdHJpbmdzLCAgc3VjaCBh cyAiMCIsICIxIiwgZXRjLiAgQ29uc3VsdCB0aGUgZG9jdW1lbnRhdGlvbiBmb3IgdGhlIHNwZWNp ZmljYXRpb24gb2YgdGhlIHBvd2VyIGNvbnN0cmFpbiBjb3JyZXNwb25kaW5nIHRvIGVhY2ggcGFy YW1ldGVyIHZhbHVlLg0KDQoNCkl0IHdvdWxkIGJlIGdyZWF0IGlmIHdlIGNvdWxkIGNvbnNpZGVy IHRoaXMgYXQgdGhlIFdHIG1lZXRpbmcgdG9tb3Jyb3cuDQoNClRoYW5rcyBhbmQgcmVnYXJkcywN CkNlc2FyDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvc2VuLCBCcmlh biBbbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XQ0KU2VudDogMjcgRmVicnVhcnkgMjAx NCAxNTo1MQ0KVG86IEdhYm9yIEJhamtvDQpDYzogQ2VzYXIgR3V0aWVycmV6OyBwYXdzQGlldGYu b3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwYXdzXSBSZXZpc2VkIEVU U0kgc3RhbmRhcmQNCg0KQ2FuIGRvLiAgV2UnbGwgY292ZXIgdGhpcyBhdCB0aGUgZW5kIG9mIHRo ZSAtcHJvdG9jb2wgZGlzY3Vzc2lvbi4NCg0KQnJpYW4NCg0KT24gRmViIDI2LCAyMDE0LCBhdCA2 OjIyIFBNLCBHYWJvciBCYWprbyA8Z2Fib3JiYWprb0BnbWFpbC5jb208bWFpbHRvOmdhYm9yYmFq a29AZ21haWwuY29tPj4gd3JvdGU6DQoNCj4gVGhlIG5lZWQgZm9yIHRoaXMgcmVxdWlyZW1lbnQg c2hvdWxkIGJlIGRpc2N1c3NlZCBvbiB0aGUgbGlzdDsgYW5kIGlmDQo+IGFncmVlZCwgaXQgY2Fu IGJlIGluY29ycG9yYXRlZCBieSB0aGUgZWRpdG9yIGludG8gYSBmdXR1cmUgZHJhZnQNCj4gdmVy c2lvbi4NCj4gSSB3b24ndCBiZSB0aGVyZSBpbiBMb25kb24sIGJ1dCBwZXJoYXBzLCBpZiB5b3Ug b3Igc29tZW9uZSBlbHNlIGNvdWxkDQo+IHByb3Bvc2UgdGV4dCB0aGlzIHdlZWssIEJyaWFuIGNv dWxkIGFkZCBpdCB0byBuZXh0IHdlZWsncyBhZ2VuZGEuDQo+DQo+IC0gR2Fib3INCj4NCj4gT24g V2VkLCBGZWIgMjYsIDIwMTQgYXQgMTA6MTIgQU0sIENlc2FyIEd1dGllcnJleg0KPiA8Q2VzYXIu R3V0aWVycmV6QG9mY29tLm9yZy51azxtYWlsdG86Q2VzYXIuR3V0aWVycmV6QG9mY29tLm9yZy51 az4+IHdyb3RlOg0KPj4gRGVhciBhbGwsDQo+Pg0KPj4NCj4+DQo+PiBUaGVyZSBpcyBhIG5ldyB2 ZXJzaW9uIGF2YWlsYWJsZSBvZiBFVFNJIEVOIDMwMSA1OTggKHRoaXMgaXMgdGhlDQo+PiBzdGFu ZGFyZCB0aGF0IGxheXMgb3V0IHRoZSByZXF1aXJlbWVudHMgZm9yIG9wZXJhdGlvbiBpbiBFdXJv cGUpLg0KPj4gTW9zdCBvZiB0aGUgY2hhbmdlcyByZWxhdGUgdG8gUkYgcmVxdWlyZW1lbnRzLCBi dXQgdGhlcmUgaXMgYWxzbyBhbg0KPj4gYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBlbGVtZW50IHRo YXQgdGhlIGRhdGFiYXNlIHdpbGwgaGF2ZSB0byBjb21tdW5pY2F0ZSB0byB0aGUgTWFzdGVyIGRl dmljZS4NCj4+IFRoaXMgZWxlbWVudCBpbmRpY2F0ZXMgd2hldGhlciBzaW11bHRhbmVvdXMgdHJh bnNtaXNzaW9uIG92ZXINCj4+IG11bHRpcGxlIGNoYW5uZWxzIG11c3QgYmUgcmVzdHJpY3RlZCBp biBwb3dlciwgYW5kIGl0IGNhbiB0YWtlIHRoZSB2YWx1ZXMgb2YgMCBhbmQgMS4NCj4+DQo+Pg0K Pj4NCj4+IEVOIDMwMSA1OTggdjEuMC45IGNhbiBiZSBmb3VuZCBoZXJlOg0KPj4NCj4+IGh0dHA6 Ly93d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAw LjA5XzMwLw0KPj4gZW5fMzAxNTk4djAxMDAwOXYucGRmDQo+Pg0KPj4gYW5kIHRoZSBhZGRpdGlv biBJIGFtIHJlZmVycmluZyB0byBpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjIuMy40DQo+PiBh bmQgaW4gdGFibGUgNC4NCj4+DQo+Pg0KPj4NCj4+IElzIGl0IHN0aWxsIHBvc3NpYmxlIHRvIGlu Y29ycG9yYXRlIHRoaXMgbmV3IGluZm9ybWF0aW9uIGVsZW1lbnQgdG8NCj4+IHRoZSBQQVdTIHNw ZWNpZmljYXRpb24/DQo+Pg0KPj4NCj4+DQo+PiBUaGFua3MgYW5kIHJlZ2FyZHMsDQo+Pg0KPj4g Q2VzYXINCj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4NCj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KPj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+PiBGb3IgbW9yZSBpbmZvcm1hdGlvbiB2aXNpdCB3d3cub2Zjb20u b3JnLnVrPGh0dHA6Ly93d3cub2Zjb20ub3JnLnVrPg0KPj4NCj4+IFRoaXMgZW1haWwgKGFuZCBh bnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZQ0KPj4g dXNlIG9mIHRoZSBhZGRyZXNzZWUgb25seS4NCj4+DQo+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3INCj4+IG9mIHRo ZSBtZXNzYWdlIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCj4+DQo+PiBUaGlzIGVt YWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMuIEhvd2V2ZXIsIHlvdSBvcGVuIGFueQ0K Pj4gYXR0YWNobWVudHMgYXQgeW91ciBvd24gcmlzay4NCj4+DQo+PiBBbnkgdmlld3MgZXhwcmVz c2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCj4+IHNlbmRl ciBhbmQgZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5s ZXNzDQo+PiBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS4NCj4+ICoqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPj4g KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFp bGluZyBsaXN0DQo+PiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwYXdzIG1haWxpbmcg bGlzdA0KPiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioNCkZvciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5v cmcudWs8aHR0cDovL3d3dy5vZmNvbS5vcmcudWs+DQoNClRoaXMgZW1haWwgKGFuZCBhbnkgYXR0 YWNobWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhl IGFkZHJlc3NlZSBvbmx5Lg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UgYW5kIGRlbGV0 ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KDQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMuIEhvd2V2ZXIsIHlvdSBvcGVuIGFueSBhdHRhY2htZW50cyBhdCB5b3VyIG93biBy aXNrLg0KDQpBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2Yg dGhlIGluZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgcmVwcmVzZW50IHRoZSB2aWV3cyBvciBv cGluaW9ucyBvZiBPZmNvbSB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBvdGhlcndpc2UuDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0K LS0NClRoaXMgbWVzc2FnZSBpcyBzdWJqZWN0IHRvIHRoZSBDU0lSJ3MgY29weXJpZ2h0IHRlcm1z IGFuZCBjb25kaXRpb25zLCBlLW1haWwgbGVnYWwgbm90aWNlLCBhbmQgaW1wbGVtZW50ZWQgT3Bl biBEb2N1bWVudCBGb3JtYXQgKE9ERikgc3RhbmRhcmQuDQpUaGUgZnVsbCBkaXNjbGFpbWVyIGRl dGFpbHMgY2FuIGJlIGZvdW5kIGF0IGh0dHA6Ly93d3cuY3Npci5jby56YS9kaXNjbGFpbWVyLmh0 bWwuDQoNClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBkYW5n ZXJvdXMgY29udGVudCBieSBNYWlsU2Nhbm5lcjxodHRwOi8vd3d3Lm1haWxzY2FubmVyLmluZm8v PiwNCmFuZCBpcyBiZWxpZXZlZCB0byBiZSBjbGVhbi4NCg0KUGxlYXNlIGNvbnNpZGVyIHRoZSBl bnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcgdGhpcyBlbWFpbC4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiB2aXNpdCB3d3cub2Zj b20ub3JnLnVrPGh0dHA6Ly93d3cub2Zjb20ub3JnLnVrPg0KDQpUaGlzIGVtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgdXNlIG9m IHRoZSBhZGRyZXNzZWUgb25seS4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlIGFuZCBk ZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS4NCg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzLiBIb3dldmVyLCB5b3Ugb3BlbiBhbnkgYXR0YWNobWVudHMgYXQgeW91ciBv d24gcmlzay4NCg0KQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mg b3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5sZXNzIGV4cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLg0K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdz IG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoNCg0KLS0NCi12aW5jZQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCkZvciBtb3JlIGluZm9ybWF0 aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWsNCg0KVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRhY2ht ZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIHVzZSBvZiB0aGUgYWRk cmVzc2VlIG9ubHkuDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0 IGZyb20geW91ciBzeXN0ZW0uDQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2su DQoNCkFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5p b25zIG9mIE9mY29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS4NCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K --_000_5D3E853BEE49C848BB63047C794C8655B3CE9E1BWOKINTRAEXC02in_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hfQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hfQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkifQ0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiJ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCnANCgl7 bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYifQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYifQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYifQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYifQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzVFMjQzQ30NCi5Nc29DaHBEZWZhdWx0DQoJe2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYifQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe21hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHR9DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtfQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY219DQotLT4NCjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPlZpbmNlLDwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5JIHJlY29nbmlzZSB0aGF0IHRo ZSBFVFNJIHN0YW5kYXJkIGlzIG5vdCB2ZXJ5IGNsZWFyIG9uIHRoaXMgYW5kIHBlb3BsZSBtYXkg ZW5kIHVwIHdpdGggZGlmZmVyZW50IGludGVycHJldGF0aW9ucy4gVGhlIGludGVudGlvbiBpcyB0 aGF0IGRldmljZXMgbXVzdCBzdXBwb3J0DQogdGhhdCBwYXJhbWV0ZXIuIEhvd2V2ZXIsIGlmIHRo ZSBkYXRhYmFzZSBkb2VzIG5vdCBzZW5kIGl0IHRoZW4gdGhlIGRldmljZSBtdXN0IHJlYWN0IGFz IGlmIHRoZSBkZWZhdWx0IHZhbHVlIGhhZCBiZWVuIHByb3ZpZGVkLjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQz QyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5UaGUgcmF0aW9uYWxlIGlzIHRoYXQgdGhlIHBv d2VyIGNvbnN0cmFpbnQgaW5kaWNhdGVkIGJ5IGEgdmFsdWUgb2YgMSB3aWxsIG9ubHkgYmUgYWN0 aXZhdGVkIGluIHNwZWNpYWwgb2NjYXNpb25zLCBmb3IgaW5zdGFuY2Ugd2hlbiB0aGVyZSBpcyBh IGhpZ2ggY29uY2VudHJhdGlvbg0KIG9mIGRldmljZXMuIFRoZSByZXN0IG9mIHRoZSB0aW1lIHRo ZSB2YWx1ZSB3b3VsZCBiZSBlaXRoZXIgMCBvciBub3QgY29tbXVuaWNhdGVkLg0KPC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjojNUUyNDNDIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPlRoZSBFVFNJIHN0YW5kYXJkICZu YnNwO2RlYWxzIHdpdGggZGV2aWNlIHJlcXVpcmVtZW50cyBvbmx5LCBhbmQgZG9lcyB0d28gdGhp bmdzIGluIG15IHZpZXc6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiM1RTI0M0MiPjxzcGFuIHN0eWxlPSIiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5pdCBy ZXF1aXJlcyB0aGF0IGRldmljZXMgc3VwcG9ydCB0aGUgcGFyYW1ldGVyLCBhbmQ8L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+PHNwYW4gc3R5bGU9 IiI+Mik8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPml0IHNwZWNpZmllcyB0aGUgYmVoYXZpb3VyIG9m IHRoZSBkZXZpY2UgaW4gYm90aCBzY2VuYXJpb3M6IDEpIHRoZSBwYXJhbWV0ZXIgaXMgcHJvdmlk ZWQgYW5kIDIpIHRoZSBwYXJhbWV0ZXIgaXMgbm90IHByb3ZpZGVkIChqdXN0IGluIGNhc2UpLjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgY29sb3I6IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5JIGFtIG5vdCBzdXJl IHdoZXRoZXIgdGhpcyBtYWtlcyB0aGUgcGFyYW1ldGVyIG9wdGlvbmFsIGZyb20gdGhlIHBlcnNw ZWN0aXZlIG9mIFBBV1MuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0 M0MiPlJlZ2FyZHMsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5DZXNhcjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+ Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmluY2VudCBDaGVuIFttYWlsdG86dmNoZW5A Z29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNCBNYXJjaCAyMDE0IDE4OjEwPGJyPg0K PGI+VG86PC9iPiBDZXNhciBHdXRpZXJyZXo8YnI+DQo8Yj5DYzo8L2I+IEx1emFuZ28gTWZ1cGU7 IEdhYm9yIEJhamtvOyBCcmlhbiBSb3NlbjsgcGF3c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3Bhd3NdIFJldmlzZWQgRVRTSSBzdGFuZGFyZDwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2Vz YXIsPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tpbmcgYXQgdGhlIEVUU0kgRU4gMzAxIDU5 OCB2MS4wLjkgZG9jLCBpdCBsb29rcyBsaWtlIHRoaXMgcGFyYW1ldGVyIGlzIG9wdGlvbmFsOjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBXaXRoaW4gVGFibGUgNDogJm5i c3A7JnF1b3Q7VGhlIGRlZmF1bHQgdmFsdWUgaXMgMCZxdW90OzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBOb3RlIDI6ICZxdW90O0lmIHRoZSBzaW11bHRh bmVvdXMgY2hhbm5lbCBvcGVyYXRpb24gcG93ZXIgcmVzdHJpY3Rpb24gcGFyYW1ldGVyIGlzIG5v dCBwcm92aWRlZCwgLi4uJnF1b3Q7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g SSB3b3VsZCBsaXN0IHRoaXMgYXMgYW4gT1BUSU9OQUwgcGFyYW1ldGVyIGluIHNlY3Rpb24gOS4y LjIuMiAodGhlIElBTkEgc2VjdGlvbiBmb3IgRVRTSSBzcGVjaWZpY3MpLjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhhdCBzb3VuZCByaWdodD88L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LXZpbmNlPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA0LCAyMDE0IGF0IDI6NTkgQU0sIENlc2Fy IEd1dGllcnJleiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkNlc2FyLkd1dGllcnJlekBvZmNvbS5vcmcu dWsiIHRhcmdldD0iX2JsYW5rIj5DZXNhci5HdXRpZXJyZXpAb2Zjb20ub3JnLnVrPC9hPiZndDsg d3JvdGU6PC9wPg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6My4wcHQ7IG1hcmdpbi10b3A6My4w cHQ7IG1hcmdpbi1yaWdodDozLjBwdDsgbWFyZ2luLWJvdHRvbTouNzVwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiM1RTI0M0MiPkx1emFuZ28sPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5TdXBwb3J0 IGZvciB0aGlzIHBhcmFtZXRlciBpcyBtYW5kYXRvcnkgaW4gRVRTSSBFTiAzMDEgNTk4LiBBIGRl dmljZSBtYW51ZmFjdHVyZXIgdGhhdCBjaG9vc2VzIHRoZSByb3V0ZSBvZiBjb21wbGlhbmNlIHdp dGggdGhlIEVUU0kgRU4gdG8gcHV0IHByb2R1Y3RzDQogaW4gdGhlIEVVIG1hcmtldCB3aWxsIGhh dmUgdG8gaW1wbGVtZW50IGl0LiBTZWNvbmRseSwgT2Zjb20gd2lsbCBtb3N0IGxpa2VseSByZXF1 aXJlIFdTIGRhdGFiYXNlcyBhbmQgZGV2aWNlcyB0byBzdXBwb3J0IHRoZSBwYXJhbWV0ZXIgd2hl biB3ZSBzZXQgdXAgdGhlIGxpY2VuY2UgZXhlbXB0aW9uIHJlZ2ltZSBuZXh0IHllYXIuPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5UaGlzIGRvZXNu4oCZdCBtZWFuIGl0IG11c3QgYmUgc3Vw cG9ydGVkIGluIFBBV1MgcmlnaHQgbm93LiBEYXRhYmFzZSBwcm92aWRlcnMgYW5kIGRldmljZSBt YW51ZmFjdHVyZXJzIHVzaW5nIFBBV1MgY291bGQgaW1wbGVtZW50IGl0IGFzIGEgcHJvcHJpZXRh cnkNCiBhZGRlbmR1bS4gSG93ZXZlciwgaXQgd291bGQgbWFrZSBhIGxvdCBvZiBzZW5zZSB0byBp bmNsdWRlIGl0IGluIFBBV1MgYXQgdGhpcyBzdGFnZSBpbiBteSB2aWV3Lg0KPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBjb2xvcjojNUUyNDNDIj5JdCB3b3VsZCBiZSBwcmVmZXJhYmxlIHRoYXQgdGhlIFBBV1Mgc3Bl Y2lmaWNhdGlvbiBzdXBwb3J0IGFsbCBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkIGJ5IHRoZSBjdXJy ZW50IHZlcnNpb24gb2YgdGhlIEVUU0kgRU4uIFRoaXMgdmVyc2lvbiBvZiB0aGUgRVRTSQ0KIEVO IGlzIG5vdyBhdCB0aGUgc3RhZ2Ugb2YgYSB2b3RlIGJ5IG5hdGlvbmFsIHN0YW5kYXJkIG9yZ2Fu aXNhdGlvbnMsIGFuZCBpdCBpcyB2ZXJ5IHZlcnkgdW5saWtlbHkgdG8gY2hhbmdlLiBBZGRpdGlv bmFsIGZ1bmN0aW9uYWxpdHkgY2Fubm90IGJlIGluY29ycG9yYXRlZCBub3cg4oCTIGFuIG5ldyB3 b3JrIGl0ZW0gbmVlZHMgdG8gYmUgc3RhcnRlZCBpbiBFVFNJIGZvciB0aGlzLCBhbmQgaXQgd2ls bCB0YWtlIG1vcmUgdGhhbiBhIHllYXIgdG8gZ2V0DQogdG8gYSBzdGFibGUgZHJhZnQgYW55d2F5 LiBJdCBpcyB0aGVyZWZvcmUgYSBnb29kIHBvaW50IGluIHRpbWUgdG8gYWxpZ24gYm90aCBkb2N1 bWVudHMuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5JbiBzdW1tYXJ5LCByZWd1bGF0b3J5 LXdpc2UgaXQgaXMgbm90IGFuIGFic29sdXRlIG11c3QsIGJ1dCBpdCB3aWxsIGJlIGhpZ2hseSBh ZHZpc2FibGUuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5SZWdhcmRzLDwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgY29sb3I6IzVFMjQzQyI+Q2VzYXI8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPiZuYnNw Ozwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDsgcGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEx1emFuZ28gTWZ1cGUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86TE1mdXBlQGNzaXIuY28u emEiIHRhcmdldD0iX2JsYW5rIj5MTWZ1cGVAY3Npci5jby56YTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gMDQgTWFyY2ggMjAxNCAwNjo1ODxicj4NCjxiPlRvOjwvYj4gR2Fib3IgQmFqa287IEJy aWFuIFJvc2VuOyBDZXNhciBHdXRpZXJyZXo8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwvYT48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtwYXdzXSBSZXZpc2VkIEVUU0kgc3RhbmRhcmQ8L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IiI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBDZXNhciw8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2hhdCB3aWxsIGJlIHRoZSBpbXBsaWNhdGlvbnMgcmVn dWxhdG9yeS13aXNlIG9mIG5vdCBpbmNsdWRpbmcgdGhpcyBuZXcgRVRTSSZuYnNwO3JlcXVpcmVt ZW50Jm5ic3A7aW4gUEFXUyB2ZXJzaW9uIDE/LCBpcyB0aGlzIG5vdCBhbiBvcHRpb25hbCByZXF1 aXJlbWVudD88L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZHM8L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+THV6YW5nby48YnI+DQo8YnI+DQomZ3Q7 Jmd0OyZndDsgQ2VzYXIgR3V0aWVycmV6ICZsdDs8YSBocmVmPSJtYWlsdG86Q2VzYXIuR3V0aWVy cmV6QG9mY29tLm9yZy51ayIgdGFyZ2V0PSJfYmxhbmsiPkNlc2FyLkd1dGllcnJlekBvZmNvbS5v cmcudWs8L2E+Jmd0OyAwMy8wMy8yMDE0IDE5OjAwICZndDsmZ3Q7Jmd0Ozxicj4NCkdhYm9yLCBC cmlhbiw8YnI+DQo8YnI+DQpJIHRoaW5rIHRoYXQgd2hhdCB3ZSB3b3VsZCBiZSBsb29raW5nIGZv ciBpcyBhIG5ldyBwYXJhbWV0ZXIgYWRkZWQgdG8gdGhlIFNwZWN0cnVtU3BlYyBlbGVtZW50Ljxi cj4NCjxicj4NCkkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nOjxicj4NCjxicj4NClBhcmFtZXRlciBu YW1lOiBldHNpRW5TaW11bHRhbmVvdXNDaGFubmVsT3BlcmF0aW9uUmVzdHJpY3Rpb248YnI+DQpQ YXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IFNwZWN0cnVtU3BlYyAoU2VjdGlvbiA1LjkpPGJyPg0K U3BlY2lmaWNhdGlvbiBkb2N1bWVudDogU3BlY2lmaWVzIHRoZSBjb25zdHJhaW50IG9uIHRoZSBk ZXZpY2UgbWF4aW11bSB0b3RhbCBFSVJQLCBhcyBkZWZpbmVkIGJ5IHRoZSBFVFNJIEhhcm1vbmlz ZWQgU3RhbmRhcmQmbmJzcDsgW0VUU0ktRU4tMzAxLTU5OF0uJm5ic3A7IFRoZSB2YWx1ZXMgYXJl IHJlcHJlc2VudGVkIGJ5IG51bWVyaWMgc3RyaW5ncywmbmJzcDsgc3VjaCBhcyAmcXVvdDswJnF1 b3Q7LCAmcXVvdDsxJnF1b3Q7LCBldGMuJm5ic3A7IENvbnN1bHQgdGhlIGRvY3VtZW50YXRpb24g Zm9yIHRoZSBzcGVjaWZpY2F0aW9uDQogb2YgdGhlIHBvd2VyIGNvbnN0cmFpbiBjb3JyZXNwb25k aW5nIHRvIGVhY2ggcGFyYW1ldGVyIHZhbHVlLjxicj4NCjxicj4NCjxicj4NCkl0IHdvdWxkIGJl IGdyZWF0IGlmIHdlIGNvdWxkIGNvbnNpZGVyIHRoaXMgYXQgdGhlIFdHIG1lZXRpbmcgdG9tb3Jy b3cuPGJyPg0KPGJyPg0KVGhhbmtzIGFuZCByZWdhcmRzLDxicj4NCkNlc2FyPGJyPg0KPGJyPg0K PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBSb3NlbiwgQnJpYW4g WzxhIGhyZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiIgdGFyZ2V0PSJfYmxhbmsi Pm1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpejwvYT5dPGJyPg0KU2VudDogMjcgRmVicnVh cnkgMjAxNCAxNTo1MTxicj4NClRvOiBHYWJvciBCYWprbzxicj4NCkNjOiBDZXNhciBHdXRpZXJy ZXo7IDxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0Bp ZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFJldmlzZWQgRVRTSSBzdGFuZGFy ZDxicj4NCjxicj4NCkNhbiBkby4mbmJzcDsgV2UnbGwgY292ZXIgdGhpcyBhdCB0aGUgZW5kIG9m IHRoZSAtcHJvdG9jb2wgZGlzY3Vzc2lvbi48YnI+DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCk9u IEZlYiAyNiwgMjAxNCwgYXQgNjoyMiBQTSwgR2Fib3IgQmFqa28gJmx0OzxhIGhyZWY9Im1haWx0 bzpnYWJvcmJhamtvQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdhYm9yYmFqa29AZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBUaGUgbmVlZCBmb3IgdGhpcyByZXF1 aXJlbWVudCBzaG91bGQgYmUgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0OyBhbmQgaWY8YnI+DQomZ3Q7 IGFncmVlZCwgaXQgY2FuIGJlIGluY29ycG9yYXRlZCBieSB0aGUgZWRpdG9yIGludG8gYSBmdXR1 cmUgZHJhZnQ8YnI+DQomZ3Q7IHZlcnNpb24uPGJyPg0KJmd0OyBJIHdvbid0IGJlIHRoZXJlIGlu IExvbmRvbiwgYnV0IHBlcmhhcHMsIGlmIHlvdSBvciBzb21lb25lIGVsc2UgY291bGQ8YnI+DQom Z3Q7IHByb3Bvc2UgdGV4dCB0aGlzIHdlZWssIEJyaWFuIGNvdWxkIGFkZCBpdCB0byBuZXh0IHdl ZWsncyBhZ2VuZGEuPGJyPg0KJmd0Ozxicj4NCiZndDsgLSBHYWJvcjxicj4NCiZndDs8YnI+DQom Z3Q7IE9uIFdlZCwgRmViIDI2LCAyMDE0IGF0IDEwOjEyIEFNLCBDZXNhciBHdXRpZXJyZXo8YnI+ DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Q2VzYXIuR3V0aWVycmV6QG9mY29tLm9yZy51ayIg dGFyZ2V0PSJfYmxhbmsiPkNlc2FyLkd1dGllcnJlekBvZmNvbS5vcmcudWs8L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0OyBEZWFyIGFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGVyZSBpcyBhIG5ldyB2ZXJzaW9uIGF2YWlsYWJs ZSBvZiBFVFNJIEVOIDMwMSA1OTggKHRoaXMgaXMgdGhlPGJyPg0KJmd0OyZndDsgc3RhbmRhcmQg dGhhdCBsYXlzIG91dCB0aGUgcmVxdWlyZW1lbnRzIGZvciBvcGVyYXRpb24gaW4gRXVyb3BlKS48 YnI+DQomZ3Q7Jmd0OyBNb3N0IG9mIHRoZSBjaGFuZ2VzIHJlbGF0ZSB0byBSRiByZXF1aXJlbWVu dHMsIGJ1dCB0aGVyZSBpcyBhbHNvIGFuPGJyPg0KJmd0OyZndDsgYWRkaXRpb25hbCBpbmZvcm1h dGlvbiBlbGVtZW50IHRoYXQgdGhlIGRhdGFiYXNlIHdpbGwgaGF2ZSB0byBjb21tdW5pY2F0ZSB0 byB0aGUgTWFzdGVyIGRldmljZS48YnI+DQomZ3Q7Jmd0OyBUaGlzIGVsZW1lbnQgaW5kaWNhdGVz IHdoZXRoZXIgc2ltdWx0YW5lb3VzIHRyYW5zbWlzc2lvbiBvdmVyPGJyPg0KJmd0OyZndDsgbXVs dGlwbGUgY2hhbm5lbHMgbXVzdCBiZSByZXN0cmljdGVkIGluIHBvd2VyLCBhbmQgaXQgY2FuIHRh a2UgdGhlIHZhbHVlcyBvZiAwIGFuZCAxLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEVOIDMwMSA1OTggdjEuMC45IGNhbiBiZSBmb3VuZCBo ZXJlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5ldHNp Lm9yZy9kZWxpdmVyL2V0c2lfZW4vMzAxNTAwXzMwMTU5OS8zMDE1OTgvMDEuMDAuMDlfMzAvIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV9lbi8zMDE1 MDBfMzAxNTk5LzMwMTU5OC8wMS4wMC4wOV8zMC88L2E+PGJyPg0KJmd0OyZndDsgZW5fMzAxNTk4 djAxMDAwOXYucGRmPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBhbmQgdGhlIGFkZGl0aW9u IEkgYW0gcmVmZXJyaW5nIHRvIGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDQuMi4zLjQ8YnI+DQom Z3Q7Jmd0OyBhbmQgaW4gdGFibGUgNC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJcyBpdCBzdGlsbCBwb3NzaWJsZSB0byBpbmNvcnBvcmF0 ZSB0aGlzIG5ldyBpbmZvcm1hdGlvbiBlbGVtZW50IHRvPGJyPg0KJmd0OyZndDsgdGhlIFBBV1Mg c3BlY2lmaWNhdGlvbj88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyBUaGFua3MgYW5kIHJlZ2FyZHMsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBDZXNhcjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCiZndDsmZ3Q7ICoq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCiZndDsmZ3Q7 IEZvciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IDxhIGhyZWY9Imh0dHA6Ly93d3cub2Zjb20ub3Jn LnVrIiB0YXJnZXQ9Il9ibGFuayI+d3d3Lm9mY29tLm9yZy51azwvYT48YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IFRoaXMgZW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVu dGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZTxicj4NCiZndDsmZ3Q7IHVzZSBvZiB0aGUgYWRkcmVz c2VlIG9ubHkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3I8YnI+DQom Z3Q7Jmd0OyBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9y IHZpcnVzZXMuIEhvd2V2ZXIsIHlvdSBvcGVuIGFueTxicj4NCiZndDsmZ3Q7IGF0dGFjaG1lbnRz IGF0IHlvdXIgb3duIHJpc2suPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWw8YnI+ DQomZ3Q7Jmd0OyBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5p b25zIG9mIE9mY29tIHVubGVzczxicj4NCiZndDsmZ3Q7IGV4cHJlc3NseSBzdGF0ZWQgb3RoZXJ3 aXNlLjxicj4NCiZndDsmZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCiZndDsmZ3Q7ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7Jmd0OyBwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQom Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3M8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgcGF3cyBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCkZvciBtb3JlIGlu Zm9ybWF0aW9uIHZpc2l0IDxhIGhyZWY9Imh0dHA6Ly93d3cub2Zjb20ub3JnLnVrIiB0YXJnZXQ9 Il9ibGFuayI+d3d3Lm9mY29tLm9yZy51azwvYT48YnI+DQo8YnI+DQpUaGlzIGVtYWlsIChhbmQg YW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgdXNl IG9mIHRoZSBhZGRyZXNzZWUgb25seS48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxicj4NCjxicj4NClRoaXMgZW1h aWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0 dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suPGJyPg0KPGJyPg0KQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQg ZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5sZXNzIGV4 cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KLS0gPGJy Pg0KVGhpcyBtZXNzYWdlIGlzIHN1YmplY3QgdG8gdGhlIENTSVIncyBjb3B5cmlnaHQgdGVybXMg YW5kIGNvbmRpdGlvbnMsIGUtbWFpbCBsZWdhbCBub3RpY2UsIGFuZCBpbXBsZW1lbnRlZCBPcGVu IERvY3VtZW50IEZvcm1hdCAoT0RGKSBzdGFuZGFyZC4NCjxicj4NClRoZSBmdWxsIGRpc2NsYWlt ZXIgZGV0YWlscyBjYW4gYmUgZm91bmQgYXQgPGEgaHJlZj0iaHR0cDovL3d3dy5jc2lyLmNvLnph L2Rpc2NsYWltZXIuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5jc2lyLmNvLnph L2Rpc2NsYWltZXIuaHRtbDwvYT4uIDwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBkYW5nZXJvdXMgY29udGVudCBieSA8YSBocmVmPSJodHRwOi8vd3d3Lm1haWxzY2FubmVy LmluZm8vIiB0YXJnZXQ9Il9ibGFuayI+DQo8Yj5NYWlsU2Nhbm5lcjwvYj48L2E+LCA8YnI+DQph bmQgaXMgYmVsaWV2ZWQgdG8gYmUgY2xlYW4uIDwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NClBsZWFzZSBjb25zaWRlciB0aGUgZW52aXJvbm1lbnQgYmVm b3JlIHByaW50aW5nIHRoaXMgZW1haWwuIDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXYg Y2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVy Ij4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpncmF5Ij48YnI+DQoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpGb3Ig bW9yZSBpbmZvcm1hdGlvbiB2aXNpdCA8YSBocmVmPSJodHRwOi8vd3d3Lm9mY29tLm9yZy51ayIg dGFyZ2V0PSJfYmxhbmsiPnd3dy5vZmNvbS5vcmcudWs8L2E+PGJyPg0KPGJyPg0KVGhpcyBlbWFp bCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3Ig dGhlIHVzZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuPGJyPg0KPGJyPg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS48YnI+DQo8YnI+DQpU aGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMuIEhvd2V2ZXIsIHlvdSBvcGVu IGFueSBhdHRhY2htZW50cyBhdCB5b3VyIG93biByaXNrLjxicj4NCjxicj4NCkFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5k ZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5pb25zIG9mIE9mY29tIHVu bGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS48YnI+DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnBhd3MgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnBhd3NA aWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g PGJyPg0KLXZpbmNlIDwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjIiPjxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCkZvciBtb3JlIGluZm9y bWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWs8YnI+DQo8YnI+DQpUaGlzIGVtYWlsIChhbmQg YW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgdXNl IG9mIHRoZSBhZGRyZXNzZWUgb25seS48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxicj4NCjxicj4NClRoaXMgZW1h aWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0 dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suPGJyPg0KPGJyPg0KQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQg ZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5sZXNzIGV4 cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_5D3E853BEE49C848BB63047C794C8655B3CE9E1BWOKINTRAEXC02in_-- From nobody Tue Mar 4 18:42:28 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C981A018D for ; Tue, 4 Mar 2014 18:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbEhicFTmKhb for ; Tue, 4 Mar 2014 18:42:22 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 86A1A1A0178 for ; Tue, 4 Mar 2014 18:42:22 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wn1so429276obc.16 for ; Tue, 04 Mar 2014 18:42:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a7Ysruq5cdG7yTEMCS3ysWlQZrz9PFObSoALEoRsgTg=; b=QByRZr+a2fU1+Iw3QjaKEsWnYZ42wFmwSXZxFK6YJCP9YnZX4Hjd7ekC+vEdwMz9wT mEuMJBP7a2M6yfXfNnNnghPozWzffNGtPTD+gJgHXe8UGmmqLQ3r6Z8FBORmpVk47yWY g3+tzPheU/pYSKFDDLXrUo79z6ayZdSJCExrAlw0o6tqkzrugB+e52m1skVsXn0HbTi3 My4sZXtimDdM8ZehaDtQ8ayJU1XQGRF5i2Crx+ifCzPgj3A3HgxxTFqK22kMaC4PZx6O cptpTQ6rFaUkxhW3WfkJJf3h9uWrmpYv45uJgAu2A8mIrZkbHuN56k866K3MkGCCRn2L HjMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a7Ysruq5cdG7yTEMCS3ysWlQZrz9PFObSoALEoRsgTg=; b=MJPQcDedsFrBBQuaADZdZaPRtlNCDut4vzRJNb8rI36FqWsXlAQ8X7PKNiDKzH/snq 5eZIyv0smqvYqLWwdKIeGkZ6pjuvt0ObUcXjfnRdpfkt/QSs/BxssAi+TtIAIK9kTDEi yztuEcypelwfxY03yG/ql6/2gkb4GNk3jyXym95Ty4VqXeoYvh6APbXnxUyjMS3h91bQ t8SkW/r9Kdj/aeTZHaRjmqZe7t0nmOeVdnM08NkkGQaZuUIpWts3EYTqf6oyQ3yNGgJ1 AHIlpO1mHhQsB56qA/NmTbc/ifoMzJCRZTB/Bg1YFzVnI4kh2yJs7OAbMmxKeXi8YKAZ BtLg== X-Gm-Message-State: ALoCoQnD6hAfg8LR4l10N103x1+tpCUrpqO+J+jeJa+fv3skxm13/dyKwHRJTufjgGOrW/TaCs/rAjS+AsbNgfUg9pPvMFW2qqsv7j3Uj7Q1DgAWkJwTwCwXyGgneybLVdXlFoqy2QTSL9bys52BKymBx06Vjrjdf/9HrcB8NQNPfntiH2bNl7mIrYBmo8co7us/wDP6k9lt MIME-Version: 1.0 X-Received: by 10.182.28.134 with SMTP id b6mr2407758obh.27.1393987338978; Tue, 04 Mar 2014 18:42:18 -0800 (PST) Received: by 10.182.45.166 with HTTP; Tue, 4 Mar 2014 18:42:18 -0800 (PST) In-Reply-To: <5D3E853BEE49C848BB63047C794C8655B3CE9E1B@WOK-INTRA-EXC02.intra.ofcom.local> References: <531595A70200009E0008F0E1@pta-emo.csir.co.za> <5D3E853BEE49C848BB63047C794C8655B3CE98DD@WOK-INTRA-EXC02.intra.ofcom.local> <5D3E853BEE49C848BB63047C794C8655B3CE9E1B@WOK-INTRA-EXC02.intra.ofcom.local> Date: Tue, 4 Mar 2014 18:42:18 -0800 Message-ID: From: Vincent Chen To: Cesar Gutierrez Content-Type: multipart/alternative; boundary=001a11c2903c295e9904f3d2f839 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/sHeOWY2rDlXk4MXpq1JZxI6ILq4 Cc: "paws@ietf.org" , Luzango Mfupe Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 02:42:27 -0000 --001a11c2903c295e9904f3d2f839 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Cesar, Here's the proposed language: etsiEnSimultaneousChannelOperationRestriction: Specifies a constraint on simultaneous channel operation. The Database MAY include this field within the SpectrumSpec (Section 5.9) parameter of the AVAIL_SPECTRUM_RESP (Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages. If it is not provided, the Device MUST assume the value of "0". If it is provided, the Device MUST NOT ignore it. I believe it captures the intent. -vince On Tue, Mar 4, 2014 at 10:56 AM, Cesar Gutierrez < Cesar.Gutierrez@ofcom.org.uk> wrote: > Vince, > > > > I recognise that the ETSI standard is not very clear on this and people > may end up with different interpretations. The intention is that devices > must support that parameter. However, if the database does not send it th= en > the device must react as if the default value had been provided. > > > > The rationale is that the power constraint indicated by a value of 1 will > only be activated in special occasions, for instance when there is a high > concentration of devices. The rest of the time the value would be either = 0 > or not communicated. > > > > The ETSI standard deals with device requirements only, and does two > things in my view: > > 1) it requires that devices support the parameter, and > > 2) it specifies the behaviour of the device in both scenarios: 1) the > parameter is provided and 2) the parameter is not provided (just in case)= . > > > > I am not sure whether this makes the parameter optional from the > perspective of PAWS. > > > > Regards, > > Cesar > > > > *From:* Vincent Chen [mailto:vchen@google.com] > *Sent:* 04 March 2014 18:10 > *To:* Cesar Gutierrez > *Cc:* Luzango Mfupe; Gabor Bajko; Brian Rosen; paws@ietf.org > > *Subject:* Re: [paws] Revised ETSI standard > > > > Cesar, > > > > Looking at the ETSI EN 301 598 v1.0.9 doc, it looks like this parameter i= s > optional: > > > > Within Table 4: "The default value is 0" > > Note 2: "If the simultaneous channel operation power restriction > parameter is not provided, ..." > > > > So I would list this as an OPTIONAL parameter in section 9.2.2.2 (the IAN= A > section for ETSI specifics). > > Does that sound right? > > > > Thanks. > > > > -vince > > > > On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez < > Cesar.Gutierrez@ofcom.org.uk> wrote: > > Luzango, > > Support for this parameter is mandatory in ETSI EN 301 598. A device > manufacturer that chooses the route of compliance with the ETSI EN to put > products in the EU market will have to implement it. Secondly, Ofcom will > most likely require WS databases and devices to support the parameter whe= n > we set up the licence exemption regime next year. > > This doesn=E2=80=99t mean it must be supported in PAWS right now. Databas= e > providers and device manufacturers using PAWS could implement it as a > proprietary addendum. However, it would make a lot of sense to include it > in PAWS at this stage in my view. > > It would be preferable that the PAWS specification support all > functionality required by the current version of the ETSI EN. This versio= n > of the ETSI EN is now at the stage of a vote by national standard > organisations, and it is very very unlikely to change. Additional > functionality cannot be incorporated now =E2=80=93 an new work item needs= to be > started in ETSI for this, and it will take more than a year to get to a > stable draft anyway. It is therefore a good point in time to align both > documents. > > In summary, regulatory-wise it is not an absolute must, but it will be > highly advisable. > > Regards, > > Cesar > > > > *From:* Luzango Mfupe [mailto:LMfupe@csir.co.za] > *Sent:* 04 March 2014 06:58 > *To:* Gabor Bajko; Brian Rosen; Cesar Gutierrez > *Cc:* paws@ietf.org > > > *Subject:* Re: [paws] Revised ETSI standard > > > > Hi Cesar, > > > > What will be the implications regulatory-wise of not including this new > ETSI requirement in PAWS version 1?, is this not an optional requirement? > > Regards > > Luzango. > > >>> Cesar Gutierrez 03/03/2014 19:00 >>> > Gabor, Brian, > > I think that what we would be looking for is a new parameter added to the > SpectrumSpec element. > > I suggest the following: > > Parameter name: etsiEnSimultaneousChannelOperationRestriction > Parameter usage location: SpectrumSpec (Section 5.9) > Specification document: Specifies the constraint on the device maximum > total EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]= . > The values are represented by numeric strings, such as "0", "1", etc. > Consult the documentation for the specification of the power constrain > corresponding to each parameter value. > > > It would be great if we could consider this at the WG meeting tomorrow. > > Thanks and regards, > Cesar > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz > ] > Sent: 27 February 2014 15:51 > To: Gabor Bajko > Cc: Cesar Gutierrez; paws@ietf.org > Subject: Re: [paws] Revised ETSI standard > > Can do. We'll cover this at the end of the -protocol discussion. > > Brian > > On Feb 26, 2014, at 6:22 PM, Gabor Bajko wrote: > > > The need for this requirement should be discussed on the list; and if > > agreed, it can be incorporated by the editor into a future draft > > version. > > I won't be there in London, but perhaps, if you or someone else could > > propose text this week, Brian could add it to next week's agenda. > > > > - Gabor > > > > On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez > > wrote: > >> Dear all, > >> > >> > >> > >> There is a new version available of ETSI EN 301 598 (this is the > >> standard that lays out the requirements for operation in Europe). > >> Most of the changes relate to RF requirements, but there is also an > >> additional information element that the database will have to > communicate to the Master device. > >> This element indicates whether simultaneous transmission over > >> multiple channels must be restricted in power, and it can take the > values of 0 and 1. > >> > >> > >> > >> EN 301 598 v1.0.9 can be found here: > >> > >> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ > >> en_301598v010009v.pdf > >> > >> and the addition I am referring to is described in section 4.2.3.4 > >> and in table 4. > >> > >> > >> > >> Is it still possible to incorporate this new information element to > >> the PAWS specification? > >> > >> > >> > >> Thanks and regards, > >> > >> Cesar > >> > >> > >> > >> > >> ________________________________ > >> > >> ********************************************************************* > >> ********************************************* > >> For more information visit www.ofcom.org.uk > >> > >> This email (and any attachments) is confidential and intended for the > >> use of the addressee only. > >> > >> If you have received this email in error please notify the originator > >> of the message and delete it from your system. > >> > >> This email has been scanned for viruses. However, you open any > >> attachments at your own risk. > >> > >> Any views expressed in this message are those of the individual > >> sender and do not represent the views or opinions of Ofcom unless > >> expressly stated otherwise. > >> ********************************************************************* > >> ********************************************* > >> > >> _______________________________________________ > >> 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 > > > ________________________________ > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > > > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > > This message has been scanned for viruses and dangerous content by > *MailScanner* , > and is believed to be clean. > > > Please consider the environment before printing this email. > > > ------------------------------ > > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > > -- > -vince > > ------------------------------ > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > --=20 -vince --001a11c2903c295e9904f3d2f839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Cesar,

Here's the proposed l= anguage:

=C2=A0 =C2=A0 =C2=A0=C2=A0etsiEnSimultaneousChannelOperationR= estriction:=C2=A0 Specifies a

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 constraint on simultaneous = channel operation.=C2=A0 The Database MAY

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 include this field within t= he SpectrumSpec (Section 5.9)

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 parameter of the AVAIL_SPEC= TRUM_RESP (Section 4.4.2) and

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 AVAIL_SPECTRUM_BATCH_RESP (= Section 4.4.4) messages.=C2=A0 If it is

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 not provided, the Device MU= ST assume the value of "0".=C2=A0 If it

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 is provided, the Device MUS= T NOT ignore it.


I believe it captur= es the intent.

-vince



On Tue, Mar 4, 2014 at 10:56 AM, Cesar Gutierrez <Cesar.Gutierr= ez@ofcom.org.uk> wrote:

Vince,

=C2=A0

I recognise that the ETSI s= tandard is not very clear on this and people may end up with different inte= rpretations. The intention is that devices must support that parameter. However, if the database does not send it then the device = must react as if the default value had been provided.

=C2=A0

The rationale is that the p= ower constraint indicated by a value of 1 will only be activated in special= occasions, for instance when there is a high concentration of devices. The rest of the time the value would be either 0 or not commun= icated.

=C2=A0

The ETSI standard =C2=A0dea= ls with device requirements only, and does two things in my view:

1)=C2=A0=C2=A0=C2=A0 it requires that devices supp= ort the parameter, and

2)=C2=A0=C2=A0=C2=A0 it specifies the behaviour of= the device in both scenarios: 1) the parameter is provided and 2) the para= meter is not provided (just in case).

=C2=A0

I am not sure whether this = makes the parameter optional from the perspective of PAWS.

=C2=A0

Regards,

Cesar

=C2=A0

From: Vincent Chen [mailto:vchen@google.com]
Sent: 04 March 2014 18:10
To: Cesar Gutierrez
Cc: Luzango Mfupe; Gabor Bajko; Brian Rosen; paws@ietf.org


Subject: Re: [paws] Revised ETSI standard

=C2=A0

Cesar,

=C2=A0

Looking at the ETSI EN 301 598 v1.0.9 doc, it looks = like this parameter is optional:

=C2=A0

=C2=A0 Within Table 4: =C2=A0"The default value= is 0"

=C2=A0 Note 2: "If the simultaneous channel ope= ration power restriction parameter is not provided, ..."

=C2=A0

So I would list this as an OPTIONAL parameter in sec= tion 9.2.2.2 (the IANA section for ETSI specifics).

Does that sound right?

=C2=A0

Thanks.

=C2=A0

-vince

=C2=A0

On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez <= Cesar.Gut= ierrez@ofcom.org.uk> wrote:

Luzango,

Support for this parameter = is mandatory in ETSI EN 301 598. A device manufacturer that chooses the rou= te of compliance with the ETSI EN to put products in the EU market will have to implement it. Secondly, Ofcom will most like= ly require WS databases and devices to support the parameter when we set up= the licence exemption regime next year.

This doesn=E2=80=99t mean i= t must be supported in PAWS right now. Database providers and device manufa= cturers using PAWS could implement it as a proprietary addendum. However, it would make a lot of sense to include it in PAWS at t= his stage in my view.

It would be preferable that= the PAWS specification support all functionality required by the current v= ersion of the ETSI EN. This version of the ETSI EN is now at the stage of a vote by national standard organisations, and i= t is very very unlikely to change. Additional functionality cannot be incor= porated now =E2=80=93 an new work item needs to be started in ETSI for this= , and it will take more than a year to get to a stable draft anyway. It is therefore a good point in time to align bo= th documents.

In summary, regulatory-wise= it is not an absolute must, but it will be highly advisable.

Regards,

Cesar

=C2=A0

From: Luzango Mfupe [mailto:LMfupe@csir.co.za]
Sent: 04 March 2014 06:58
To: Gabor Bajko; Brian Rosen; Cesar Gutierrez
Cc: paws@ietf.org=


Subject: Re: [paws] Revised ETSI standard

=C2=A0

Hi Cesar,

=C2=A0

What will be the implications regulato= ry-wise of not including this new ETSI=C2=A0requirement=C2=A0in PAWS versio= n 1?, is this not an optional requirement?

Regards

Luzango= .

>>> Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> 03/03/2014 19:= 00 >>>
Gabor, Brian,

I think that what we would be looking for is a new parameter added to the S= pectrumSpec element.

I suggest the following:

Parameter name: etsiEnSimultaneousChannelOperationRestriction
Parameter usage location: SpectrumSpec (Section 5.9)
Specification document: Specifies the constraint on the device maximum tota= l EIRP, as defined by the ETSI Harmonised Standard=C2=A0 [ETSI-EN-301-598].= =C2=A0 The values are represented by numeric strings,=C2=A0 such as "0= ", "1", etc.=C2=A0 Consult the documentation for the specifi= cation of the power constrain corresponding to each parameter value.


It would be great if we could consider this at the WG meeting tomorrow.

Thanks and regards,
Cesar


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: 27 February 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; paw= s@ietf.org
Subject: Re: [paws] Revised ETSI standard

Can do.=C2=A0 We'll cover this at the end of the -protocol discussion.<= br>
Brian

On Feb 26, 2014, at 6:22 PM, Gabor Bajko <gaborbajko@gmail.com> wrote:

> The need for this requirement should be discussed on the list; and if<= br> > agreed, it can be incorporated by the editor into a future draft
> version.
> I won't be there in London, but perhaps, if you or someone else co= uld
> propose text this week, Brian could add it to next week's agenda.<= br> >
> - Gabor
>
> On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez
> <= Cesar.Gutierrez@ofcom.org.uk> wrote:
>> Dear all,
>>
>>
>>
>> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe).<= br> >> Most of the changes relate to RF requirements, but there is also a= n
>> additional information element that the database will have to comm= unicate to the Master device.
>> This element indicates whether simultaneous transmission over
>> multiple channels must be restricted in power, and it can take the= values of 0 and 1.
>>
>>
>>
>> EN 301 598 v1.0.9 can be found here:
>>
>> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf
>>
>> and the addition I am referring to is described in section 4.2.3.4=
>> and in table 4.
>>
>>
>>
>> Is it still possible to incorporate this new information element t= o
>> the PAWS specification?
>>
>>
>>
>> Thanks and regards,
>>
>> Cesar
>>
>>
>>
>>
>> ________________________________
>>
>> ******************************************************************= ***
>> *********************************************
>> For more information visit www.ofcom.org.uk
>>
>> This email (and any attachments) is confidential and intended for = the
>> use of the addressee only.
>>
>> If you have received this email in error please notify the origina= tor
>> of the message and delete it from your system.
>>
>> This email has been scanned for viruses. However, you open any
>> attachments at your own risk.
>>
>> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless<= br> >> expressly stated otherwise.
>> ******************************************************************= ***
>> *********************************************
>>
>> _______________________________________________
>> 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


________________________________

***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************


--
This message is subject to the CSIR's copyright terms and conditions, e= -mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean.


Please consider the environment before printing this email.

=C2=A0


***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************


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



=C2=A0

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************



--
-vince --001a11c2903c295e9904f3d2f839-- From nobody Tue Mar 4 22:52:40 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B56E1A02C3 for ; Tue, 4 Mar 2014 22:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvLC56cHOMk9 for ; Tue, 4 Mar 2014 22:52:33 -0800 (PST) Received: from ls-mx3.csir.co.za (ls-mx3.csir.co.za [146.64.10.248]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4D21A02BF for ; Tue, 4 Mar 2014 22:52:28 -0800 (PST) Received: from pta-emo.csir.co.za (pta-emo.csir.co.za [146.64.100.109]) by ls-mx3.csir.co.za (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id s256pruu030223 for ; Wed, 5 Mar 2014 08:51:55 +0200 Received: from PTA-EMO-MTA by pta-emo.csir.co.za with Novell_GroupWise; Wed, 05 Mar 2014 08:51:37 +0200 Message-Id: <5316E5970200009E0008F2D0@pta-emo.csir.co.za> X-Mailer: Novell GroupWise Internet Agent 12.0.2 Date: Wed, 05 Mar 2014 08:51:35 +0200 From: "Luzango Mfupe" To: "Vincent Chen" , "Cesar Gutierrez" Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part83B1CB67.2__=" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (ls-mx3.csir.co.za [146.64.10.248]); Wed, 05 Mar 2014 08:51:55 +0200 (SAST) X-CSIR-MailScanner-Information: Please contact the ISP for more information X-CSIR-MailScanner-ID: s256pruu030223 X-CSIR-MailScanner: Found to be clean X-CSIR-MailScanner-From: lmfupe@csir.co.za X-CSIR-MailScanner-Watermark: 1394607116.52279@WwRHbIg+xWvUHDu0nImrYw Archived-At: http://mailarchive.ietf.org/arch/msg/paws/FLzTmxkIfvZXkswguWxufMhk6es Cc: "paws@ietf.org" Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 06:52:39 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part83B1CB67.2__= Content-Type: multipart/alternative; boundary="=__Part83B1CB67.3__=" --=__Part83B1CB67.3__= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Vince, Ceser, I think Vince's proposed wording in Sects 4.4.2, 4.4.4, & 5.2 sufficiently aligns with the current ETSI draft until we get their stable version. -Luzango. >>> Vincent Chen 05/03/2014 04:42 >>> Thanks Cesar, Here's the proposed language: etsiEnSimultaneousChannelOperationRestriction: Specifies a constraint on simultaneous channel operation. The Database MAY include this field within the SpectrumSpec (Section 5.9) parameter of the AVAIL_SPECTRUM_RESP (Section 4.4.2) and AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages. If it is not provided, the Device MUST assume the value of "0". If it is provided, the Device MUST NOT ignore it. I believe it captures the intent. -vince On Tue, Mar 4, 2014 at 10:56 AM, Cesar Gutierrez wrote: Vince, I recognise that the ETSI standard is not very clear on this and people may end up with different interpretations. The intention is that devices must support that parameter. However, if the database does not send it then the device must react as if the default value had been provided. The rationale is that the power constraint indicated by a value of 1 will only be activated in special occasions, for instance when there is a high concentration of devices. The rest of the time the value would be either 0 or not communicated. The ETSI standard deals with device requirements only, and does two things in my view: 1) it requires that devices support the parameter, and 2) it specifies the behaviour of the device in both scenarios: 1) the parameter is provided and 2) the parameter is not provided (just in case). I am not sure whether this makes the parameter optional from the perspective of PAWS. Regards, Cesar From: Vincent Chen [mailto:vchen@google.com] Sent: 04 March 2014 18:10 To: Cesar Gutierrez Cc: Luzango Mfupe; Gabor Bajko; Brian Rosen; paws@ietf.org Subject: Re: [paws] Revised ETSI standard Cesar, Looking at the ETSI EN 301 598 v1.0.9 doc, it looks like this parameter is optional: Within Table 4: "The default value is 0" Note 2: "If the simultaneous channel operation power restriction parameter is not provided, ..." So I would list this as an OPTIONAL parameter in section 9.2.2.2 (the IANA section for ETSI specifics). Does that sound right? Thanks. -vince On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez wrote: Luzango, Support for this parameter is mandatory in ETSI EN 301 598. A device manufacturer that chooses the route of compliance with the ETSI EN to put products in the EU market will have to implement it. Secondly, Ofcom will most likely require WS databases and devices to support the parameter when we set up the licence exemption regime next year. This doesn’t mean it must be supported in PAWS right now. Database providers and device manufacturers using PAWS could implement it as a proprietary addendum. However, it would make a lot of sense to include it in PAWS at this stage in my view. It would be preferable that the PAWS specification support all functionality required by the current version of the ETSI EN. This version of the ETSI EN is now at the stage of a vote by national standard organisations, and it is very very unlikely to change. Additional functionality cannot be incorporated now – an new work item needs to be started in ETSI for this, and it will take more than a year to get to a stable draft anyway. It is therefore a good point in time to align both documents. In summary, regulatory-wise it is not an absolute must, but it will be highly advisable. Regards, Cesar From: Luzango Mfupe [mailto:LMfupe@csir.co.za] Sent: 04 March 2014 06:58 To: Gabor Bajko; Brian Rosen; Cesar Gutierrez Cc: paws@ietf.org Subject: Re: [paws] Revised ETSI standard Hi Cesar, What will be the implications regulatory-wise of not including this new ETSI requirement in PAWS version 1?, is this not an optional requirement? Regards Luzango. >>> Cesar Gutierrez 03/03/2014 19:00 >>> Gabor, Brian, I think that what we would be looking for is a new parameter added to the SpectrumSpec element. I suggest the following: Parameter name: etsiEnSimultaneousChannelOperationRestriction Parameter usage location: SpectrumSpec (Section 5.9) Specification document: Specifies the constraint on the device maximum total EIRP, as defined by the ETSI Harmonised Standard [ETSI-EN-301-598]. The values are represented by numeric strings, such as "0", "1", etc. Consult the documentation for the specification of the power constrain corresponding to each parameter value. It would be great if we could consider this at the WG meeting tomorrow. Thanks and regards, Cesar -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: 27 February 2014 15:51 To: Gabor Bajko Cc: Cesar Gutierrez; paws@ietf.org Subject: Re: [paws] Revised ETSI standard Can do. We'll cover this at the end of the -protocol discussion. Brian On Feb 26, 2014, at 6:22 PM, Gabor Bajko wrote: > The need for this requirement should be discussed on the list; and if > agreed, it can be incorporated by the editor into a future draft > version. > I won't be there in London, but perhaps, if you or someone else could > propose text this week, Brian could add it to next week's agenda. > > - Gabor > > On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez > wrote: >> Dear all, >> >> >> >> There is a new version available of ETSI EN 301 598 (this is the >> standard that lays out the requirements for operation in Europe). >> Most of the changes relate to RF requirements, but there is also an >> additional information element that the database will have to communicate to the Master device. >> This element indicates whether simultaneous transmission over >> multiple channels must be restricted in power, and it can take the values of 0 and 1. >> >> >> >> EN 301 598 v1.0.9 can be found here: >> >> http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/ >> en_301598v010009v.pdf >> >> and the addition I am referring to is described in section 4.2.3.4 >> and in table 4. >> >> >> >> Is it still possible to incorporate this new information element to >> the PAWS specification? >> >> >> >> Thanks and regards, >> >> Cesar >> >> >> >> >> ________________________________ >> >> ********************************************************************* >> ********************************************* >> For more information visit www.ofcom.org.uk >> >> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >> If you have received this email in error please notify the originator >> of the message and delete it from your system. >> >> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless >> expressly stated otherwise. >> ********************************************************************* >> ********************************************* >> >> _______________________________________________ >> 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 ________________________________ ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ****************************************************************************************************************** -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner ( http://www.mailscanner.info/) , and is believed to be clean. Please consider the environment before printing this email. ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ****************************************************************************************************************** _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ****************************************************************************************************************** -- -vince -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Please consider the environment before printing this email. --=__Part83B1CB67.3__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML
Vince, Ceser,
I think Vince's proposed wording in Sects 4.4.2, 4.4.4,= & 5.2 sufficiently aligns with the current ETSI draft until we ge= t their stable version.
-Luzango. 

>>> Vincent Chen <vchen@google.com&= gt; 05/03/2014 04:42 >>>
Thanks Cesar,

Here's the proposed language:

etsiEnSimultaneousChannelOperationRestriction: Specifies a

constraint on simultaneous channel operation. The Database MAY

include this field within the SpectrumSpec (Section 5.9)

parameter of the AVAIL_SPECTRUM_RESP (Section 4.4.2) and

AVAIL_SPECTRUM_BATCH_RESP (Section 4.4.4) messages. If it is

not provided, the Device MUST assume the value of "0". If it

is provided, the Device MUST NOT ignore it.


I believe it captures the intent.

-vince



On Tue, Mar 4, 2014 at 10:56 AM, Cesar Gutierrez <= SPAN dir=3Dltr><Cesar.Gutierrez@ofcom.org.uk> wrote:

Vince,

I recognise that the ETSI standard is not very= clear on this and people may end up with different interpretations. The in= tention is that devices must support that parameter. However, if the databa= se does not send it then the device must react as if the default value had = been provided.

The rationale is that the power constraint ind= icated by a value of 1 will only be activated in special occasions, for ins= tance when there is a high concentration of devices. The rest of the time t= he value would be either 0 or not communicated.

The ETSI standard deals with device requiremen= ts only, and does two things in my view:

1) it requires that devices support the parameter, and

2) it specifies the behaviour of the device in both scenario= s: 1) the parameter is provided and 2) the parameter is not provided (just = in case).

I am not sure whether this makes the parameter= optional from the perspective of PAWS.

Regards,

Cesar

From: Vincent Chen [mailto:<= A href=3D"mailto:vchen@google.com" target=3D_blank>vchen@google.com] Sent: 04 March 2014 18:10
To: Cesar Gutierrez
Cc:<= /B> Luzango Mfupe; Gabor Bajko; Brian Rosen; paws@ietf.org


Subject: Re: [paws] Revised ETSI standard
<= /DIV>

Cesar,

Looking at the ETSI EN 301 598 v1.0.9 doc, it looks li= ke this parameter is optional:

Within Table 4: "The default value is 0"

Note 2: "If the simultaneous channel operation power r= estriction parameter is not provided, ..."

So I would list this as an OPTIONAL parameter in secti= on 9.2.2.2 (the IANA section for ETSI specifics).

Does that sound right?

Thanks.

-vince

On Tue, Mar 4, 2014 at 2:59 AM, Cesar Gutierrez <Cesar.Gutierr= ez@ofcom.org.uk> wrote:

Luzango,

Support for this parameter is mandatory in ETS= I EN 301 598. A device manufacturer that chooses the route of compliance wi= th the ETSI EN to put products in the EU market will have to implement it. = Secondly, Ofcom will most likely require WS databases and devices to suppor= t the parameter when we set up the licence exemption regime next year.

This doesn=E2=80=99t mean it must be supported= in PAWS right now. Database providers and device manufacturers using PAWS = could implement it as a proprietary addendum. However, it would make a lot = of sense to include it in PAWS at this stage in my view.

It would be preferable that the PAWS specifica= tion support all functionality required by the current version of the ETSI = EN. This version of the ETSI EN is now at the stage of a vote by national s= tandard organisations, and it is very very unlikely to change. Additional f= unctionality cannot be incorporated now =E2=80=93 an new work item needs to= be started in ETSI for this, and it will take more than a year to get to a= stable draft anyway. It is therefore a good point in time to align both do= cuments.

In summary, regulatory-wise it is not an absol= ute must, but it will be highly advisable.

Regards,

Cesar

From: Luzango Mfupe [mailto:= LMfupe@csir.co.za]=
Sent: 04 March 2014 06:58
To: Gabor Bajko; Brian Rose= n; Cesar Gutierrez
Cc: paws@ietf.org


Subject: Re: [paws] Revised ETSI standard

Hi Cesar,

What will be the implications regulatory-wise of not includ= ing this new ETSI requirement in PAWS version 1?, is this not an optional r= equirement?

Regards

Luzango.

>>> = Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> 03/03/2014 19:00 >>>= ;
Gabor, Brian,

I think that what we would be looking for is a ne= w parameter added to the SpectrumSpec element.

I suggest the followi= ng:

Parameter name: etsiEnSimultaneousChannelOperationRestrictionParameter usage location: SpectrumSpec (Section 5.9)
Specification docu= ment: Specifies the constraint on the device maximum total EIRP, as defined= by the ETSI Harmonised Standard [ETSI-EN-301-598]. The values are represen= ted by numeric strings, such as "0", "1", etc. Consult the documentation fo= r the specification of the power constrain corresponding to each parameter = value.


It would be great if we could consider this at the WG mee= ting tomorrow.

Thanks and regards,
Cesar


-----Original= Message-----
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: 27 Februa= ry 2014 15:51
To: Gabor Bajko
Cc: Cesar Gutierrez; paws@ietf.org
Subject: Re: [paws] Rev= ised ETSI standard

Can do. We'll cover this at the end of the -proto= col discussion.

Brian

On Feb 26, 2014, at 6:22 PM, Gabor Bajk= o <gaborbajko@gm= ail.com> wrote:

> The need for this requirement should be = discussed on the list; and if
> agreed, it can be incorporated by the= editor into a future draft
> version.
> I won't be there in Lo= ndon, but perhaps, if you or someone else could
> propose text this w= eek, Brian could add it to next week's agenda.
>
> - Gabor
&= gt;
> On Wed, Feb 26, 2014 at 10:12 AM, Cesar Gutierrez
> <<= A href=3D"mailto:Cesar.Gutierrez@ofcom.org.uk" target=3D_blank>Cesar.Gutier= rez@ofcom.org.uk> wrote:
>> Dear all,
>>
>&g= t;
>>
>> There is a new version available of ETSI EN 301 = 598 (this is the
>> standard that lays out the requirements for op= eration in Europe).
>> Most of the changes relate to RF requiremen= ts, but there is also an
>> additional information element that th= e database will have to communicate to the Master device.
>> This = element indicates whether simultaneous transmission over
>> multip= le channels must be restricted in power, and it can take the values of 0 an= d 1.
>>
>>
>>
>> EN 301 598 v1.0.9 can = be found here:
>>
>> http://www.et= si.org/deliver/etsi_en/301500_301599/301598/01.00.09_30/
>> en= _301598v010009v.pdf
>>
>> and the addition I am referring= to is described in section 4.2.3.4
>> and in table 4.
>>=
>>
>>
>> Is it still possible to incorporate th= is new information element to
>> the PAWS specification?
>&g= t;
>>
>>
>> Thanks and regards,
>>
&= gt;> Cesar
>>
>>
>>
>>
>> _= _______________________________
>>
>> *******************= **************************************************
>> ************= *********************************
>> For more information visit www.ofcom.org.uk
&= gt;>
>> This email (and any attachments) is confidential and in= tended for the
>> use of the addressee only.
>>
>&g= t; If you have received this email in error please notify the originator>> of the message and delete it from your system.
>>
>= ;> This email has been scanned for viruses. However, you open any
>= ;> attachments at your own risk.
>>
>> Any views expre= ssed in this message are those of the individual
>> sender and do = not represent the views or opinions of Ofcom unless
>> expressly s= tated otherwise.
>> **********************************************= ***********************
>> ***************************************= ******
>>
>> ____________________________________________= ___
>> paws mailing list
>> paws@ietf.org
>> https://www.ietf.org/mailman/= listinfo/paws
>>
>
> _____________________________= __________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailm= an/listinfo/paws


________________________________

***= ***************************************************************************= ************************************
For more information visit www.ofcom.org.uk

Th= is email (and any attachments) is confidential and intended for the use of = the addressee only.

If you have received this email in error please = notify the originator of the message and delete it from your system.
This email has been scanned for viruses. However, you open any attachments= at your own risk.

Any views expressed in this message are those of = the individual sender and do not represent the views or opinions of Ofcom u= nless expressly stated otherwise.
**************************************= ***************************************************************************= *


--
This message is subject to the CSIR's copyright = terms and conditions, e-mail legal notice, and implemented Open Document Fo= rmat (ODF) standard.
The full disclaimer details can be found at http://www.csir= .co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, =
and is believed to be clean.

Please consider the environment before printing this email.


**************************************************************= ****************************************************
For more informatio= n visit www.ofcom.org.u= k

This email (and any attachments) is confidential and intended = for the use of the addressee only.

If you have received this email i= n error please notify the originator of the message and delete it from your= system.

This email has been scanned for viruses. However, you open = any attachments at your own risk.

Any views expressed in this messag= e are those of the individual sender and do not represent the views or opin= ions of Ofcom unless expressly stated otherwise.
***********************= ***************************************************************************= ****************


____________________= ___________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/lis= tinfo/paws



--
-vince



***************************************= ***************************************************************************=
For more information visit www.ofcom.org.uk

This email (and any attachments) is c= onfidential and intended for the use of the addressee only.

If you h= ave received this email in error please notify the originator of the messag= e and delete it from your system.

This email has been scanned for vi= ruses. However, you open any attachments at your own risk.

Any views= expressed in this message are those of the individual sender and do not re= present the views or opinions of Ofcom unless expressly stated otherwise.*************************************************************************= *****************************************



--
-vince

--=20
This message is subject to the CSIR's copyright terms and conditions,= e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.


This message has been scanned for viruses and dangerous content by MailScanner,=20
and is believed to be clean.


Please consider the environment before printing this email. --=__Part83B1CB67.3__=-- --=__Part83B1CB67.2__=-- From nobody Wed Mar 5 06:26:53 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E101A0203 for ; Wed, 5 Mar 2014 06:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RsVNVXR0a-U for ; Wed, 5 Mar 2014 06:26:47 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8087F1A0245 for ; Wed, 5 Mar 2014 06:26:46 -0800 (PST) Received: from [85.158.136.3:2289] by server-10.bemta-5.messagelabs.com id F2/90-08578-12437135; Wed, 05 Mar 2014 14:26:41 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-13.tower-123.messagelabs.com!1394029540!34162515!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14297 invoked from network); 5 Mar 2014 14:25:40 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-13.tower-123.messagelabs.com with AES128-SHA encrypted SMTP; 5 Mar 2014 14:25:40 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 5 Mar 2014 14:25:39 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%14]) with mapi id 14.03.0136.001; Wed, 5 Mar 2014 14:25:38 +0000 From: Cesar Gutierrez To: Vincent Chen Thread-Topic: [paws] Revised ETSI standard Thread-Index: AQHPN3cds+k5bdpqR2WDG2AKa+qGP5rQvSDAgAB9uYCAAAmR0IAAhbQAgADENoA= Date: Wed, 5 Mar 2014 14:25:43 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655B3CEA8AD@WOK-INTRA-EXC02.intra.ofcom.local> References: <531595A70200009E0008F0E1@pta-emo.csir.co.za> <5D3E853BEE49C848BB63047C794C8655B3CE98DD@WOK-INTRA-EXC02.intra.ofcom.local> <5D3E853BEE49C848BB63047C794C8655B3CE9E1B@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655B3CEA8ADWOKINTRAEXC02in_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/HsHRxAVEIt_E7yylmLgsYM-x4e8 Cc: "paws@ietf.org" , Luzango Mfupe Subject: Re: [paws] Revised ETSI standard X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 14:26:52 -0000 --_000_5D3E853BEE49C848BB63047C794C8655B3CEA8ADWOKINTRAEXC02in_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmluY2Ug4oCTIHRoYW5rcyBmb3IgdGhpcywgSSBhZ3JlZSBpdCBjYXB0dXJlcyB0aGUgcmVxdWly ZW1lbnQuDQoNCkNlc2FyDQoNCkZyb206IFZpbmNlbnQgQ2hlbiBbbWFpbHRvOnZjaGVuQGdvb2ds ZS5jb21dDQpTZW50OiAwNSBNYXJjaCAyMDE0IDAyOjQyDQpUbzogQ2VzYXIgR3V0aWVycmV6DQpD YzogTHV6YW5nbyBNZnVwZTsgR2Fib3IgQmFqa287IEJyaWFuIFJvc2VuOyBwYXdzQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFJldmlzZWQgRVRTSSBzdGFuZGFyZA0KDQpUaGFua3MgQ2Vz YXIsDQoNCkhlcmUncyB0aGUgcHJvcG9zZWQgbGFuZ3VhZ2U6DQoNCiAgICAgIGV0c2lFblNpbXVs dGFuZW91c0NoYW5uZWxPcGVyYXRpb25SZXN0cmljdGlvbjogIFNwZWNpZmllcyBhDQogICAgICAg ICBjb25zdHJhaW50IG9uIHNpbXVsdGFuZW91cyBjaGFubmVsIG9wZXJhdGlvbi4gIFRoZSBEYXRh YmFzZSBNQVkNCiAgICAgICAgIGluY2x1ZGUgdGhpcyBmaWVsZCB3aXRoaW4gdGhlIFNwZWN0cnVt U3BlYyAoU2VjdGlvbiA1LjkpDQogICAgICAgICBwYXJhbWV0ZXIgb2YgdGhlIEFWQUlMX1NQRUNU UlVNX1JFU1AgKFNlY3Rpb24gNC40LjIpIGFuZA0KICAgICAgICAgQVZBSUxfU1BFQ1RSVU1fQkFU Q0hfUkVTUCAoU2VjdGlvbiA0LjQuNCkgbWVzc2FnZXMuICBJZiBpdCBpcw0KICAgICAgICAgbm90 IHByb3ZpZGVkLCB0aGUgRGV2aWNlIE1VU1QgYXNzdW1lIHRoZSB2YWx1ZSBvZiAiMCIuICBJZiBp dA0KICAgICAgICAgaXMgcHJvdmlkZWQsIHRoZSBEZXZpY2UgTVVTVCBOT1QgaWdub3JlIGl0Lg0K DQpJIGJlbGlldmUgaXQgY2FwdHVyZXMgdGhlIGludGVudC4NCi12aW5jZQ0KDQpPbiBUdWUsIE1h ciA0LCAyMDE0IGF0IDEwOjU2IEFNLCBDZXNhciBHdXRpZXJyZXogPENlc2FyLkd1dGllcnJlekBv ZmNvbS5vcmcudWs8bWFpbHRvOkNlc2FyLkd1dGllcnJlekBvZmNvbS5vcmcudWs+PiB3cm90ZToN ClZpbmNlLA0KDQpJIHJlY29nbmlzZSB0aGF0IHRoZSBFVFNJIHN0YW5kYXJkIGlzIG5vdCB2ZXJ5 IGNsZWFyIG9uIHRoaXMgYW5kIHBlb3BsZSBtYXkgZW5kIHVwIHdpdGggZGlmZmVyZW50IGludGVy cHJldGF0aW9ucy4gVGhlIGludGVudGlvbiBpcyB0aGF0IGRldmljZXMgbXVzdCBzdXBwb3J0IHRo YXQgcGFyYW1ldGVyLiBIb3dldmVyLCBpZiB0aGUgZGF0YWJhc2UgZG9lcyBub3Qgc2VuZCBpdCB0 aGVuIHRoZSBkZXZpY2UgbXVzdCByZWFjdCBhcyBpZiB0aGUgZGVmYXVsdCB2YWx1ZSBoYWQgYmVl biBwcm92aWRlZC4NCg0KVGhlIHJhdGlvbmFsZSBpcyB0aGF0IHRoZSBwb3dlciBjb25zdHJhaW50 IGluZGljYXRlZCBieSBhIHZhbHVlIG9mIDEgd2lsbCBvbmx5IGJlIGFjdGl2YXRlZCBpbiBzcGVj aWFsIG9jY2FzaW9ucywgZm9yIGluc3RhbmNlIHdoZW4gdGhlcmUgaXMgYSBoaWdoIGNvbmNlbnRy YXRpb24gb2YgZGV2aWNlcy4gVGhlIHJlc3Qgb2YgdGhlIHRpbWUgdGhlIHZhbHVlIHdvdWxkIGJl IGVpdGhlciAwIG9yIG5vdCBjb21tdW5pY2F0ZWQuDQoNClRoZSBFVFNJIHN0YW5kYXJkICBkZWFs cyB3aXRoIGRldmljZSByZXF1aXJlbWVudHMgb25seSwgYW5kIGRvZXMgdHdvIHRoaW5ncyBpbiBt eSB2aWV3Og0KDQoxKSAgICBpdCByZXF1aXJlcyB0aGF0IGRldmljZXMgc3VwcG9ydCB0aGUgcGFy YW1ldGVyLCBhbmQNCg0KMikgICAgaXQgc3BlY2lmaWVzIHRoZSBiZWhhdmlvdXIgb2YgdGhlIGRl dmljZSBpbiBib3RoIHNjZW5hcmlvczogMSkgdGhlIHBhcmFtZXRlciBpcyBwcm92aWRlZCBhbmQg MikgdGhlIHBhcmFtZXRlciBpcyBub3QgcHJvdmlkZWQgKGp1c3QgaW4gY2FzZSkuDQoNCkkgYW0g bm90IHN1cmUgd2hldGhlciB0aGlzIG1ha2VzIHRoZSBwYXJhbWV0ZXIgb3B0aW9uYWwgZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgUEFXUy4NCg0KUmVnYXJkcywNCkNlc2FyDQoNCkZyb206IFZpbmNl bnQgQ2hlbiBbbWFpbHRvOnZjaGVuQGdvb2dsZS5jb208bWFpbHRvOnZjaGVuQGdvb2dsZS5jb20+ XQ0KU2VudDogMDQgTWFyY2ggMjAxNCAxODoxMA0KVG86IENlc2FyIEd1dGllcnJleg0KQ2M6IEx1 emFuZ28gTWZ1cGU7IEdhYm9yIEJhamtvOyBCcmlhbiBSb3NlbjsgcGF3c0BpZXRmLm9yZzxtYWls dG86cGF3c0BpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtwYXdzXSBSZXZpc2VkIEVUU0kgc3Rh bmRhcmQNCg0KQ2VzYXIsDQoNCkxvb2tpbmcgYXQgdGhlIEVUU0kgRU4gMzAxIDU5OCB2MS4wLjkg ZG9jLCBpdCBsb29rcyBsaWtlIHRoaXMgcGFyYW1ldGVyIGlzIG9wdGlvbmFsOg0KDQogIFdpdGhp biBUYWJsZSA0OiAgIlRoZSBkZWZhdWx0IHZhbHVlIGlzIDAiDQogIE5vdGUgMjogIklmIHRoZSBz aW11bHRhbmVvdXMgY2hhbm5lbCBvcGVyYXRpb24gcG93ZXIgcmVzdHJpY3Rpb24gcGFyYW1ldGVy IGlzIG5vdCBwcm92aWRlZCwgLi4uIg0KDQpTbyBJIHdvdWxkIGxpc3QgdGhpcyBhcyBhbiBPUFRJ T05BTCBwYXJhbWV0ZXIgaW4gc2VjdGlvbiA5LjIuMi4yICh0aGUgSUFOQSBzZWN0aW9uIGZvciBF VFNJIHNwZWNpZmljcykuDQpEb2VzIHRoYXQgc291bmQgcmlnaHQ/DQoNClRoYW5rcy4NCg0KLXZp bmNlDQoNCk9uIFR1ZSwgTWFyIDQsIDIwMTQgYXQgMjo1OSBBTSwgQ2VzYXIgR3V0aWVycmV6IDxD ZXNhci5HdXRpZXJyZXpAb2Zjb20ub3JnLnVrPG1haWx0bzpDZXNhci5HdXRpZXJyZXpAb2Zjb20u b3JnLnVrPj4gd3JvdGU6DQpMdXphbmdvLA0KU3VwcG9ydCBmb3IgdGhpcyBwYXJhbWV0ZXIgaXMg bWFuZGF0b3J5IGluIEVUU0kgRU4gMzAxIDU5OC4gQSBkZXZpY2UgbWFudWZhY3R1cmVyIHRoYXQg Y2hvb3NlcyB0aGUgcm91dGUgb2YgY29tcGxpYW5jZSB3aXRoIHRoZSBFVFNJIEVOIHRvIHB1dCBw cm9kdWN0cyBpbiB0aGUgRVUgbWFya2V0IHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgaXQuIFNlY29u ZGx5LCBPZmNvbSB3aWxsIG1vc3QgbGlrZWx5IHJlcXVpcmUgV1MgZGF0YWJhc2VzIGFuZCBkZXZp Y2VzIHRvIHN1cHBvcnQgdGhlIHBhcmFtZXRlciB3aGVuIHdlIHNldCB1cCB0aGUgbGljZW5jZSBl eGVtcHRpb24gcmVnaW1lIG5leHQgeWVhci4NClRoaXMgZG9lc27igJl0IG1lYW4gaXQgbXVzdCBi ZSBzdXBwb3J0ZWQgaW4gUEFXUyByaWdodCBub3cuIERhdGFiYXNlIHByb3ZpZGVycyBhbmQgZGV2 aWNlIG1hbnVmYWN0dXJlcnMgdXNpbmcgUEFXUyBjb3VsZCBpbXBsZW1lbnQgaXQgYXMgYSBwcm9w cmlldGFyeSBhZGRlbmR1bS4gSG93ZXZlciwgaXQgd291bGQgbWFrZSBhIGxvdCBvZiBzZW5zZSB0 byBpbmNsdWRlIGl0IGluIFBBV1MgYXQgdGhpcyBzdGFnZSBpbiBteSB2aWV3Lg0KSXQgd291bGQg YmUgcHJlZmVyYWJsZSB0aGF0IHRoZSBQQVdTIHNwZWNpZmljYXRpb24gc3VwcG9ydCBhbGwgZnVu Y3Rpb25hbGl0eSByZXF1aXJlZCBieSB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBFVFNJIEVO LiBUaGlzIHZlcnNpb24gb2YgdGhlIEVUU0kgRU4gaXMgbm93IGF0IHRoZSBzdGFnZSBvZiBhIHZv dGUgYnkgbmF0aW9uYWwgc3RhbmRhcmQgb3JnYW5pc2F0aW9ucywgYW5kIGl0IGlzIHZlcnkgdmVy eSB1bmxpa2VseSB0byBjaGFuZ2UuIEFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBjYW5ub3QgYmUg aW5jb3Jwb3JhdGVkIG5vdyDigJMgYW4gbmV3IHdvcmsgaXRlbSBuZWVkcyB0byBiZSBzdGFydGVk IGluIEVUU0kgZm9yIHRoaXMsIGFuZCBpdCB3aWxsIHRha2UgbW9yZSB0aGFuIGEgeWVhciB0byBn ZXQgdG8gYSBzdGFibGUgZHJhZnQgYW55d2F5LiBJdCBpcyB0aGVyZWZvcmUgYSBnb29kIHBvaW50 IGluIHRpbWUgdG8gYWxpZ24gYm90aCBkb2N1bWVudHMuDQpJbiBzdW1tYXJ5LCByZWd1bGF0b3J5 LXdpc2UgaXQgaXMgbm90IGFuIGFic29sdXRlIG11c3QsIGJ1dCBpdCB3aWxsIGJlIGhpZ2hseSBh ZHZpc2FibGUuDQpSZWdhcmRzLA0KQ2VzYXINCg0KRnJvbTogTHV6YW5nbyBNZnVwZSBbbWFpbHRv OkxNZnVwZUBjc2lyLmNvLnphPG1haWx0bzpMTWZ1cGVAY3Npci5jby56YT5dDQpTZW50OiAwNCBN YXJjaCAyMDE0IDA2OjU4DQpUbzogR2Fib3IgQmFqa287IEJyaWFuIFJvc2VuOyBDZXNhciBHdXRp ZXJyZXoNCkNjOiBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KDQpTdWJqZWN0 OiBSZTogW3Bhd3NdIFJldmlzZWQgRVRTSSBzdGFuZGFyZA0KDQpIaSBDZXNhciwNCg0KV2hhdCB3 aWxsIGJlIHRoZSBpbXBsaWNhdGlvbnMgcmVndWxhdG9yeS13aXNlIG9mIG5vdCBpbmNsdWRpbmcg dGhpcyBuZXcgRVRTSSByZXF1aXJlbWVudCBpbiBQQVdTIHZlcnNpb24gMT8sIGlzIHRoaXMgbm90 IGFuIG9wdGlvbmFsIHJlcXVpcmVtZW50Pw0KUmVnYXJkcw0KTHV6YW5nby4NCg0KPj4+IENlc2Fy IEd1dGllcnJleiA8Q2VzYXIuR3V0aWVycmV6QG9mY29tLm9yZy51azxtYWlsdG86Q2VzYXIuR3V0 aWVycmV6QG9mY29tLm9yZy51az4+IDAzLzAzLzIwMTQgMTk6MDAgPj4+DQpHYWJvciwgQnJpYW4s DQoNCkkgdGhpbmsgdGhhdCB3aGF0IHdlIHdvdWxkIGJlIGxvb2tpbmcgZm9yIGlzIGEgbmV3IHBh cmFtZXRlciBhZGRlZCB0byB0aGUgU3BlY3RydW1TcGVjIGVsZW1lbnQuDQoNCkkgc3VnZ2VzdCB0 aGUgZm9sbG93aW5nOg0KDQpQYXJhbWV0ZXIgbmFtZTogZXRzaUVuU2ltdWx0YW5lb3VzQ2hhbm5l bE9wZXJhdGlvblJlc3RyaWN0aW9uDQpQYXJhbWV0ZXIgdXNhZ2UgbG9jYXRpb246IFNwZWN0cnVt U3BlYyAoU2VjdGlvbiA1LjkpDQpTcGVjaWZpY2F0aW9uIGRvY3VtZW50OiBTcGVjaWZpZXMgdGhl IGNvbnN0cmFpbnQgb24gdGhlIGRldmljZSBtYXhpbXVtIHRvdGFsIEVJUlAsIGFzIGRlZmluZWQg YnkgdGhlIEVUU0kgSGFybW9uaXNlZCBTdGFuZGFyZCAgW0VUU0ktRU4tMzAxLTU5OF0uICBUaGUg dmFsdWVzIGFyZSByZXByZXNlbnRlZCBieSBudW1lcmljIHN0cmluZ3MsICBzdWNoIGFzICIwIiwg IjEiLCBldGMuICBDb25zdWx0IHRoZSBkb2N1bWVudGF0aW9uIGZvciB0aGUgc3BlY2lmaWNhdGlv biBvZiB0aGUgcG93ZXIgY29uc3RyYWluIGNvcnJlc3BvbmRpbmcgdG8gZWFjaCBwYXJhbWV0ZXIg dmFsdWUuDQoNCg0KSXQgd291bGQgYmUgZ3JlYXQgaWYgd2UgY291bGQgY29uc2lkZXIgdGhpcyBh dCB0aGUgV0cgbWVldGluZyB0b21vcnJvdy4NCg0KVGhhbmtzIGFuZCByZWdhcmRzLA0KQ2VzYXIN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9zZW4sIEJyaWFuIFttYWls dG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXpdDQpTZW50OiAyNyBGZWJydWFyeSAyMDE0IDE1OjUx DQpUbzogR2Fib3IgQmFqa28NCkNjOiBDZXNhciBHdXRpZXJyZXo7IHBhd3NAaWV0Zi5vcmc8bWFp bHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Bhd3NdIFJldmlzZWQgRVRTSSBzdGFu ZGFyZA0KDQpDYW4gZG8uICBXZSdsbCBjb3ZlciB0aGlzIGF0IHRoZSBlbmQgb2YgdGhlIC1wcm90 b2NvbCBkaXNjdXNzaW9uLg0KDQpCcmlhbg0KDQpPbiBGZWIgMjYsIDIwMTQsIGF0IDY6MjIgUE0s IEdhYm9yIEJhamtvIDxnYWJvcmJhamtvQGdtYWlsLmNvbTxtYWlsdG86Z2Fib3JiYWprb0BnbWFp bC5jb20+PiB3cm90ZToNCg0KPiBUaGUgbmVlZCBmb3IgdGhpcyByZXF1aXJlbWVudCBzaG91bGQg YmUgZGlzY3Vzc2VkIG9uIHRoZSBsaXN0OyBhbmQgaWYNCj4gYWdyZWVkLCBpdCBjYW4gYmUgaW5j b3Jwb3JhdGVkIGJ5IHRoZSBlZGl0b3IgaW50byBhIGZ1dHVyZSBkcmFmdA0KPiB2ZXJzaW9uLg0K PiBJIHdvbid0IGJlIHRoZXJlIGluIExvbmRvbiwgYnV0IHBlcmhhcHMsIGlmIHlvdSBvciBzb21l b25lIGVsc2UgY291bGQNCj4gcHJvcG9zZSB0ZXh0IHRoaXMgd2VlaywgQnJpYW4gY291bGQgYWRk IGl0IHRvIG5leHQgd2VlaydzIGFnZW5kYS4NCj4NCj4gLSBHYWJvcg0KPg0KPiBPbiBXZWQsIEZl YiAyNiwgMjAxNCBhdCAxMDoxMiBBTSwgQ2VzYXIgR3V0aWVycmV6DQo+IDxDZXNhci5HdXRpZXJy ZXpAb2Zjb20ub3JnLnVrPG1haWx0bzpDZXNhci5HdXRpZXJyZXpAb2Zjb20ub3JnLnVrPj4gd3Jv dGU6DQo+PiBEZWFyIGFsbCwNCj4+DQo+Pg0KPj4NCj4+IFRoZXJlIGlzIGEgbmV3IHZlcnNpb24g YXZhaWxhYmxlIG9mIEVUU0kgRU4gMzAxIDU5OCAodGhpcyBpcyB0aGUNCj4+IHN0YW5kYXJkIHRo YXQgbGF5cyBvdXQgdGhlIHJlcXVpcmVtZW50cyBmb3Igb3BlcmF0aW9uIGluIEV1cm9wZSkuDQo+ PiBNb3N0IG9mIHRoZSBjaGFuZ2VzIHJlbGF0ZSB0byBSRiByZXF1aXJlbWVudHMsIGJ1dCB0aGVy ZSBpcyBhbHNvIGFuDQo+PiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGVsZW1lbnQgdGhhdCB0aGUg ZGF0YWJhc2Ugd2lsbCBoYXZlIHRvIGNvbW11bmljYXRlIHRvIHRoZSBNYXN0ZXIgZGV2aWNlLg0K Pj4gVGhpcyBlbGVtZW50IGluZGljYXRlcyB3aGV0aGVyIHNpbXVsdGFuZW91cyB0cmFuc21pc3Np b24gb3Zlcg0KPj4gbXVsdGlwbGUgY2hhbm5lbHMgbXVzdCBiZSByZXN0cmljdGVkIGluIHBvd2Vy LCBhbmQgaXQgY2FuIHRha2UgdGhlIHZhbHVlcyBvZiAwIGFuZCAxLg0KPj4NCj4+DQo+Pg0KPj4g RU4gMzAxIDU5OCB2MS4wLjkgY2FuIGJlIGZvdW5kIGhlcmU6DQo+Pg0KPj4gaHR0cDovL3d3dy5l dHNpLm9yZy9kZWxpdmVyL2V0c2lfZW4vMzAxNTAwXzMwMTU5OS8zMDE1OTgvMDEuMDAuMDlfMzAv DQo+PiBlbl8zMDE1OTh2MDEwMDA5di5wZGYNCj4+DQo+PiBhbmQgdGhlIGFkZGl0aW9uIEkgYW0g cmVmZXJyaW5nIHRvIGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDQuMi4zLjQNCj4+IGFuZCBpbiB0 YWJsZSA0Lg0KPj4NCj4+DQo+Pg0KPj4gSXMgaXQgc3RpbGwgcG9zc2libGUgdG8gaW5jb3Jwb3Jh dGUgdGhpcyBuZXcgaW5mb3JtYXRpb24gZWxlbWVudCB0bw0KPj4gdGhlIFBBV1Mgc3BlY2lmaWNh dGlvbj8NCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcyBhbmQgcmVnYXJkcywNCj4+DQo+PiBDZXNhcg0K Pj4NCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0K Pj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+PiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+IEZvciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWs8 aHR0cDovL3d3dy5vZmNvbS5vcmcudWs+DQo+Pg0KPj4gVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRh Y2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlDQo+PiB1c2Ugb2Yg dGhlIGFkZHJlc3NlZSBvbmx5Lg0KPj4NCj4+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvcg0KPj4gb2YgdGhlIG1lc3Nh Z2UgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLg0KPj4NCj4+IFRoaXMgZW1haWwgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55DQo+PiBhdHRh Y2htZW50cyBhdCB5b3VyIG93biByaXNrLg0KPj4NCj4+IEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0KPj4gc2VuZGVyIGFuZCBk byBub3QgcmVwcmVzZW50IHRoZSB2aWV3cyBvciBvcGluaW9ucyBvZiBPZmNvbSB1bmxlc3MNCj4+ IGV4cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLg0KPj4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+PiAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcGF3cyBtYWlsaW5nIGxp c3QNCj4+IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+DQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHBhd3MgbWFpbGluZyBsaXN0DQo+ IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlzaXQgd3d3Lm9mY29tLm9yZy51azxo dHRwOi8vd3d3Lm9mY29tLm9yZy51az4NCg0KVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRhY2htZW50 cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIHVzZSBvZiB0aGUgYWRkcmVz c2VlIG9ubHkuDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZy b20geW91ciBzeXN0ZW0uDQoNClRoaXMgZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suDQoN CkFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5k aXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5pb25z IG9mIE9mY29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS4NCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQotLQ0KVGhp cyBtZXNzYWdlIGlzIHN1YmplY3QgdG8gdGhlIENTSVIncyBjb3B5cmlnaHQgdGVybXMgYW5kIGNv bmRpdGlvbnMsIGUtbWFpbCBsZWdhbCBub3RpY2UsIGFuZCBpbXBsZW1lbnRlZCBPcGVuIERvY3Vt ZW50IEZvcm1hdCAoT0RGKSBzdGFuZGFyZC4NClRoZSBmdWxsIGRpc2NsYWltZXIgZGV0YWlscyBj YW4gYmUgZm91bmQgYXQgaHR0cDovL3d3dy5jc2lyLmNvLnphL2Rpc2NsYWltZXIuaHRtbC4NCg0K VGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIGRhbmdlcm91cyBj b250ZW50IGJ5IE1haWxTY2FubmVyPGh0dHA6Ly93d3cubWFpbHNjYW5uZXIuaW5mby8+LA0KYW5k IGlzIGJlbGlldmVkIHRvIGJlIGNsZWFuLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGVudmlyb25t ZW50IGJlZm9yZSBwcmludGluZyB0aGlzIGVtYWlsLg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCkZvciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcu dWs8aHR0cDovL3d3dy5vZmNvbS5vcmcudWs+DQoNClRoaXMgZW1haWwgKGFuZCBhbnkgYXR0YWNo bWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFk ZHJlc3NlZSBvbmx5Lg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UgYW5kIGRlbGV0ZSBp dCBmcm9tIHlvdXIgc3lzdGVtLg0KDQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMuIEhvd2V2ZXIsIHlvdSBvcGVuIGFueSBhdHRhY2htZW50cyBhdCB5b3VyIG93biByaXNr Lg0KDQpBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgcmVwcmVzZW50IHRoZSB2aWV3cyBvciBvcGlu aW9ucyBvZiBPZmNvbSB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBvdGhlcndpc2UuDQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGlu ZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQotLQ0KLXZpbmNlDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlz aXQgd3d3Lm9mY29tLm9yZy51azxodHRwOi8vd3d3Lm9mY29tLm9yZy51az4NCg0KVGhpcyBlbWFp bCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3Ig dGhlIHVzZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVz c2FnZSBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQoNClRoaXMgZW1haWwgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFjaG1lbnRz IGF0IHlvdXIgb3duIHJpc2suDQoNCkFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQg dGhlIHZpZXdzIG9yIG9waW5pb25zIG9mIE9mY29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90 aGVyd2lzZS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KDQoNCg0KLS0NCi12aW5jZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioNCkZvciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWsN Cg0KVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBmb3IgdGhlIHVzZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuDQoNCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQoNClRoaXMg ZW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55 IGF0dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suDQoNCkFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5v dCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5pb25zIG9mIE9mY29tIHVubGVzcyBleHByZXNz bHkgc3RhdGVkIG90aGVyd2lzZS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0K --_000_5D3E853BEE49C848BB63047C794C8655B3CEA8ADWOKINTRAEXC02in_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hfQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hfQ0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiJ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCnANCgl7 bWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYifQ0KcC5Nc29BY2V0YXRlLCBs aS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYifQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYifQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzVFMjQzQ30NCi5Nc29DaHBEZWZhdWx0DQoJe2ZvbnQtZmFt aWx5OiJBcmlhbCIsInNhbnMtc2VyaWYifQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe21hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHR9DQpkaXYuV29yZFNlY3Rpb24xDQoJe30NCi0tPg0K PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+VmluY2Ug4oCTIHRo YW5rcyBmb3IgdGhpcywgSSBhZ3JlZSBpdCBjYXB0dXJlcyB0aGUgcmVxdWlyZW1lbnQuPC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBj b2xvcjojNUUyNDNDIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPkNlc2FyPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjoj NUUyNDNDIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBWaW5jZW50IENoZW4gW21haWx0 bzp2Y2hlbkBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA1IE1hcmNoIDIwMTQgMDI6 NDI8YnI+DQo8Yj5Ubzo8L2I+IENlc2FyIEd1dGllcnJlejxicj4NCjxiPkNjOjwvYj4gTHV6YW5n byBNZnVwZTsgR2Fib3IgQmFqa287IEJyaWFuIFJvc2VuOyBwYXdzQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcGF3c10gUmV2aXNlZCBFVFNJIHN0YW5kYXJkPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MgQ2VzYXIsPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUncyB0aGUgcHJv cG9zZWQgbGFuZ3VhZ2U6PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtldHNpRW5TaW11bHRhbmVvdXNDaGFubmVsT3BlcmF0 aW9uUmVzdHJpY3Rpb246Jm5ic3A7IFNwZWNpZmllcyBhPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnN0cmFpbnQg b24gc2ltdWx0YW5lb3VzIGNoYW5uZWwgb3BlcmF0aW9uLiZuYnNwOyBUaGUgRGF0YWJhc2UgTUFZ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGluY2x1ZGUgdGhpcyBmaWVsZCB3aXRoaW4gdGhlIFNwZWN0cnVtU3BlYyAo U2VjdGlvbiA1LjkpPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBhcmFtZXRlciBvZiB0aGUgQVZBSUxfU1BFQ1RSVU1f UkVTUCAoU2VjdGlvbiA0LjQuMikgYW5kPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFWQUlMX1NQRUNUUlVNX0JBVENI X1JFU1AgKFNlY3Rpb24gNC40LjQpIG1lc3NhZ2VzLiZuYnNwOyBJZiBpdCBpczwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBub3QgcHJvdmlkZWQsIHRoZSBEZXZpY2UgTVVTVCBhc3N1bWUgdGhlIHZhbHVlIG9mICZxdW90 OzAmcXVvdDsuJm5ic3A7IElmIGl0PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+ Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIHByb3ZpZGVkLCB0aGUgRGV2aWNl IE1VU1QgTk9UIGlnbm9yZSBpdC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj4m bmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj5JIGJlbGlldmUgaXQgY2Fw dHVyZXMgdGhlIGludGVudC48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj4tdmlu Y2U8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFR1ZSwgTWFyIDQsIDIwMTQgYXQgMTA6NTYgQU0sIENlc2FyIEd1dGllcnJleiAm bHQ7PGEgaHJlZj0ibWFpbHRvOkNlc2FyLkd1dGllcnJlekBvZmNvbS5vcmcudWsiIHRhcmdldD0i X2JsYW5rIj5DZXNhci5HdXRpZXJyZXpAb2Zjb20ub3JnLnVrPC9hPiZndDsgd3JvdGU6PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+VmluY2UsPC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjoj NUUyNDNDIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPkkgcmVjb2duaXNlIHRo YXQgdGhlIEVUU0kgc3RhbmRhcmQgaXMgbm90IHZlcnkgY2xlYXIgb24gdGhpcyBhbmQgcGVvcGxl IG1heSBlbmQgdXAgd2l0aCBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zLiBUaGUgaW50ZW50aW9u IGlzIHRoYXQgZGV2aWNlcyBtdXN0DQogc3VwcG9ydCB0aGF0IHBhcmFtZXRlci4gSG93ZXZlciwg aWYgdGhlIGRhdGFiYXNlIGRvZXMgbm90IHNlbmQgaXQgdGhlbiB0aGUgZGV2aWNlIG11c3QgcmVh Y3QgYXMgaWYgdGhlIGRlZmF1bHQgdmFsdWUgaGFkIGJlZW4gcHJvdmlkZWQuPC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBjb2xvcjojNUUyNDNDIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPlRoZSBy YXRpb25hbGUgaXMgdGhhdCB0aGUgcG93ZXIgY29uc3RyYWludCBpbmRpY2F0ZWQgYnkgYSB2YWx1 ZSBvZiAxIHdpbGwgb25seSBiZSBhY3RpdmF0ZWQgaW4gc3BlY2lhbCBvY2Nhc2lvbnMsIGZvciBp bnN0YW5jZSB3aGVuIHRoZXJlIGlzIGEgaGlnaA0KIGNvbmNlbnRyYXRpb24gb2YgZGV2aWNlcy4g VGhlIHJlc3Qgb2YgdGhlIHRpbWUgdGhlIHZhbHVlIHdvdWxkIGJlIGVpdGhlciAwIG9yIG5vdCBj b21tdW5pY2F0ZWQuDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPiZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzVFMjQzQyI+VGhlIEVUU0kgc3RhbmRhcmQgJm5ic3A7ZGVhbHMgd2l0aCBk ZXZpY2UgcmVxdWlyZW1lbnRzIG9ubHksIGFuZCBkb2VzIHR3byB0aGluZ3MgaW4gbXkgdmlldzo8 L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0Mi PjEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGNvbG9yOiM1RTI0M0MiPiZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xv cjojNUUyNDNDIj5pdCByZXF1aXJlcyB0aGF0IGRldmljZXMgc3VwcG9ydCB0aGUgcGFyYW1ldGVy LCBhbmQ8L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1 RTI0M0MiPjIpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7IGNvbG9yOiM1RTI0 M0MiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBjb2xvcjojNUUyNDNDIj5pdCBzcGVjaWZpZXMgdGhlIGJlaGF2aW91ciBvZiB0aGUgZGV2aWNl IGluIGJvdGggc2NlbmFyaW9zOiAxKSB0aGUgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGFuZCAyKSB0 aGUgcGFyYW1ldGVyIGlzIG5vdCBwcm92aWRlZCAoanVzdCBpbiBjYXNlKS48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOiM1RTI0M0MiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+SSBhbSBu b3Qgc3VyZSB3aGV0aGVyIHRoaXMgbWFrZXMgdGhlIHBhcmFtZXRlciBvcHRpb25hbCBmcm9tIHRo ZSBwZXJzcGVjdGl2ZSBvZiBQQVdTLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+Jm5ic3A7 PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5SZWdhcmRzLDwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6 IzVFMjQzQyI+Q2VzYXI8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPiZuYnNwOzwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFZpbmNlbnQgQ2hlbiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp2Y2hlbkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmNoZW5AZ29vZ2xlLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDQgTWFyY2ggMjAxNCAxODoxMDxicj4NCjxiPlRvOjwv Yj4gQ2VzYXIgR3V0aWVycmV6PGJyPg0KPGI+Q2M6PC9iPiBMdXphbmdvIE1mdXBlOyBHYWJvciBC YWprbzsgQnJpYW4gUm9zZW47IDxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+DQpwYXdzQGlldGYub3JnPC9hPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Bhd3NdIFJldmlz ZWQgRVRTSSBzdGFuZGFyZDwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iIj5DZXNhciw8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IiI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IiI+TG9va2luZyBhdCB0aGUgRVRTSSBFTiAzMDEgNTk4IHYxLjAuOSBkb2MsIGl0IGxv b2tzIGxpa2UgdGhpcyBwYXJhbWV0ZXIgaXMgb3B0aW9uYWw6PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7IFdpdGhpbiBUYWJsZSA0OiAmbmJz cDsmcXVvdDtUaGUgZGVmYXVsdCB2YWx1ZSBpcyAwJnF1b3Q7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7IE5vdGUgMjogJnF1b3Q7SWYgdGhl IHNpbXVsdGFuZW91cyBjaGFubmVsIG9wZXJhdGlvbiBwb3dlciByZXN0cmljdGlvbiBwYXJhbWV0 ZXIgaXMgbm90IHByb3ZpZGVkLCAuLi4mcXVvdDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iIj5TbyBJIHdvdWxkIGxpc3QgdGhpcyBhcyBhbiBPUFRJT05B TCBwYXJhbWV0ZXIgaW4gc2VjdGlvbiA5LjIuMi4yICh0aGUgSUFOQSBzZWN0aW9uIGZvciBFVFNJ IHNwZWNpZmljcykuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9IiI+RG9lcyB0aGF0IHNvdW5kIHJpZ2h0PzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSIiPlRoYW5rcy48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iIj4tdmluY2U8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7 PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPk9uIFR1ZSwgTWFyIDQs IDIwMTQgYXQgMjo1OSBBTSwgQ2VzYXIgR3V0aWVycmV6ICZsdDs8YSBocmVmPSJtYWlsdG86Q2Vz YXIuR3V0aWVycmV6QG9mY29tLm9yZy51ayIgdGFyZ2V0PSJfYmxhbmsiPkNlc2FyLkd1dGllcnJl ekBvZmNvbS5vcmcudWs8L2E+Jmd0OyB3cm90ZTo8L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDozLjBwdDsgbWFyZ2luLXRvcDozLjBwdDsgbWFyZ2luLXJpZ2h0OjMuMHB0OyBtYXJnaW4tYm90 dG9tOi43NXB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+THV6YW5nbyw8L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOiM1RTI0M0MiPlN1cHBvcnQgZm9yIHRoaXMgcGFyYW1ldGVyIGlzIG1hbmRhdG9yeSBp biBFVFNJIEVOIDMwMSA1OTguIEEgZGV2aWNlIG1hbnVmYWN0dXJlciB0aGF0IGNob29zZXMgdGhl IHJvdXRlIG9mIGNvbXBsaWFuY2Ugd2l0aCB0aGUgRVRTSSBFTiB0byBwdXQgcHJvZHVjdHMNCiBp biB0aGUgRVUgbWFya2V0IHdpbGwgaGF2ZSB0byBpbXBsZW1lbnQgaXQuIFNlY29uZGx5LCBPZmNv bSB3aWxsIG1vc3QgbGlrZWx5IHJlcXVpcmUgV1MgZGF0YWJhc2VzIGFuZCBkZXZpY2VzIHRvIHN1 cHBvcnQgdGhlIHBhcmFtZXRlciB3aGVuIHdlIHNldCB1cCB0aGUgbGljZW5jZSBleGVtcHRpb24g cmVnaW1lIG5leHQgeWVhci48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPlRoaXMgZG9lc27i gJl0IG1lYW4gaXQgbXVzdCBiZSBzdXBwb3J0ZWQgaW4gUEFXUyByaWdodCBub3cuIERhdGFiYXNl IHByb3ZpZGVycyBhbmQgZGV2aWNlIG1hbnVmYWN0dXJlcnMgdXNpbmcgUEFXUyBjb3VsZCBpbXBs ZW1lbnQgaXQgYXMgYSBwcm9wcmlldGFyeQ0KIGFkZGVuZHVtLiBIb3dldmVyLCBpdCB3b3VsZCBt YWtlIGEgbG90IG9mIHNlbnNlIHRvIGluY2x1ZGUgaXQgaW4gUEFXUyBhdCB0aGlzIHN0YWdlIGlu IG15IHZpZXcuDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0MiPkl0IHdvdWxkIGJlIHByZWZl cmFibGUgdGhhdCB0aGUgUEFXUyBzcGVjaWZpY2F0aW9uIHN1cHBvcnQgYWxsIGZ1bmN0aW9uYWxp dHkgcmVxdWlyZWQgYnkgdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgRVRTSSBFTi4gVGhpcyB2 ZXJzaW9uIG9mIHRoZSBFVFNJDQogRU4gaXMgbm93IGF0IHRoZSBzdGFnZSBvZiBhIHZvdGUgYnkg bmF0aW9uYWwgc3RhbmRhcmQgb3JnYW5pc2F0aW9ucywgYW5kIGl0IGlzIHZlcnkgdmVyeSB1bmxp a2VseSB0byBjaGFuZ2UuIEFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBjYW5ub3QgYmUgaW5jb3Jw b3JhdGVkIG5vdyDigJMgYW4gbmV3IHdvcmsgaXRlbSBuZWVkcyB0byBiZSBzdGFydGVkIGluIEVU U0kgZm9yIHRoaXMsIGFuZCBpdCB3aWxsIHRha2UgbW9yZSB0aGFuIGEgeWVhciB0byBnZXQNCiB0 byBhIHN0YWJsZSBkcmFmdCBhbnl3YXkuIEl0IGlzIHRoZXJlZm9yZSBhIGdvb2QgcG9pbnQgaW4g dGltZSB0byBhbGlnbiBib3RoIGRvY3VtZW50cy48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0Mi PkluIHN1bW1hcnksIHJlZ3VsYXRvcnktd2lzZSBpdCBpcyBub3QgYW4gYWJzb2x1dGUgbXVzdCwg YnV0IGl0IHdpbGwgYmUgaGlnaGx5IGFkdmlzYWJsZS48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0 M0MiPlJlZ2FyZHMsPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5DZXNhcjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgY29sb3I6IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0OyBwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTHV6YW5nbyBNZnVwZSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpMTWZ1cGVAY3Npci5jby56YSIgdGFyZ2V0PSJfYmxhbmsiPkxNZnVw ZUBjc2lyLmNvLnphPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNCBNYXJjaCAyMDE0IDA2OjU4 PGJyPg0KPGI+VG86PC9iPiBHYWJvciBCYWprbzsgQnJpYW4gUm9zZW47IENlc2FyIEd1dGllcnJl ejxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Bhd3Nd IFJldmlzZWQgRVRTSSBzdGFuZGFyZDwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iIj4mbmJzcDs8L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkhpIENlc2FyLDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGF0IHdpbGwgYmUgdGhlIGltcGxp Y2F0aW9ucyByZWd1bGF0b3J5LXdpc2Ugb2Ygbm90IGluY2x1ZGluZyB0aGlzIG5ldyBFVFNJJm5i c3A7cmVxdWlyZW1lbnQmbmJzcDtpbiBQQVdTIHZlcnNpb24gMT8sIGlzIHRoaXMgbm90IGFuIG9w dGlvbmFsIHJlcXVpcmVtZW50Pzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJk czwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5MdXph bmdvLjxicj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyBDZXNhciBHdXRpZXJyZXogJmx0OzxhIGhyZWY9 Im1haWx0bzpDZXNhci5HdXRpZXJyZXpAb2Zjb20ub3JnLnVrIiB0YXJnZXQ9Il9ibGFuayI+Q2Vz YXIuR3V0aWVycmV6QG9mY29tLm9yZy51azwvYT4mZ3Q7IDAzLzAzLzIwMTQgMTk6MDAgJmd0OyZn dDsmZ3Q7PGJyPg0KR2Fib3IsIEJyaWFuLDxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB3aGF0IHdl IHdvdWxkIGJlIGxvb2tpbmcgZm9yIGlzIGEgbmV3IHBhcmFtZXRlciBhZGRlZCB0byB0aGUgU3Bl Y3RydW1TcGVjIGVsZW1lbnQuPGJyPg0KPGJyPg0KSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6PGJy Pg0KPGJyPg0KUGFyYW1ldGVyIG5hbWU6IGV0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVyYXRp b25SZXN0cmljdGlvbjxicj4NClBhcmFtZXRlciB1c2FnZSBsb2NhdGlvbjogU3BlY3RydW1TcGVj IChTZWN0aW9uIDUuOSk8YnI+DQpTcGVjaWZpY2F0aW9uIGRvY3VtZW50OiBTcGVjaWZpZXMgdGhl IGNvbnN0cmFpbnQgb24gdGhlIGRldmljZSBtYXhpbXVtIHRvdGFsIEVJUlAsIGFzIGRlZmluZWQg YnkgdGhlIEVUU0kgSGFybW9uaXNlZCBTdGFuZGFyZCZuYnNwOyBbRVRTSS1FTi0zMDEtNTk4XS4m bmJzcDsgVGhlIHZhbHVlcyBhcmUgcmVwcmVzZW50ZWQgYnkgbnVtZXJpYyBzdHJpbmdzLCZuYnNw OyBzdWNoIGFzICZxdW90OzAmcXVvdDssICZxdW90OzEmcXVvdDssIGV0Yy4mbmJzcDsgQ29uc3Vs dCB0aGUgZG9jdW1lbnRhdGlvbiBmb3IgdGhlIHNwZWNpZmljYXRpb24NCiBvZiB0aGUgcG93ZXIg Y29uc3RyYWluIGNvcnJlc3BvbmRpbmcgdG8gZWFjaCBwYXJhbWV0ZXIgdmFsdWUuPGJyPg0KPGJy Pg0KPGJyPg0KSXQgd291bGQgYmUgZ3JlYXQgaWYgd2UgY291bGQgY29uc2lkZXIgdGhpcyBhdCB0 aGUgV0cgbWVldGluZyB0b21vcnJvdy48YnI+DQo8YnI+DQpUaGFua3MgYW5kIHJlZ2FyZHMsPGJy Pg0KQ2VzYXI8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IFJvc2VuLCBCcmlhbiBbPGEgaHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6IiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6PC9hPl08 YnI+DQpTZW50OiAyNyBGZWJydWFyeSAyMDE0IDE1OjUxPGJyPg0KVG86IEdhYm9yIEJhamtvPGJy Pg0KQ2M6IENlc2FyIEd1dGllcnJlejsgPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbcGF3c10g UmV2aXNlZCBFVFNJIHN0YW5kYXJkPGJyPg0KPGJyPg0KQ2FuIGRvLiZuYnNwOyBXZSdsbCBjb3Zl ciB0aGlzIGF0IHRoZSBlbmQgb2YgdGhlIC1wcm90b2NvbCBkaXNjdXNzaW9uLjxicj4NCjxicj4N CkJyaWFuPGJyPg0KPGJyPg0KT24gRmViIDI2LCAyMDE0LCBhdCA2OjIyIFBNLCBHYWJvciBCYWpr byAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdhYm9yYmFqa29AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+Z2Fib3JiYWprb0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IFRo ZSBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IHNob3VsZCBiZSBkaXNjdXNzZWQgb24gdGhlIGxp c3Q7IGFuZCBpZjxicj4NCiZndDsgYWdyZWVkLCBpdCBjYW4gYmUgaW5jb3Jwb3JhdGVkIGJ5IHRo ZSBlZGl0b3IgaW50byBhIGZ1dHVyZSBkcmFmdDxicj4NCiZndDsgdmVyc2lvbi48YnI+DQomZ3Q7 IEkgd29uJ3QgYmUgdGhlcmUgaW4gTG9uZG9uLCBidXQgcGVyaGFwcywgaWYgeW91IG9yIHNvbWVv bmUgZWxzZSBjb3VsZDxicj4NCiZndDsgcHJvcG9zZSB0ZXh0IHRoaXMgd2VlaywgQnJpYW4gY291 bGQgYWRkIGl0IHRvIG5leHQgd2VlaydzIGFnZW5kYS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIEdh Ym9yPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBGZWIgMjYsIDIwMTQgYXQgMTA6MTIgQU0s IENlc2FyIEd1dGllcnJlejxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpDZXNhci5HdXRp ZXJyZXpAb2Zjb20ub3JnLnVrIiB0YXJnZXQ9Il9ibGFuayI+Q2VzYXIuR3V0aWVycmV6QG9mY29t Lm9yZy51azwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IERlYXIgYWxsLDxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZXJlIGlzIGEg bmV3IHZlcnNpb24gYXZhaWxhYmxlIG9mIEVUU0kgRU4gMzAxIDU5OCAodGhpcyBpcyB0aGU8YnI+ DQomZ3Q7Jmd0OyBzdGFuZGFyZCB0aGF0IGxheXMgb3V0IHRoZSByZXF1aXJlbWVudHMgZm9yIG9w ZXJhdGlvbiBpbiBFdXJvcGUpLjxicj4NCiZndDsmZ3Q7IE1vc3Qgb2YgdGhlIGNoYW5nZXMgcmVs YXRlIHRvIFJGIHJlcXVpcmVtZW50cywgYnV0IHRoZXJlIGlzIGFsc28gYW48YnI+DQomZ3Q7Jmd0 OyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGVsZW1lbnQgdGhhdCB0aGUgZGF0YWJhc2Ugd2lsbCBo YXZlIHRvIGNvbW11bmljYXRlIHRvIHRoZSBNYXN0ZXIgZGV2aWNlLjxicj4NCiZndDsmZ3Q7IFRo aXMgZWxlbWVudCBpbmRpY2F0ZXMgd2hldGhlciBzaW11bHRhbmVvdXMgdHJhbnNtaXNzaW9uIG92 ZXI8YnI+DQomZ3Q7Jmd0OyBtdWx0aXBsZSBjaGFubmVscyBtdXN0IGJlIHJlc3RyaWN0ZWQgaW4g cG93ZXIsIGFuZCBpdCBjYW4gdGFrZSB0aGUgdmFsdWVzIG9mIDAgYW5kIDEuPGJyPg0KJmd0OyZn dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRU4gMzAxIDU5OCB2 MS4wLjkgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwOi8vd3d3LmV0c2kub3JnL2RlbGl2ZXIvZXRzaV9lbi8zMDE1MDBfMzAxNTk5LzMw MTU5OC8wMS4wMC4wOV8zMC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuZXRzaS5vcmcv ZGVsaXZlci9ldHNpX2VuLzMwMTUwMF8zMDE1OTkvMzAxNTk4LzAxLjAwLjA5XzMwLzwvYT48YnI+ DQomZ3Q7Jmd0OyBlbl8zMDE1OTh2MDEwMDA5di5wZGY8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IGFuZCB0aGUgYWRkaXRpb24gSSBhbSByZWZlcnJpbmcgdG8gaXMgZGVzY3JpYmVkIGluIHNl Y3Rpb24gNC4yLjMuNDxicj4NCiZndDsmZ3Q7IGFuZCBpbiB0YWJsZSA0Ljxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElzIGl0IHN0aWxsIHBv c3NpYmxlIHRvIGluY29ycG9yYXRlIHRoaXMgbmV3IGluZm9ybWF0aW9uIGVsZW1lbnQgdG88YnI+ DQomZ3Q7Jmd0OyB0aGUgUEFXUyBzcGVjaWZpY2F0aW9uPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyBhbmQgcmVnYXJkcyw8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IENlc2FyPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPGJyPg0KJmd0OyZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqPGJyPg0KJmd0OyZndDsgRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlzaXQgPGEgaHJlZj0i aHR0cDovL3d3dy5vZmNvbS5vcmcudWsiIHRhcmdldD0iX2JsYW5rIj53d3cub2Zjb20ub3JnLnVr PC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhpcyBlbWFpbCAoYW5kIGFueSBhdHRh Y2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlPGJyPg0KJmd0OyZn dDsgdXNlIG9mIHRoZSBhZGRyZXNzZWUgb25seS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0 aGUgb3JpZ2luYXRvcjxicj4NCiZndDsmZ3Q7IG9mIHRoZSBtZXNzYWdlIGFuZCBkZWxldGUgaXQg ZnJvbSB5b3VyIHN5c3RlbS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoaXMgZW1haWwg aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55PGJyPg0K Jmd0OyZndDsgYXR0YWNobWVudHMgYXQgeW91ciBvd24gcmlzay48YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbDxicj4NCiZndDsmZ3Q7IHNlbmRlciBhbmQgZG8gbm90IHJlcHJlc2Vu dCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5sZXNzPGJyPg0KJmd0OyZndDsgZXhw cmVzc2x5IHN0YXRlZCBvdGhlcndpc2UuPGJyPg0KJmd0OyZndDsgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0K Jmd0OyZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHBhd3MgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdz QGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0OyBwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnBhd3NA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjxi cj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJy Pg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlzaXQgPGEgaHJlZj0iaHR0cDovL3d3dy5v ZmNvbS5vcmcudWsiIHRhcmdldD0iX2JsYW5rIj53d3cub2Zjb20ub3JnLnVrPC9hPjxicj4NCjxi cj4NClRoaXMgZW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBvbmx5Ljxicj4NCjxicj4NCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0u PGJyPg0KPGJyPg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzLiBIb3dl dmVyLCB5b3Ugb3BlbiBhbnkgYXR0YWNobWVudHMgYXQgeW91ciBvd24gcmlzay48YnI+DQo8YnI+ DQpBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgcmVwcmVzZW50IHRoZSB2aWV3cyBvciBvcGluaW9u cyBvZiBPZmNvbSB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBvdGhlcndpc2UuPGJyPg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPC9zcGFu PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQotLSA8YnI+DQpUaGlzIG1lc3NhZ2UgaXMgc3ViamVjdCB0 byB0aGUgQ1NJUidzIGNvcHlyaWdodCB0ZXJtcyBhbmQgY29uZGl0aW9ucywgZS1tYWlsIGxlZ2Fs IG5vdGljZSwgYW5kIGltcGxlbWVudGVkIE9wZW4gRG9jdW1lbnQgRm9ybWF0IChPREYpIHN0YW5k YXJkLg0KPGJyPg0KVGhlIGZ1bGwgZGlzY2xhaW1lciBkZXRhaWxzIGNhbiBiZSBmb3VuZCBhdCA8 YSBocmVmPSJodHRwOi8vd3d3LmNzaXIuY28uemEvZGlzY2xhaW1lci5odG1sIiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwOi8vd3d3LmNzaXIuY28uemEvZGlzY2xhaW1lci5odG1sPC9hPi4gPC9zcGFu PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIGRhbmdlcm91cyBjb250ZW50IGJ5IDxh IGhyZWY9Imh0dHA6Ly93d3cubWFpbHNjYW5uZXIuaW5mby8iIHRhcmdldD0iX2JsYW5rIj4NCjxi Pk1haWxTY2FubmVyPC9iPjwvYT4sIDxicj4NCmFuZCBpcyBiZWxpZXZlZCB0byBiZSBjbGVhbi4g PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KUGxlYXNl IGNvbnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcHJpbnRpbmcgdGhpcyBlbWFpbC4gPC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9IiI+Jm5ic3A7PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdp ZHRoPSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmdyYXkiPjxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCkZvciBtb3JlIGluZm9y bWF0aW9uIHZpc2l0IDxhIGhyZWY9Imh0dHA6Ly93d3cub2Zjb20ub3JnLnVrIiB0YXJnZXQ9Il9i bGFuayI+d3d3Lm9mY29tLm9yZy51azwvYT48YnI+DQo8YnI+DQpUaGlzIGVtYWlsIChhbmQgYW55 IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgdXNlIG9m IHRoZSBhZGRyZXNzZWUgb25seS48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxicj4NCjxicj4NClRoaXMgZW1haWwg aGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFj aG1lbnRzIGF0IHlvdXIgb3duIHJpc2suPGJyPg0KPGJyPg0KQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgZG8g bm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5sZXNzIGV4cHJl c3NseSBzdGF0ZWQgb3RoZXJ3aXNlLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSIiPiZuYnNwOzwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IiI+LS0gPGJyPg0KLXZpbmNlIDwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0 eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWdu PSJjZW50ZXIiPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6 Z3JheSI+PGJyPg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqPGJyPg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlzaXQgPGEgaHJlZj0iaHR0 cDovL3d3dy5vZmNvbS5vcmcudWsiIHRhcmdldD0iX2JsYW5rIj53d3cub2Zjb20ub3JnLnVrPC9h Pjxicj4NCjxicj4NClRoaXMgZW1haWwgKGFuZCBhbnkgYXR0YWNobWVudHMpIGlzIGNvbmZpZGVu dGlhbCBhbmQgaW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBvbmx5Ljxicj4N Cjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZSBhbmQgZGVsZXRlIGl0IGZyb20geW91 ciBzeXN0ZW0uPGJyPg0KPGJyPg0KVGhpcyBlbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzLiBIb3dldmVyLCB5b3Ugb3BlbiBhbnkgYXR0YWNobWVudHMgYXQgeW91ciBvd24gcmlzay48 YnI+DQo8YnI+DQpBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyIGFuZCBkbyBub3QgcmVwcmVzZW50IHRoZSB2aWV3cyBv ciBvcGluaW9ucyBvZiBPZmNvbSB1bmxlc3MgZXhwcmVzc2x5IHN0YXRlZCBvdGhlcndpc2UuPGJy Pg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g PGJyPg0KLXZpbmNlIDwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjIiPjxicj4NCioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCkZvciBtb3JlIGluZm9y bWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWs8YnI+DQo8YnI+DQpUaGlzIGVtYWlsIChhbmQg YW55IGF0dGFjaG1lbnRzKSBpcyBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIGZvciB0aGUgdXNl IG9mIHRoZSBhZGRyZXNzZWUgb25seS48YnI+DQo8YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l c3NhZ2UgYW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLjxicj4NCjxicj4NClRoaXMgZW1h aWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0 dGFjaG1lbnRzIGF0IHlvdXIgb3duIHJpc2suPGJyPg0KPGJyPg0KQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQg ZG8gbm90IHJlcHJlc2VudCB0aGUgdmlld3Mgb3Igb3BpbmlvbnMgb2YgT2Zjb20gdW5sZXNzIGV4 cHJlc3NseSBzdGF0ZWQgb3RoZXJ3aXNlLjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_5D3E853BEE49C848BB63047C794C8655B3CEA8ADWOKINTRAEXC02in_-- From nobody Wed Mar 5 07:09:53 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5B01A0276; Wed, 5 Mar 2014 07:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DtiihSmvEHC; Wed, 5 Mar 2014 07:09:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 917BC1A01C0; Wed, 5 Mar 2014 07:09:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> Date: Wed, 05 Mar 2014 07:09:48 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/GoJT4ukUPymjx9OC_pEsn7As8rM Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 15:09:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Protocol to Access WS database Working Group of the IETF. Title : Protocol to Access White-Space (PAWS) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-11.txt Pages : 108 Date : 2014-03-05 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 5 07:17:35 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5051A025A for ; Wed, 5 Mar 2014 07:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kuv4Q2e7LH1W for ; Wed, 5 Mar 2014 07:17:30 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 91E791A06B8 for ; Wed, 5 Mar 2014 07:17:30 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wp18so1150268obc.9 for ; Wed, 05 Mar 2014 07:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=AU4rjzwrsjEJ+3GxbQxpaMKKK/jZeeB+kmGaYo6BxQk=; b=nwt139dIy9N78EjhTtyVO6AwxBj47+u+HdqLIiHQ3LlYiN14t0K2MTq5XbZkt+JmyS 47MElA1b6bPB63OXHRsyv7opzhPMFEqjAwKQtJUivvjBah+epKhXg1nNjvFTngXrtn5c 9jjuTg1jqVmO9Wef9gDF4htWHRIRO9U420Isg3AsrP+TaGhaQUCvoyoolVp0xzW6E+6I Mz4eEnRBi0OBKyXzVg9No2/6RVHBHSLCc2Hx2sk+R+JNjmvmDDWPqM7ZJCH3zLcMG/Sx uKi/RQQdjCt1UGsYSKZ5WLm8fh4PRJlUWcfI8qgmWvRoSg2FWVXyKFMhdFVOg4PQjowd KA8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AU4rjzwrsjEJ+3GxbQxpaMKKK/jZeeB+kmGaYo6BxQk=; b=fVO0/jNsmsBBaUOmM4QYPdCZTVjY56WLs7PeqnOBouhBHWcIUcR4H7dV3dd4Pn7a69 xKdPCunluDQAGngurp0bdpdOfAZ6B+UPoKVJtmOlc+nILQU6A7o/EGy7ingxdy4KLAXj JkQ1os6UB5SzG7fEuuNpykEBarye4Sy6lpUGI9k/ReBrSux/0Iqj1u8xZ/XthvL7WTgl UwQMjvp65UHD44P7cCM8KaqnsHD6gZkm0Xz86OveGw2OJ+GJzSfbouTM3jwHGCeKwRdR wL61ZetAR43hUrgcaxCmGFz42Ajv+L7c1L0cluMwhw3UF+1hWeHBBG6Xzz6iPMX3YWh0 TzWg== X-Gm-Message-State: ALoCoQkchG3rrNnAdRQq71wAc1P96QtoTt64YZA8uHfCcw9h2Cyb1WKMj5Li/gnDX0QWwxjVf9MlgndZtauaCL/Y2DtUq+k7AlnBr7ebZm0jRjvfmAnnPBsiFyFJZILQj5xM5uBzSxDRQvwgOA0im/CLxr2LQnHAGCjoe4QW/lIYVRWB2HgVqudjTgc3//gGuWV5t61IS3u7 MIME-Version: 1.0 X-Received: by 10.182.97.67 with SMTP id dy3mr404517obb.84.1394032646793; Wed, 05 Mar 2014 07:17:26 -0800 (PST) Received: by 10.182.45.166 with HTTP; Wed, 5 Mar 2014 07:17:26 -0800 (PST) In-Reply-To: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> Date: Wed, 5 Mar 2014 07:17:26 -0800 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e4c02b88c0f04f3dd84af Archived-At: http://mailarchive.ietf.org/arch/msg/paws/jwqfPBndfZsUhoAHffYNGT4ZIMc Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 05 Mar 2014 15:17:33 -0000 --047d7b2e4c02b88c0f04f3dd84af Content-Type: text/plain; charset=UTF-8 PAWS, Draft 11 contains the following changes: - Separation of protocol and regulatory requirements. In essence, MAY, MUST , SHOULD has been replaced where the text describes regulatory requirements and device behavior. They are replaced with just explanatory text. - Added the new ETSI parameter for simultaneous channel-operation restrictions Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11 -vince On Wed, Mar 5, 2014 at 7:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol to Access WS database Working > Group of the IETF. > > Title : Protocol to Access White-Space (PAWS) Databases > Authors : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-11.txt > Pages : 108 > Date : 2014-03-05 > > Abstract: > Portions of the radio spectrum that are allocated to licensees are > available for non-interfering use. This available spectrum is called > "White Space." Allowing secondary users access to available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater overall > spectrum utilization. > > One approach to manage spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space (PAWS) Databases". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --047d7b2e4c02b88c0f04f3dd84af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

PAWS,

Draft 11 contains the following c= hanges:
=C2=A0- Separation of protocol and regulatory requirement= s. In essence, MAY, MUST , SHOULD has been replaced where the text describe= s regulatory requirements and device behavior. They are replaced with just = explanatory text.

=C2=A0- Added the new ETSI parameter for simultaneous c= hannel-operation restrictions



On Wed, Mar 5, 2014 at 7:09 AM, <internet= -drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Protocol to Access WS database Worki= ng Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Prot= ocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vincent C= hen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 108<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spectrum that are allocated to licensees= are
=C2=A0 =C2=A0available for non-interfering use. =C2=A0This available spectr= um is called
=C2=A0 =C2=A0"White Space." =C2=A0Allowing secondary users access= to available spectrum
=C2=A0 =C2=A0"unlocks" existing spectrum to maximize its utilizat= ion and to
=C2=A0 =C2=A0provide opportunities for innovation, resulting in greater ove= rall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spectrum sharing uses databases to repo= rt
=C2=A0 =C2=A0spectrum availability to devices. =C2=A0To achieve interoperab= ility among
=C2=A0 =C2=A0multiple devices and databases, a standardized protocol must b= e
=C2=A0 =C2=A0defined and implemented. =C2=A0This document defines such a pr= otocol, the
=C2=A0 =C2=A0"Protocol to Access White Space (PAWS) Databases".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-11


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

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

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



--
-vince
--047d7b2e4c02b88c0f04f3dd84af-- From nobody Wed Mar 5 16:17:36 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7331A0010 for ; Wed, 5 Mar 2014 16:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbIIwd6xnHMf for ; Wed, 5 Mar 2014 16:17:29 -0800 (PST) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7833D1A001A for ; Wed, 5 Mar 2014 16:17:29 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so1771353qac.41 for ; Wed, 05 Mar 2014 16:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+AN04EoWHFTPacd/IqozRW2UYgejhXe5JiTZPZHtMEU=; b=OHLX4qfNyAwebhngT5nloww8giGs33iOS29z6mRQFhWSBrLfTb9L1aq/Gi1jJ3QKd9 KWfuwIRv5AtKJJDJv6zmCwpNGyMJB8kRw7PlyzqvTzbBNBljf5OPr0pAT5L0UcBXLOWF U59GHVnHtbEtDSFE+2l8nHymQbv4XEaQJrbxf/n+yCdMq17P+USzso0eim6HDXWWGxiD j74RGGZSauvVRheiM/o3HdI2+ODWUyWbSPqVIFnI/KJ86Jgg4XHm/aurY5yaCHabY2Ko v813+gf3GuUqGRRANU7NdmVBqRLm2eL1n4xPpDk/QRMwqE8TxqC3VIpu/A7hc75IyPvv U8PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+AN04EoWHFTPacd/IqozRW2UYgejhXe5JiTZPZHtMEU=; b=FaVrcNgdp2ukV4DgWFT+861qJRzeaEvej+1/Pm3153ijy4zesYpMfeletidGo28hjx Ygmn2hVw6mSHKpEbaysgxAiN8wXGLIskU+C/S98Hbitt1dH+cEuezlH/6GeUC5e/hoM9 vuobD5nwZjcUxjcg15mrfLBziMt/zX1abCvSZ4een9CcEczXzU/fZqcon9RFmPZYMmKw mnbIRftv12uDmqQGSbPYIGLbzQW8Z9TmoGigdJ8J1bHQoE4lXe94gwQcaDlSWHAZP+lT nZtMcZUEBMM3rkpauKVsfxZM7c6Jm3f+F2oPh9jJ2revhCyF06DdlgqbjHN9OVtAXbdo DF9A== X-Gm-Message-State: ALoCoQmJS+6D64fQvMFKKdAK4HQn/h//6ccWF3EJoTqkIL/KWmRmeYqQZR0M1HKYvYWEtecFleHOw53PY57rm1vpf5+Bou7mcvxwo9/V6pYo4etFBHjKNg9jYPzbWqOk4fdRoDnHDYGLP0SlMvvYAAQt21uMEoj05B9bjaVGe6GX3Zo920OLPAsxbT00DNBlw0hxluQozNwp MIME-Version: 1.0 X-Received: by 10.140.31.247 with SMTP id f110mr9844133qgf.58.1394065045609; Wed, 05 Mar 2014 16:17:25 -0800 (PST) Received: by 10.229.97.1 with HTTP; Wed, 5 Mar 2014 16:17:25 -0800 (PST) In-Reply-To: References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> Date: Wed, 5 Mar 2014 16:17:25 -0800 Message-ID: From: Andy Lee To: Vincent Chen Content-Type: multipart/alternative; boundary=001a113a9c02d6779a04f3e50f4e Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ilFAKPS-KMGq4n-x7AnzdkkaxTQ Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 00:17:34 -0000 --001a113a9c02d6779a04f3e50f4e Content-Type: text/plain; charset=UTF-8 I have a question about the new parameter etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is provided, the Device MUST NOT ignore it." I can understand that if this parameter is provided and is set to "1", that the device must honor it (reduce output power when using multiple channels). But what if there is a device that "hard coded" to always apply the power restriction when using multiple channels? This "conservative" approach would always remain below the permitted emission limits regardless of whether this flag is set to "1" or "0". Are we saying that if this parameter is provided and is set to "0" that the device must not apply the multi-channel power restrictions? What does it mean to say "MUST NOT ignore it" in such a case. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen wrote: > PAWS, > > Draft 11 contains the following changes: > - Separation of protocol and regulatory requirements. In essence, MAY, > MUST , SHOULD has been replaced where the text describes regulatory > requirements and device behavior. They are replaced with just explanatory > text. > > - Added the new ETSI parameter for simultaneous channel-operation > restrictions > > Diff: > http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11 > > -vince > > > On Wed, Mar 5, 2014 at 7:09 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Protocol to Access WS database Working >> Group of the IETF. >> >> Title : Protocol to Access White-Space (PAWS) Databases >> Authors : Vincent Chen >> Subir Das >> Lei Zhu >> John Malyar >> Peter J. McCann >> Filename : draft-ietf-paws-protocol-11.txt >> Pages : 108 >> Date : 2014-03-05 >> >> Abstract: >> Portions of the radio spectrum that are allocated to licensees are >> available for non-interfering use. This available spectrum is called >> "White Space." Allowing secondary users access to available spectrum >> "unlocks" existing spectrum to maximize its utilization and to >> provide opportunities for innovation, resulting in greater overall >> spectrum utilization. >> >> One approach to manage spectrum sharing uses databases to report >> spectrum availability to devices. To achieve interoperability among >> multiple devices and databases, a standardized protocol must be >> defined and implemented. This document defines such a protocol, the >> "Protocol to Access White Space (PAWS) Databases". >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-paws-protocol-11 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> > > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --001a113a9c02d6779a04f3e50f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a question about the new parameter etsiEnSimultaneo= usChannelOperationRestriction and the phrase "If it=C2=A0is provided, = the Device MUST NOT ignore it."

I can understand th= at if this parameter is provided and is set to "1", that the devi= ce must honor it (reduce output power when using multiple channels).

But what if there is a device that "hard coded&quo= t; to always apply the power restriction when using multiple channels? =C2= =A0This "conservative" approach would always remain below the per= mitted emission limits regardless of whether this flag is set to "1&qu= ot; or "0".

Are we saying that if this parameter is provided and is= set to "0" that the device must not apply the multi-channel powe= r restrictions? =C2=A0What does it mean to say "MUST NOT ignore it&quo= t; in such a case.





=
Andy Lee=C2=A0|=C2=A0Goog= le Inc. | =C2=A0tvfool@google.com=C2=A0| =C2=A0408-230-0522


On Wed, Mar 5, 2014 at 7:17 AM, Vincent = Chen <vchen@google.com> wrote:
PAWS,

Draft 11 contains the following c= hanges:
=C2=A0- Separation of protocol and regulatory requirement= s. In essence, MAY, MUST , SHOULD has been replaced where the text describe= s regulatory requirements and device behavior. They are replaced with just = explanatory text.

=C2=A0- Added the new ETSI parameter for simultaneous c= hannel-operation restrictions


-vince


On Wed, Mar 5, 2014 at 7:09= AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Protocol to Access WS database Worki= ng Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Prot= ocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vincent C= hen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 108<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spectrum that are allocated to licensees= are
=C2=A0 =C2=A0available for non-interfering use. =C2=A0This available spectr= um is called
=C2=A0 =C2=A0"White Space." =C2=A0Allowing secondary users access= to available spectrum
=C2=A0 =C2=A0"unlocks" existing spectrum to maximize its utilizat= ion and to
=C2=A0 =C2=A0provide opportunities for innovation, resulting in greater ove= rall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spectrum sharing uses databases to repo= rt
=C2=A0 =C2=A0spectrum availability to devices. =C2=A0To achieve interoperab= ility among
=C2=A0 =C2=A0multiple devices and databases, a standardized protocol must b= e
=C2=A0 =C2=A0defined and implemented. =C2=A0This document defines such a pr= otocol, the
=C2=A0 =C2=A0"Protocol to Access White Space (PAWS) Databases".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-11


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

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

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



--
-vince

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


--001a113a9c02d6779a04f3e50f4e-- From nobody Wed Mar 5 18:35:09 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047B71A007A for ; Wed, 5 Mar 2014 18:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo-iSO90Wwsr for ; Wed, 5 Mar 2014 18:35:00 -0800 (PST) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5841A0056 for ; Wed, 5 Mar 2014 18:35:00 -0800 (PST) Received: from BLU0-SMTP299 ([65.55.116.72]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Mar 2014 18:34:56 -0800 X-TMN: [EqWGzA+o7/swYoZGgWXNMprpGR3/76gOzp4VDkT1wU4=] X-Originating-Email: [ben@blindcreek.com] Message-ID: Received: from [127.0.0.1] ([162.251.185.174]) by BLU0-SMTP299.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Mar 2014 18:34:55 -0800 Date: Wed, 5 Mar 2014 18:34:53 -0800 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: paws@ietf.org References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040301080209090201030701" X-OriginalArrivalTime: 06 Mar 2014 02:34:55.0547 (UTC) FILETIME=[A8F6A8B0:01CF38E4] Sender: Archived-At: http://mailarchive.ietf.org/arch/msg/paws/bC07bZ-D8YZ1sgyJfBRPzqM-OJc Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 02:35:03 -0000 --------------040301080209090201030701 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I too was struggling with this wording. "Must not" is often problematic for me, and I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable behavior, such as the case Andy sites or the case where the value is zero. The logic should be: If (etsiEnSimultaneousChannelOperationRestriction == 0) Do what you were going to do anyway; else if (etsiEnSimultaneousChannelOperationRestriction == 1) Do not exceed the lower limit; The first condition looks to me pretty much the definition of "ignore" (based on my experience as a parent :-). Only the second condition can produce an observable change in the devices behavior. So if I have figured it out correctly the requirement being stated is: If the etsiEnSimultaneousChannelOperationRestriction paramter is provided and the value is 1, the Device MUST comply with the additional power restrictions when simultaneous transmission on multiple channel operation defined in [reference]. Is that right? -Ben On 3/5/2014 4:17 PM, Andy Lee wrote: > I have a question about the new parameter > etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is > provided, the Device MUST NOT ignore it." > > I can understand that if this parameter is provided and is set to "1", > that the device must honor it (reduce output power when using multiple > channels). > > But what if there is a device that "hard coded" to always apply the > power restriction when using multiple channels? This "conservative" > approach would always remain below the permitted emission limits > regardless of whether this flag is set to "1" or "0". > > Are we saying that if this parameter is provided and is set to "0" > that the device must not apply the multi-channel power restrictions? > What does it mean to say "MUST NOT ignore it" in such a case. > > > > > > Andy Lee | Google Inc. | tvfool@google.com > | 408-230-0522 > > > > On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen > wrote: > > PAWS, > > Draft 11 contains the following changes: > - Separation of protocol and regulatory requirements. In essence, > MAY, MUST , SHOULD has been replaced where the text describes > regulatory requirements and device behavior. They are replaced > with just explanatory text. > > - Added the new ETSI parameter for simultaneous channel-operation > restrictions > > Diff: > http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11 > > -vince > > > On Wed, Mar 5, 2014 at 7:09 AM, > wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Protocol to Access WS > database Working Group of the IETF. > > Title : Protocol to Access White-Space > (PAWS) Databases > Authors : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-11.txt > Pages : 108 > Date : 2014-03-05 > > Abstract: > Portions of the radio spectrum that are allocated to > licensees are > available for non-interfering use. This available spectrum > is called > "White Space." Allowing secondary users access to > available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater > overall > spectrum utilization. > > One approach to manage spectrum sharing uses databases to > report > spectrum availability to devices. To achieve > interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a > protocol, the > "Protocol to Access White Space (PAWS) Databases". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > -- > -vince > > _______________________________________________ > 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 --------------040301080209090201030701 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I too was struggling with this wording.  "Must not" is often problematic for me, and I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable behavior, such as the case Andy sites or the case where the value is zero. The logic should be:

If (etsiEnSimultaneousChannelOperationRestriction == 0)
   Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction == 1)
   Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore" (based on my experience as a parent :-).  Only the second condition can produce an observable change in the devices behavior. So if I have figured it out correctly the requirement being stated  is:

If the etsiEnSimultaneousChannelOperationRestriction  paramter is provided and the value is 1,  the Device MUST comply with the additional power restrictions when simultaneous transmission on multiple channel operation defined in [reference].

Is that right?

-Ben
On 3/5/2014 4:17 PM, Andy Lee wrote:
I have a question about the new parameter etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is provided, the Device MUST NOT ignore it."

I can understand that if this parameter is provided and is set to "1", that the device must honor it (reduce output power when using multiple channels).

But what if there is a device that "hard coded" to always apply the power restriction when using multiple channels?  This "conservative" approach would always remain below the permitted emission limits regardless of whether this flag is set to "1" or "0".

Are we saying that if this parameter is provided and is set to "0" that the device must not apply the multi-channel power restrictions?  What does it mean to say "MUST NOT ignore it" in such a case.





Andy Lee |  Google Inc. |  tvfool@google.com |  408-230-0522


On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com> wrote:
PAWS,

Draft 11 contains the following changes:
 - Separation of protocol and regulatory requirements. In essence, MAY, MUST , SHOULD has been replaced where the text describes regulatory requirements and device behavior. They are replaced with just explanatory text.

 - Added the new ETSI parameter for simultaneous channel-operation restrictions


-vince


On Wed, Mar 5, 2014 at 7:09 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

        Title           : Protocol to Access White-Space (PAWS) Databases
        Authors         : Vincent Chen
                          Subir Das
                          Lei Zhu
                          John Malyar
                          Peter J. McCann
        Filename        : draft-ietf-paws-protocol-11.txt
        Pages           : 108
        Date            : 2014-03-05

Abstract:
   Portions of the radio spectrum that are allocated to licensees are
   available for non-interfering use.  This available spectrum is called
   "White Space."  Allowing secondary users access to available spectrum
   "unlocks" existing spectrum to maximize its utilization and to
   provide opportunities for innovation, resulting in greater overall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to report
   spectrum availability to devices.  To achieve interoperability among
   multiple devices and databases, a standardized protocol must be
   defined and implemented.  This document defines such a protocol, the
   "Protocol to Access White Space (PAWS) Databases".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11


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

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

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



--
-vince

_______________________________________________
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

--------------040301080209090201030701-- From nobody Wed Mar 5 18:50:53 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839391A0021 for ; Wed, 5 Mar 2014 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpodchxRAHQ1 for ; Wed, 5 Mar 2014 18:50:49 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 01D551A0071 for ; Wed, 5 Mar 2014 18:50:48 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id uz6so1963334obc.1 for ; Wed, 05 Mar 2014 18:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z817GW5cON8H5xAdmSvRTKalNLPZ8XmjhE1KEN/eGUE=; b=h4v0eE0B+itzxfoTJOMF+7Ow/1C9TsU+MVp6prVpbeEeIkEd/tXzdtPIUXoClkHjPs Ekhba7JUVZzCsPh16Twr9ljHxLY3MoVJTCuHg0AYfQ5cAk0HtvuZyum3WEwTJI/IgYn8 Rq6yyj5/JqBmajzZDo2SrB91TjBtxyCEoYjjc5sov8gzemn7mQ6i6z/o7aGnXNe74Yr0 HaCnsSoWc3LFaNRPdXyAedNfxZkP4rShMJt340YeBKG6dkUt+FSZl80jJXCo8e1hE9MJ cF6InzztNbzUhN5/t7XLnIQ7chbVnmdRkrx/IvA4ltSi3W/K4I7aJY2g9AXUkufcna+J gk7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z817GW5cON8H5xAdmSvRTKalNLPZ8XmjhE1KEN/eGUE=; b=nAgwvEeyGHat4BrmaB20bCk/zpsjhWUBdBHySasqV5a8d5xZE1VqcCZoMJreSYW/tw RWqfbfty9xnhoJr1uRcx35aGodkty6ITJ4F+oeindUAJsVBficiHQUyA2FcI+rh0AXWo g++p4yNjGsRzgaPx4FiyKC3JRaUWojIBOKlrBWouqDFg+PkuRT48mT4/XLxiQ3nxdeTw XwQm3YwRZ+Ri/3CrUxueYO+LSlwDkjCXmg4jOodnURjIDfWnXWzR2nerxxzRl4MBCB94 ZPS5sC4aKqWWdkcVuBq6t60lZHWF+YN61xNKu6A3AaraLeo6AcFTuHES4vs9valGJFCc ljCw== X-Gm-Message-State: ALoCoQm16jHPvKBRe+8cSRHupW8KJl1d2iDr1YF710+liV6v+zcu9kwggWEaanJoPULNa5o0dZfCX7Tuhq7Yf8NsuuBfhG4r0iHkfn3YlNuM7xgO6QgM4BORS4LKRe8baEee8GorZvhJInqyjTOhWmOqKum4a2LCC7xC1H7QMRlu9dP5a59utNhWBqilybibJhvyAq6EhbOK MIME-Version: 1.0 X-Received: by 10.60.62.146 with SMTP id y18mr3476055oer.24.1394074245127; Wed, 05 Mar 2014 18:50:45 -0800 (PST) Received: by 10.182.45.166 with HTTP; Wed, 5 Mar 2014 18:50:45 -0800 (PST) In-Reply-To: References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> Date: Wed, 5 Mar 2014 18:50:45 -0800 Message-ID: From: Vincent Chen To: "Benjamin A. Rolfe" Content-Type: multipart/alternative; boundary=047d7b6769e82bfcb904f3e73486 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/ZFpGtws8QT2nSg3SUQQxClTAnpg Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 02:50:52 -0000 --047d7b6769e82bfcb904f3e73486 Content-Type: text/plain; charset=UTF-8 Ben, Andy, >From what I understood, the request is to add a parameter to the protocol with numeric string values, with a default value of "0". It does not limit the valid values to "0" or "1", and does not associate meaning to the values. The device behavior, upon receipt of the value, is defined by the ETSI specs, not the protocol doc. The "MUST NOT ignore" is intended to indicate that the device must understand the value, if present. The risk of not processing the value is that, if ETSI were to add another value that is more restrictive, the hard-coded device would be out of compliance. I believe the intent is to prevent hard-coding in devices. -vince On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe wrote: > I too was struggling with this wording. "Must not" is often problematic > for me, and I was struggling to figure out how we verify that device has > not ignored a parameter when the value of the paramter has a value that > produces no observable behavior, such as the case Andy sites or the case > where the value is zero. The logic should be: > > If (etsiEnSimultaneousChannelOperationRestriction == 0) > Do what you were going to do anyway; > else if (etsiEnSimultaneousChannelOperationRestriction == 1) > Do not exceed the lower limit; > > The first condition looks to me pretty much the definition of "ignore" > (based on my experience as a parent :-). Only the second condition can > produce an observable change in the devices behavior. So if I have figured > it out correctly the requirement being stated is: > > If the etsiEnSimultaneousChannelOperationRestriction paramter is > provided and the value is 1, the Device MUST comply with the additional > power restrictions when simultaneous transmission on multiple channel > operation defined in [reference]. > > Is that right? > > -Ben > > On 3/5/2014 4:17 PM, Andy Lee wrote: > > I have a question about the new parameter > etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is > provided, the Device MUST NOT ignore it." > > I can understand that if this parameter is provided and is set to "1", > that the device must honor it (reduce output power when using multiple > channels). > > But what if there is a device that "hard coded" to always apply the > power restriction when using multiple channels? This "conservative" > approach would always remain below the permitted emission limits regardless > of whether this flag is set to "1" or "0". > > Are we saying that if this parameter is provided and is set to "0" that > the device must not apply the multi-channel power restrictions? What does > it mean to say "MUST NOT ignore it" in such a case. > > > > > > Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 > > > On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen wrote: > >> PAWS, >> >> Draft 11 contains the following changes: >> - Separation of protocol and regulatory requirements. In essence, MAY, >> MUST , SHOULD has been replaced where the text describes regulatory >> requirements and device behavior. They are replaced with just explanatory >> text. >> >> - Added the new ETSI parameter for simultaneous channel-operation >> restrictions >> >> Diff: >> http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11 >> >> -vince >> >> >> On Wed, Mar 5, 2014 at 7:09 AM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Protocol to Access WS database Working >>> Group of the IETF. >>> >>> Title : Protocol to Access White-Space (PAWS) Databases >>> Authors : Vincent Chen >>> Subir Das >>> Lei Zhu >>> John Malyar >>> Peter J. McCann >>> Filename : draft-ietf-paws-protocol-11.txt >>> Pages : 108 >>> Date : 2014-03-05 >>> >>> Abstract: >>> Portions of the radio spectrum that are allocated to licensees are >>> available for non-interfering use. This available spectrum is called >>> "White Space." Allowing secondary users access to available spectrum >>> "unlocks" existing spectrum to maximize its utilization and to >>> provide opportunities for innovation, resulting in greater overall >>> spectrum utilization. >>> >>> One approach to manage spectrum sharing uses databases to report >>> spectrum availability to devices. To achieve interoperability among >>> multiple devices and databases, a standardized protocol must be >>> defined and implemented. This document defines such a protocol, the >>> "Protocol to Access White Space (PAWS) Databases". >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-paws-protocol-11 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >> >> >> >> -- >> -vince >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > _______________________________________________ > paws mailing listpaws@ietf.orghttps://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --047d7b6769e82bfcb904f3e73486 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben, Andy,

From what I understood, the = request is to add a parameter to the protocol with
numeric string= values, with a default value of "0". It does not limit the valid= values
to "0" or "1", and does not associate meaning to t= he values. The device behavior,=C2=A0
upon receipt of the value, = is defined by the ETSI specs, not the protocol doc.

The "MUST NOT ignore" is intended to indicate that the device mus= t understand
the value, if present. The risk of not processing th= e value is that, if ETSI were to add
another value that is more r= estrictive, the hard-coded device would be out of
compliance.

I believe the intent is to preven= t hard-coding in devices.

-vince


On Wed, Mar 5, 2014= at 6:34 PM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:<= br>
=20 =20 =20
I too was struggling with this wording.=C2=A0 "Must not" is often p= roblematic for me, and I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable behavior, such as the case Andy sites or the case where the value is zero. The logic should be:

If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0)=
=C2=A0=C2=A0 Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1)
=C2=A0=C2=A0 Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore" (based on my experience as a parent :-).=C2=A0 O= nly the second condition can produce an observable change in the devices behavior. So if I have figured it out correctly the requirement being stated=C2=A0 is:

If the etsiEnSimultaneousChannelOperationRestriction=C2= =A0 paramter is provided and the value is 1,=C2=A0 the Device MUST comp= ly with the additional power restrictions when simultaneous transmission on multiple channel operation defined in [reference].

Is that right?

-Ben

On 3/5/2014 4:17 PM, Andy Lee wrote:
I have a question about the new parameter etsiEnSimultaneousChannelOperationRestriction and the phrase "= If it=C2=A0is provided, the Device MUST NOT ignore it."

I can understand that if this parameter is provided and is set to "1", that the device must honor it (reduce outpu= t power when using multiple channels).

But what if there is a device that "hard coded" to a= lways apply the power restriction when using multiple channels? =C2=A0This "conservative" approach would always remain = below the permitted emission limits regardless of whether this flag is set to "1" or "0".

Are we saying that if this parameter is provided and is set to "0" that the device must not apply the multi-channel= power restrictions? =C2=A0What does it mean to say "MUST NOT ignor= e it" in such a case.





Andy Lee=C2=A0| =C2=A0Google Inc. | =C2=A0tvfool@google.com=C2=A0| =C2=A0408-230-0522


On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com> wrote:
PAWS,

Draft 11 contains the following changes:
=C2=A0- Separation of protocol and regulatory requirements. In essence, MAY, MUST , SHOULD has been replaced where the text describes regulatory requirements and device behavior. They are replaced with just explanatory text.

=C2=A0- Added the new ETSI parameter for simultaneous channel-operation restrictions


-vince


On Wed, Mar 5, 2014 at 7:09 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
=C2=A0This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : Protocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Vincent Chen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 = =C2=A0 =C2=A0: draft-ietf-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 : 108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0: 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spectrum that are allocated to licensees are
=C2=A0 =C2=A0available for non-interfering use. =C2= =A0This available spectrum is called
=C2=A0 =C2=A0"White Space." =C2=A0Allowing = secondary users access to available spectrum
=C2=A0 =C2=A0"unlocks" existing spectrum to= maximize its utilization and to
=C2=A0 =C2=A0provide opportunities for innovation, re= sulting in greater overall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spectrum sharing = uses databases to report
=C2=A0 =C2=A0spectrum availability to devices. =C2=A0= To achieve interoperability among
=C2=A0 =C2=A0multiple devices and databases, a standa= rdized protocol must be
=C2=A0 =C2=A0defined and implemented. =C2=A0This docu= ment defines such a protocol, the
=C2=A0 =C2=A0"Protocol to Access White Space (PA= WS) Databases".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-= protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3D= draft-ietf-paws-protocol-11


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

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

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



--
-vince

_______________________________________________
paws mailing list
paws@ietf.or= g
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




--
-vince
--047d7b6769e82bfcb904f3e73486-- From nobody Wed Mar 5 19:26:23 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85561A007D for ; Wed, 5 Mar 2014 19:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqbJHBdEJA9a for ; Wed, 5 Mar 2014 19:26:18 -0800 (PST) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 145F31A003D for ; Wed, 5 Mar 2014 19:26:18 -0800 (PST) Received: from BLU0-SMTP245 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Mar 2014 19:26:13 -0800 X-TMN: [cKwkyxkn8jKnUP97aHUn8Pse2qDGYnAuAibXJyX1kQg=] X-Originating-Email: [ben@blindcreek.com] Message-ID: Received: from [127.0.0.1] ([162.251.185.174]) by BLU0-SMTP245.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Mar 2014 19:26:12 -0800 Date: Wed, 5 Mar 2014 19:26:10 -0800 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: "paws@ietf.org" References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090503050401070809000001" X-OriginalArrivalTime: 06 Mar 2014 03:26:12.0562 (UTC) FILETIME=[D301E320:01CF38EB] Sender: Archived-At: http://mailarchive.ietf.org/arch/msg/paws/F-hgWk21X1_9P6NCrHyjIPO9rqU Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 03:26:21 -0000 --------------090503050401070809000001 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Thanks Vincent. I was attempting to capture what you just explained. I think that is what I captured - reference the ETSI spec for what to do when the value is not zero. I had guessed that the intent of adding this param was to provide a way to signal that an additional constraint is applied to the channels being used. On 3/5/2014 6:50 PM, Vincent Chen wrote: > Ben, Andy, > > From what I understood, the request is to add a parameter to the > protocol with > numeric string values, with a default value of "0". It does not limit > the valid values > to "0" or "1", and does not associate meaning to the values. The > device behavior, > upon receipt of the value, is defined by the ETSI specs, not the > protocol doc. > > The "MUST NOT ignore" is intended to indicate that the device must > understand > the value, if present. The risk of not processing the value is that, > if ETSI were to add > another value that is more restrictive, the hard-coded device would be > out of > compliance. > > I believe the intent is to prevent hard-coding in devices. > > -vince > > > On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe > wrote: > > I too was struggling with this wording. "Must not" is often > problematic for me, and I was struggling to figure out how we > verify that device has not ignored a parameter when the value of > the paramter has a value that produces no observable behavior, > such as the case Andy sites or the case where the value is zero. > The logic should be: > > If (etsiEnSimultaneousChannelOperationRestriction == 0) > Do what you were going to do anyway; > else if (etsiEnSimultaneousChannelOperationRestriction == 1) > Do not exceed the lower limit; > > The first condition looks to me pretty much the definition of > "ignore" (based on my experience as a parent :-). Only the second > condition can produce an observable change in the devices > behavior. So if I have figured it out correctly the requirement > being stated is: > > If the etsiEnSimultaneousChannelOperationRestriction paramter is > provided and the value is 1, the Device MUST comply with the > additional power restrictions when simultaneous transmission on > multiple channel operation defined in [reference]. > > Is that right? > > -Ben > > On 3/5/2014 4:17 PM, Andy Lee wrote: >> I have a question about the new parameter >> etsiEnSimultaneousChannelOperationRestriction and the phrase "If >> it is provided, the Device MUST NOT ignore it." >> >> I can understand that if this parameter is provided and is set to >> "1", that the device must honor it (reduce output power when >> using multiple channels). >> >> But what if there is a device that "hard coded" to always apply >> the power restriction when using multiple channels? This >> "conservative" approach would always remain below the permitted >> emission limits regardless of whether this flag is set to "1" or "0". >> >> Are we saying that if this parameter is provided and is set to >> "0" that the device must not apply the multi-channel power >> restrictions? What does it mean to say "MUST NOT ignore it" in >> such a case. >> >> >> >> >> >> Andy Lee | Google Inc. | tvfool@google.com >> | 408-230-0522 >> >> >> >> On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen > > wrote: >> >> PAWS, >> >> Draft 11 contains the following changes: >> - Separation of protocol and regulatory requirements. In >> essence, MAY, MUST , SHOULD has been replaced where the text >> describes regulatory requirements and device behavior. They >> are replaced with just explanatory text. >> >> - Added the new ETSI parameter for simultaneous >> channel-operation restrictions >> >> Diff: >> http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11 >> >> -vince >> >> >> On Wed, Mar 5, 2014 at 7:09 AM, > > wrote: >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> This draft is a work item of the Protocol to Access WS >> database Working Group of the IETF. >> >> Title : Protocol to Access White-Space >> (PAWS) Databases >> Authors : Vincent Chen >> Subir Das >> Lei Zhu >> John Malyar >> Peter J. McCann >> Filename : draft-ietf-paws-protocol-11.txt >> Pages : 108 >> Date : 2014-03-05 >> >> Abstract: >> Portions of the radio spectrum that are allocated to >> licensees are >> available for non-interfering use. This available >> spectrum is called >> "White Space." Allowing secondary users access to >> available spectrum >> "unlocks" existing spectrum to maximize its >> utilization and to >> provide opportunities for innovation, resulting in >> greater overall >> spectrum utilization. >> >> One approach to manage spectrum sharing uses databases >> to report >> spectrum availability to devices. To achieve >> interoperability among >> multiple devices and databases, a standardized >> protocol must be >> defined and implemented. This document defines such a >> protocol, the >> "Protocol to Access White Space (PAWS) Databases". >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-paws-protocol-11 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 >> >> >> Please note that it may take a couple of minutes from the >> time of submission >> until the htmlized version and diff are available at >> tools.ietf.org . >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> >> -- >> -vince >> >> _______________________________________________ >> 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 > > > > > -- > -vince --------------090503050401070809000001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank= s Vincent.=C2=A0

I was attempting to capture what you just explained. I think that is what I captured - reference the ETSI spec for what to do when the value is not zero.
I had guessed that the intent of adding this param was to provide a way to signal that an additional constraint is applied to the channels being used.
On 3/5/2014 6:50 PM=2C Vincent Chen wrote:
Ben=2C Andy=2C

From what I understood=2C the request is to add a parameter to the protocol with
numeric string values=2C with a default value of "0". It does not limit the valid values
to "0" or "1"=2C and does not associate meaning to the values. The device behavior=2C=C2=A0
upon receipt of the value=2C is defined by the ETSI specs=2C not the protocol doc.

The "MUST NOT ignore" is intended to indicate that the device must understand
the value=2C if present. The risk of not processing the value is that=2C if ETSI were to add
another value that is more restrictive=2C the hard-coded device would be out of
compliance.

I believe the intent is to prevent hard-coding in devices.

-vince


On Wed=2C Mar 5=2C 2014 at 6:34 PM=2C Benjamin A. Rolfe <=3Bben@blindcreek.com>=3B wrote:<= br>
I too was struggling with this wording.=C2=A0 "Must not" is often problematic for me=2C and I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable behavior=2C such as the case Andy sites or the case where the value is zero. The logic should be:

If (etsiEnSimultane= ousChannelOperationRestriction =3D=3D 0)
=C2=A0=C2=A0 Do what you were going to do anyway=3B
else if (etsiEnSimultane= ousChannelOperationRestriction =3D=3D 1)
=C2=A0=C2=A0 Do not exceed the lower limit=3B

The first condition looks to me pretty much the definition of "ignore" (based on my experience as a parent :-).=C2=A0 Only the second condition can produce a= n observable change in the devices behavior. So if I have figured it out correctly the requirement being stated=C2=A0 is:

If the etsiEnSimultane= ousChannelOperationRestriction=C2=A0 paramter is provided and the value is 1=2C=C2=A0 the Devi= ce MUST comply with the additional power restrictions when simultaneous transmission on multiple channel operation defined in [reference].

Is that right?

-Ben
On 3/5/2014 4:17 PM=2C Andy Lee wrote:
I have a question about the new parameter etsiEnSimultaneousChannelOperationRestriction and the phrase "If it=C2=A0is provided=2C the Device MUST= NOT ignore it."

I can understand that if this parameter is provided and is set to "1"=2C that the device must honor it (reduce output power when using multiple channels).

But what if there is a device that "hard coded" to always apply the power restriction when using multiple channels? =C2=A0This "conservative" approach would always remain below the permitted emission limits regardless of whether this flag is set to "1" or "0".

Are we saying that if this parameter is provided and is set to "0" that the device must not apply the multi-channel power restrictions? =C2=A0What does it mean to say "MUST NOT ignore it" in such a case.





Andy Lee=C2=A0| =C2=A0Google Inc. | =C2=A0tvfool@google.com= =C2=A0| =C2=A0408-230-0522


On Wed=2C Mar 5=2C 2014 at 7:17 AM=2C Vincent Chen <=3Bvchen@google.com>=3B wrote:
PAWS=2C

Draft 11 contains the following changes:
=C2=A0- Separation of protocol and regulatory requirements. In essence=2C MAY=2C MUST =2C SHOULD has been replaced where the text describes regulatory requirements and device behavior. They are replaced with just explanatory text.

=C2=A0- Added the new ETSI parameter for simultaneous channel-operation restrictions


-vince


On Wed=2C Mar 5= =2C 2014 at 7:09 AM=2C <= =3Binternet-drafts@iet= f.org>=3B wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
=C2=A0This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Protocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : Vincent Chen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename = =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spec= trum that are allocated to licensees are
=C2=A0 =C2=A0available for non-interfer= ing use. =C2=A0This available spectrum is called
=C2=A0 =C2=A0"White Space." =C2=A0Allow= ing secondary users access to available spectrum
=C2=A0 =C2=A0"unlocks" existing spectru= m to maximize its utilization and to
=C2=A0 =C2=A0provide opportunities for innovation=2C resulting in greater overall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spe= ctrum sharing uses databases to report
=C2=A0 =C2=A0spectrum availability to d= evices. =C2=A0To achieve interoperability among=
=C2=A0 =C2=A0multiple devices and datab= ases=2C a standardized protocol must be
=C2=A0 =C2=A0defined and implemented. = =C2=A0This document defines such a protocol=2C the
=C2=A0 =C2=A0"Protocol to Access White = Space (PAWS) Databases".


The IETF datatracker status page for this draft is:
https://datatracker= .ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.o= rg/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-paws-protocol-11


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

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

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



--
-vince

_______________________________________________
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<= /a>




--
-vince

--------------090503050401070809000001-- From nobody Wed Mar 5 21:18:50 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33521A00B6 for ; Wed, 5 Mar 2014 21:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4btdMIK8B2T for ; Wed, 5 Mar 2014 21:18:43 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 3D43E1A00B0 for ; Wed, 5 Mar 2014 21:18:43 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id j5so5834637qga.4 for ; Wed, 05 Mar 2014 21:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JpZmF5k8RuTMcdIhI4u0m5SmEtxZ0bDHmrORtfwSCDE=; b=O9rpgcD9/7Rg8HT7NfZx263l9kL0eXTtJhXJG+25m9xFFjrSIH4ljIMBOiuCUv1HqE QP743S7IP1NUt/Fde15uR0YMuVwN9+1aaO1ZP6yk3Q6MxFwcujhSJvn7j63m7odTzzIr +0k6EzXsgx+IFIpUykyTJQGWnYxQtREI+IFTloTpmBd1LDRy1H83yCyaIgrfqEvdQmhf SrOQZjnVjMd8hpngJeoRZGhmjnlChXU2t3lleJ1+4tOUhJ0lsXI2HYmVXMl3sQyS2zP+ JEP3XcyZ+uDGx/VcBeMsd++0xr7+2S9WUyFW/TEzlZ9rX2OC0EpfhWRdK8P7QDouq/ga IU3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JpZmF5k8RuTMcdIhI4u0m5SmEtxZ0bDHmrORtfwSCDE=; b=C01WXGcJmJoGaCQJMCmMBo827cZPDSOlpz382cAuSwUs1nl+9hlVf1UaErlbDUV5+p v+Mu3w8JljF5K3Rc8NPLLpo+NKnI7vd9hu/btQ5vFt6B6kFYKGRzPaGeTprQ0i3GLUZK naVB17RNAcRKAFjqQqI0aBg08oERtOILTTzxEHHhDu+lvQVS4b2RZ8LtW5ebwZ14I72y NgrxhHlqOVNhqXE1z0pXA2s3N3EGjZwy+Xso2y5zcGnuEsd27Z4vhlK/5MEJg5HwHVBm yoiKKimJs1FiF0VQIh1b1nHIwvO+BqP67MrQDFQm20nQEjXt6qtJQSnQ7ySg7OmDj3uT 3tMg== X-Gm-Message-State: ALoCoQkYxVTvj11BTY7+fNcbJBXy8hcc2b24lP4GaZTNMmzdVqIz1Mpb5Zv1U1JZ0h6pj/XhYztKpKuBsS/MMaq8uU8XzWxM9OhyJ7nwih+Ap+qhRF6d/tsGI1vMYdflJEaPU+dkP7ilsxpLAlwmk1U7WxIsqK3y0Q0CIw8qzLGvPx5U3tq6yLA1GM+vLzGFCCz+S3+phtup MIME-Version: 1.0 X-Received: by 10.140.96.180 with SMTP id k49mr11035054qge.4.1394083119053; Wed, 05 Mar 2014 21:18:39 -0800 (PST) Received: by 10.229.97.1 with HTTP; Wed, 5 Mar 2014 21:18:38 -0800 (PST) In-Reply-To: References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> Date: Wed, 5 Mar 2014 21:18:38 -0800 Message-ID: From: Andy Lee To: "Benjamin A. Rolfe" Content-Type: multipart/alternative; boundary=001a113ac3d019521504f3e9458e Archived-At: http://mailarchive.ietf.org/arch/msg/paws/Fx2e5yfgJ5lB0WEdOB-GoWpyMG0 Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 05:18:47 -0000 --001a113ac3d019521504f3e9458e Content-Type: text/plain; charset=UTF-8 Thank you both for the additional clarifications. I think this is getting out-of-scope for the PAWS standard, but there is no future-proofing guidance here either. If a device built today knows what to do when etsiEnSimultaneousChannelOperationRestriction="0" and when etsiEnSimultaneousChannelOperationRestriction="1", what should it do when a database sends a value it doesn't recognize in the future? The spec is clear about what to do when the parameter is not sent at all, but no fallback behavior is defined for when the parameter takes on new values never seen before. This seems to be clearly out-of-scope of PAWS itself, and as Ben suggested, this should defer to the ETSI spec for details. However, this still leaves the question of what "must not ignore" means. Devices cannot process unknown future values, so how can they possibly "not ignore" a field that is unrecognizable to them? At this point, I think all we can say is that if a device encounters etsiEnSimultaneousChannelOperationRestriction="1", it must follow the ETSI power constraint rules. Any other statements about defaulting to "0" and "must not ignore" seem superfluous. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe wrote: > Thanks Vincent. > > I was attempting to capture what you just explained. I think that is what > I captured - reference the ETSI spec for what to do when the value is not > zero. > I had guessed that the intent of adding this param was to provide a way to > signal that an additional constraint is applied to the channels being used. > > > On 3/5/2014 6:50 PM, Vincent Chen wrote: > > Ben, Andy, > > From what I understood, the request is to add a parameter to the > protocol with > numeric string values, with a default value of "0". It does not limit the > valid values > to "0" or "1", and does not associate meaning to the values. The device > behavior, > upon receipt of the value, is defined by the ETSI specs, not the protocol > doc. > > The "MUST NOT ignore" is intended to indicate that the device must > understand > the value, if present. The risk of not processing the value is that, if > ETSI were to add > another value that is more restrictive, the hard-coded device would be out > of > compliance. > > I believe the intent is to prevent hard-coding in devices. > > -vince > > > On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe wrote: > >> I too was struggling with this wording. "Must not" is often >> problematic for me, and I was struggling to figure out how we verify that >> device has not ignored a parameter when the value of the paramter has a >> value that produces no observable behavior, such as the case Andy sites or >> the case where the value is zero. The logic should be: >> >> If (etsiEnSimultaneousChannelOperationRestriction == 0) >> Do what you were going to do anyway; >> else if (etsiEnSimultaneousChannelOperationRestriction == 1) >> Do not exceed the lower limit; >> >> The first condition looks to me pretty much the definition of "ignore" >> (based on my experience as a parent :-). Only the second condition can >> produce an observable change in the devices behavior. So if I have figured >> it out correctly the requirement being stated is: >> >> If the etsiEnSimultaneousChannelOperationRestriction paramter is >> provided and the value is 1, the Device MUST comply with the additional >> power restrictions when simultaneous transmission on multiple channel >> operation defined in [reference]. >> >> Is that right? >> >> -Ben >> >> On 3/5/2014 4:17 PM, Andy Lee wrote: >> >> I have a question about the new parameter >> etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is >> provided, the Device MUST NOT ignore it." >> >> I can understand that if this parameter is provided and is set to "1", >> that the device must honor it (reduce output power when using multiple >> channels). >> >> But what if there is a device that "hard coded" to always apply the >> power restriction when using multiple channels? This "conservative" >> approach would always remain below the permitted emission limits regardless >> of whether this flag is set to "1" or "0". >> >> Are we saying that if this parameter is provided and is set to "0" that >> the device must not apply the multi-channel power restrictions? What does >> it mean to say "MUST NOT ignore it" in such a case. >> >> >> >> >> >> Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 >> >> >> On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen wrote: >> >>> PAWS, >>> >>> Draft 11 contains the following changes: >>> - Separation of protocol and regulatory requirements. In essence, MAY, >>> MUST , SHOULD has been replaced where the text describes regulatory >>> requirements and device behavior. They are replaced with just explanatory >>> text. >>> >>> - Added the new ETSI parameter for simultaneous channel-operation >>> restrictions >>> >>> Diff: >>> http://www.ietf.org/rfcdiff?url1=draft-ietf-paws-protocol-10&difftype=--html&submit=Go%21&url2=draft-ietf-paws-protocol-11 >>> >>> -vince >>> >>> >>> On Wed, Mar 5, 2014 at 7:09 AM, wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Protocol to Access WS database >>>> Working Group of the IETF. >>>> >>>> Title : Protocol to Access White-Space (PAWS) >>>> Databases >>>> Authors : Vincent Chen >>>> Subir Das >>>> Lei Zhu >>>> John Malyar >>>> Peter J. McCann >>>> Filename : draft-ietf-paws-protocol-11.txt >>>> Pages : 108 >>>> Date : 2014-03-05 >>>> >>>> Abstract: >>>> Portions of the radio spectrum that are allocated to licensees are >>>> available for non-interfering use. This available spectrum is called >>>> "White Space." Allowing secondary users access to available spectrum >>>> "unlocks" existing spectrum to maximize its utilization and to >>>> provide opportunities for innovation, resulting in greater overall >>>> spectrum utilization. >>>> >>>> One approach to manage spectrum sharing uses databases to report >>>> spectrum availability to devices. To achieve interoperability among >>>> multiple devices and databases, a standardized protocol must be >>>> defined and implemented. This document defines such a protocol, the >>>> "Protocol to Access White Space (PAWS) Databases". >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-paws-protocol-11 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-11 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> >>> >>> -- >>> -vince >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >> >> >> _______________________________________________ >> paws mailing listpaws@ietf.orghttps://www.ietf.org/mailman/listinfo/paws >> >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --001a113ac3d019521504f3e9458e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you both for the additional clarifications.

I think this is getting out-of-scope for the PAWS standard= , but there is no future-proofing guidance here either. =C2=A0If a device b= uilt today knows what to do when=C2=A0etsiEnSimultaneousChannelOperationRestriction=3D"0"= ; and when=C2=A0etsiEnSimultaneousChannelOperationRestriction=3D"1", what should = it do when a database sends a value it doesn't recognize=C2=A0in the future?

The spec= is clear about what to do when the parameter is not sent at all, but no fa= llback behavior is defined for when the parameter takes on new values never= seen before. =C2=A0This seems to be clearly out-of-scope of PAWS itself, a= nd as Ben suggested, this should defer to the ETSI spec for details.=

How= ever, this still leaves the question of what "must not ignore" me= ans. =C2=A0Devices cannot process unknown future values, so how can they po= ssibly "not ignore" a field that is unrecognizable to them?

At = this point, I think all we can say is that if a device encounters=C2=A0etsiEnSimult= aneousChannelOperationRestriction=3D"1", it=C2=A0must follow the ETSI power const= raint rules. =C2=A0Any other statements about defaulting to "0" and "= ;must not ignore" seem superfluous.


Andy Lee=C2=A0|=C2=A0Google Inc. | =C2=A0tvfool@google.= com=C2=A0|=C2=A0408-230-0522


On Wed, Mar 5, 2014 at 7:26 PM, Benjamin= A. Rolfe <ben@blindcreek.com> wrote:
=20 =20 =20
Thanks Vincent.=C2=A0

I was attempting to capture what you just explained. I think that is what I captured - reference the ETSI spec for what to do when the value is not zero.
I had guessed that the intent of adding this param was to provide a way to signal that an additional constraint is applied to the channels being used.


On 3/5/2014 6:50 PM, Vincent Chen wrote:
Ben, Andy,

From what I understood, the request is to add a parameter to the protocol with
numeric string values, with a default value of "0". = It does not limit the valid values
to "0" or "1", and does not associate mean= ing to the values. The device behavior,=C2=A0
upon receipt of the value, is defined by the ETSI specs, not the protocol doc.

The "MUST NOT ignore" is intended to indicate that the = device must understand
the value, if present. The risk of not processing the value is that, if ETSI were to add
another value that is more restrictive, the hard-coded device would be out of
compliance.

I believe the intent is to prevent hard-coding in devices.

-vince


On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe <ben@blindcreek.com> wrote:
I too was struggling with this wording.=C2=A0 "Must not" = is often problematic for me, and I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable behavior, such as the case Andy sites or the case where the value is zero. The logic should be:

If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0)
=C2=A0=C2=A0 Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1)
=C2=A0=C2=A0 Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore" (based on my experience = as a parent :-).=C2=A0 Only the second condition can produce a= n observable change in the devices behavior. So if I have figured it out correctly the requirement being stated=C2=A0 is:

If the etsiEnSimultaneousChannelOperationRestriction=C2= =A0 paramter is provided and the value is 1,=C2=A0 the Device MUST comply with the additional power restrictions when simultaneous transmission on multiple channel operation defined in [reference].

Is that right?

-Ben
On 3/5/2014 4:17 PM, Andy Lee wrote:
I have a question about the new parameter etsiEnSimultaneousChannelOperationRestriction and the phrase "If it=C2=A0is provided, the Device M= UST NOT ignore it."

I can understand that if this parameter is provided and is set to "1", that the devi= ce must honor it (reduce output power when using multiple channels).

But what if there is a device that "hard coded" to always apply the power restriction when using multiple channels? =C2=A0This "conservative" approach would always rema= in below the permitted emission limits regardless of whether this flag is set to "1" or &qu= ot;0".

Are we saying that if this parameter is provided and is set to "0" that the devic= e must not apply the multi-channel power restrictions? =C2=A0What does it mean to say "MUST NOT ignor= e it" in such a case.





Andy Lee=C2=A0| =C2=A0Google Inc. |<= /td> =C2=A0tvfool@google.com=C2=A0| =C2=A0408-230-0522


On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com> wrote:
PAWS,

Draft 11 contains the following changes:
=C2=A0- Separation of protocol and regulatory requirements. In essence, MAY, MUST , SHOULD has been replaced where the text describes regulatory requirements and device behavior. They are replaced with just explanatory text.

=C2=A0- Added the new ETSI parameter for simultaneous channel-operation restrictions


-vince


On Wed, Mar 5, 2014 at 7:09 AM, <internet-drafts= @ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
=C2=A0This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Protocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2= =A0 =C2=A0 =C2=A0 =C2=A0 : Vincent Chen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename = =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-ietf-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 108
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spec= trum that are allocated to licensees are
=C2=A0 =C2=A0available for non-interfer= ing use. =C2=A0This available spectrum is called
=C2=A0 =C2=A0"White Space." = =C2=A0Allowing secondary users access to available spectrum
=C2=A0 =C2=A0"unlocks" existi= ng spectrum to maximize its utilization and to
=C2=A0 =C2=A0provide opportunities for innovation, resulting in greater overall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spe= ctrum sharing uses databases to report
=C2=A0 =C2=A0spectrum availability to d= evices. =C2=A0To achieve interoperability among=
=C2=A0 =C2=A0multiple devices and datab= ases, a standardized protocol must be
=C2=A0 =C2=A0defined and implemented. = =C2=A0This document defines such a protocol, the
=C2=A0 =C2=A0"Protocol to Access W= hite Space (PAWS) Databases".


The IETF datatracker status page for this draft is:
https://datatracker.ietf.= org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/dr= aft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/r= fcdiff?url2=3Ddraft-ietf-paws-protocol-11


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

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

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



--
-vince

_______________________________________________
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.or= g
https://www.ietf.org/mailman/listinfo/paws




--
-vince


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


--001a113ac3d019521504f3e9458e-- From nobody Thu Mar 6 02:11:30 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC01A01F5 for ; Thu, 6 Mar 2014 02:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYGE0oywWnoG for ; Thu, 6 Mar 2014 02:11:22 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E06231A019A for ; Thu, 6 Mar 2014 02:11:21 -0800 (PST) Received: from stntexhc10.cis.neustar.com (unknown [10.31.58.69]) by stihiron1.va.neustar.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 0fe6_7bbb_4bd0c7d0_86b7_47d1_853e_2f60fdbb6044; Thu, 06 Mar 2014 05:11:12 -0500 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc10.cis.neustar.com ([169.254.4.33]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 05:11:07 -0500 From: "Rosen, Brian" To: Andy Lee Thread-Topic: [paws] I-D Action: draft-ietf-paws-protocol-11.txt Thread-Index: AQHPOSRjwrqKape22E2X6bCr+crCmw== Date: Thu, 6 Mar 2014 10:11:06 +0000 Message-ID: References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.128.127] Content-Type: multipart/alternative; boundary="_000_DE7ABC34B5684387BC7BDF55D52576EEneustarbiz_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/yhXWrXwRxZLOmkLHkbBkl0QQ1Sw Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 06 Mar 2014 10:11:28 -0000 --_000_DE7ABC34B5684387BC7BDF55D52576EEneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Note that we could eliminate the text in this doc and rely on the relevant = regulations to force devices to use the parameter. As long as the protocol= can carry the value, then the regs can control what the device must do. I suspect the concern about not understanding a value is probably covered b= y the same solution. If the device is licensed for a particular regulatory= domain, then it will have to be able to handle all the values defined for = that domain. The protocol needs a statement to cover it however. The usua= l advice is =93ignore it=94. Brian On Mar 6, 2014, at 5:18 AM, Andy Lee > wrote: Thank you both for the additional clarifications. I think this is getting out-of-scope for the PAWS standard, but there is no= future-proofing guidance here either. If a device built today knows what = to do when etsiEnSimultaneousChannelOperationRestriction=3D"0" and when ets= iEnSimultaneousChannelOperationRestriction=3D"1", what should it do when a = database sends a value it doesn't recognize in the future? The spec is clear about what to do when the parameter is not sent at all, b= ut no fallback behavior is defined for when the parameter takes on new valu= es never seen before. This seems to be clearly out-of-scope of PAWS itself= , and as Ben suggested, this should defer to the ETSI spec for details. However, this still leaves the question of what "must not ignore" means. D= evices cannot process unknown future values, so how can they possibly "not = ignore" a field that is unrecognizable to them? At this point, I think all we can say is that if a device encounters etsiEn= SimultaneousChannelOperationRestriction=3D"1", it must follow the ETSI powe= r constraint rules. Any other statements about defaulting to "0" and "must= not ignore" seem superfluous. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe > wrote: Thanks Vincent. I was attempting to capture what you just explained. I think that is what I= captured - reference the ETSI spec for what to do when the value is not ze= ro. I had guessed that the intent of adding this param was to provide a way to = signal that an additional constraint is applied to the channels being used. On 3/5/2014 6:50 PM, Vincent Chen wrote: Ben, Andy, >From what I understood, the request is to add a parameter to the protocol w= ith numeric string values, with a default value of "0". It does not limit the v= alid values to "0" or "1", and does not associate meaning to the values. The device beh= avior, upon receipt of the value, is defined by the ETSI specs, not the protocol d= oc. The "MUST NOT ignore" is intended to indicate that the device must understa= nd the value, if present. The risk of not processing the value is that, if ETS= I were to add another value that is more restrictive, the hard-coded device would be out = of compliance. I believe the intent is to prevent hard-coding in devices. -vince On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe > wrote: I too was struggling with this wording. "Must not" is often problematic fo= r me, and I was struggling to figure out how we verify that device has not = ignored a parameter when the value of the paramter has a value that produce= s no observable behavior, such as the case Andy sites or the case where the= value is zero. The logic should be: If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0) Do what you were going to do anyway; else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1) Do not exceed the lower limit; The first condition looks to me pretty much the definition of "ignore" (bas= ed on my experience as a parent :-). Only the second condition can produce= an observable change in the devices behavior. So if I have figured it out = correctly the requirement being stated is: If the etsiEnSimultaneousChannelOperationRestriction paramter is provided = and the value is 1, the Device MUST comply with the additional power restr= ictions when simultaneous transmission on multiple channel operation define= d in [reference]. Is that right? -Ben On 3/5/2014 4:17 PM, Andy Lee wrote: I have a question about the new parameter etsiEnSimultaneousChannelOperatio= nRestriction and the phrase "If it is provided, the Device MUST NOT ignore = it." I can understand that if this parameter is provided and is set to "1", that= the device must honor it (reduce output power when using multiple channels= ). But what if there is a device that "hard coded" to always apply the power r= estriction when using multiple channels? This "conservative" approach woul= d always remain below the permitted emission limits regardless of whether t= his flag is set to "1" or "0". Are we saying that if this parameter is provided and is set to "0" that the= device must not apply the multi-channel power restrictions? What does it = mean to say "MUST NOT ignore it" in such a case. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen > wrote: PAWS, Draft 11 contains the following changes: - Separation of protocol and regulatory requirements. In essence, MAY, MUS= T , SHOULD has been replaced where the text describes regulatory requiremen= ts and device behavior. They are replaced with just explanatory text. - Added the new ETSI parameter for simultaneous channel-operation restrict= ions Diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-10&diffty= pe=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-11 -vince On Wed, Mar 5, 2014 at 7:09 AM, > wrote: 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 Working Gr= oup of the IETF. Title : Protocol to Access White-Space (PAWS) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-11.txt Pages : 108 Date : 2014-03-05 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ 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 -- -vince _______________________________________________ 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_DE7ABC34B5684387BC7BDF55D52576EEneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Note that we could eliminate the text in this doc and rely on the relevant = regulations to force devices to use the parameter.  As long as the pro= tocol can carry the value, then the regs can control what the device must d= o.  

I suspect the concern about not understanding a value is probably cove= red by the same solution.  If the device is licensed for a particular = regulatory domain, then it will have to be able to handle all the values de= fined for that domain.  The protocol needs a statement to cover it however.  The usual advice is =93ignore= it=94.  

Brian
 
On Mar 6, 2014, at 5:18 AM, Andy Lee <tvfool@google.com> wrote:

Thank you both for the additional clarifications.

I think this is getting out-of-scope for the PAWS standard, but there is no= future-proofing guidance here either.  If a device built today knows = what to do when etsiEnSimultaneousChannelOperationRestriction=3D"0" and when etsiEnSimultaneousChannelOperationRestriction=3D"1", what should i= t do when a database sends a value it doesn't recognize in the future?

The spec i= s clear about what to do when the parameter is not sent at all, but no fall= back behavior is defined for when the parameter takes on new values never s= een before.  This seems to be clearly out-of-scope of PAWS itself, and as Ben suggested, this should defer to th= e ETSI spec for details.

However, t= his still leaves the question of what "must not ignore" means. &n= bsp;Devices cannot process unknown future values, so how can they possibly = "not ignore" a field that is unrecognizable to them?

At this po= int, I think all we can say is that if a device encounters etsiEnSimultaneousC= hannelOperationRestriction=3D"1", it = ;must follow the ETSI power constraint rules.  Any other statements about defa= ulting to "0" and "must not ignore" seem superfluous.


Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolf= e <ben@blindcreek.= com> wrote:
Thanks Vincent. 

I was attempting t= o capture what you just explained. I think that is what I captured - refere= nce the ETSI spec for what to do when the value is not zero.
I had guessed that the intent of adding this param was to provide a way to = signal that an additional constraint is applied to the channels being used.=


On 3/5/2014 6:50 PM, Vincent Chen wrote:
Ben, Andy,

From what I understood, the request is to add a parameter to the proto= col with
numeric string values, with a default value of "0". It does = not limit the valid values
to "0" or "1", and does not associate meaning to t= he values. The device behavior, 
upon receipt of the value, is defined by the ETSI specs, not the proto= col doc.

The "MUST NOT ignore" is intended to indicate that the devic= e must understand
the value, if present. The risk of not processing the value is that, i= f ETSI were to add
another value that is more restrictive, the hard-coded device would be= out of
compliance.

I believe the intent is to prevent hard-coding in devices.

-vince


On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolf= e <ben@blindcreek.= com> wrote:
I too was struggling with this wording.&n= bsp; "Must not" is often problematic for me, and I was struggling= to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable beh= avior, such as the case Andy sites or the case where the value is zero. The= logic should be:

If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0)
   Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1)
   Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore&= quot; (based on my experience as a parent :-).  Only the second condit= ion can produce an observable change in the devices behavior. So if I have = figured it out correctly the requirement being stated  is:

If the etsiEnSimultaneousChannelOperationRestriction  paramter is= provided and the value is 1,  the Device MUST comply with the additio= nal power restrictions when simultaneous transmission on multiple channel operation defined in [reference].

Is that right?

-Ben
On 3/5/2014 4:17 PM, Andy Lee wrote:
I have a question about the new parameter etsiEnSimultaneo= usChannelOperationRestriction and the phrase "If it is provided, = the Device MUST NOT ignore it."

I can understand that if this parameter is provided and is set to &quo= t;1", that the device must honor it (reduce output power when using mu= ltiple channels).

But what if there is a device that "hard coded" to always ap= ply the power restriction when using multiple channels?  This "co= nservative" approach would always remain below the permitted emission = limits regardless of whether this flag is set to "1" or "0&q= uot;.

Are we saying that if this parameter is provided and is set to "0= " that the device must not apply the multi-channel power restrictions?=  What does it mean to say "MUST NOT ignore it" in such a ca= se.





Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com<= /a>> wrote:


On Wed, Mar 5, 2014 at 7:09 AM, <interne= t-drafts@ietf.org> wrote:

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 Worki= ng Group of the IETF.

        Title           : Prot= ocol to Access White-Space (PAWS) Databases
        Authors         : Vincent C= hen
                     = ;     Subir Das
                     = ;     Lei Zhu
                     = ;     John Malyar
                     = ;     Peter J. McCann
        Filename        : draft-iet= f-paws-protocol-11.txt
        Pages           : 108<= br>         Date            := 2014-03-05

Abstract:
   Portions of the radio spectrum that are allocated to licensees= are
   available for non-interfering use.  This available spectr= um is called
   "White Space."  Allowing secondary users access= to available spectrum
   "unlocks" existing spectrum to maximize its utilizat= ion and to
   provide opportunities for innovation, resulting in greater ove= rall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to repo= rt
   spectrum availability to devices.  To achieve interoperab= ility among
   multiple devices and databases, a standardized protocol must b= e
   defined and implemented.  This document defines such a pr= otocol, the
   "Protocol to Access White Space (PAWS) Databases".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-11


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

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

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



--
-vince

_______________________________________________
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


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




--
-vince


_______________________________________________
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_DE7ABC34B5684387BC7BDF55D52576EEneustarbiz_-- From nobody Tue Mar 11 07:03:59 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA88E1A0729 for ; Tue, 11 Mar 2014 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Z0KoJOhpog2 for ; Tue, 11 Mar 2014 07:03:53 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9334B1A045C for ; Tue, 11 Mar 2014 07:03:53 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id m1so8634188oag.35 for ; Tue, 11 Mar 2014 07:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SYaQjcAkYuYWErH3Vjs6Fibc/ulfLH4sQxgcusuoMZI=; b=VfO6Qbs/q+xV7IycdCMfwofhhRdp0Wv8M6dpuiEa2364AWTz+OR0cHUXfNyGRJ+AQX 9mgPmD0/TyRsvByJtlRwIB/S6MdMgBeR/pHijXAPP7GXJoQ7cYPM4NWKUO6YesrXqNDh a2kUUvZpX88yXjwRayHos/8GviVR8qpeppsOPLqJs+aej6IPj6krtXvAPyO3V6lhRFwt wz2BbhP07Y5Esa47QpVbC11FbjF3E/7XgxouVNIT+jTxoBNO9ValmdIuqWqpEoS4I7j0 DGgb4AOMH+ubzv/E/y2j2wdV0p9TNBBCCa2YABlejuKeVAStr0QRnMNq0ePRUyHGiDe7 AMnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SYaQjcAkYuYWErH3Vjs6Fibc/ulfLH4sQxgcusuoMZI=; b=ei4eIYWeFYbJ5BAXRImaCDmcvlva+os1SdF5qjHzNcv0VCLf5Z93A8xPaIV9aZAMBX G1byeF9NSCGKfOYvhym8rKiVEysGhb9iQv5rjXHBjnngSPqyZ1Zr/lO4K/c30Y7rcKL1 HQNaGCNExCzzfwYLBvK3bTXhS6JhTRxkH5tryV44M9QRosjcmPvegIfnbmCThFvllwSf 9C4CyjK9AWysK1dFVcAQ3dSMv5NiTcfUD6DOcugeUNa9GbL/J92yy7TwjrbFr9EJ+/ON 0gsfotjWp7DXyS/eWZQyI2CnDnMzy7fnEl2M0Zy+jCnR/mNoJRPpuEhPpnX8vzB5NvaY GNDA== X-Gm-Message-State: ALoCoQlY16XlEYD1DH1qm1lW4A5Xj6v2tA7WqQkLdgmiJENwBHXBALsvFhY2UJkBvBCJq4r88SY8ubTxdZ+dq0i70ns1CDk/ZrbfmZwNDlimVy8qEH6c3Hxk8Yzh6ubiDv6nE7gV14NSdVDmTrPiiQWSpy/xx901+F66azhOZ4iWN07UG0y5V1ONqTvPelnWy9fY26Gp/51O MIME-Version: 1.0 X-Received: by 10.60.52.138 with SMTP id t10mr1948329oeo.59.1394546627765; Tue, 11 Mar 2014 07:03:47 -0700 (PDT) Received: by 10.182.45.166 with HTTP; Tue, 11 Mar 2014 07:03:47 -0700 (PDT) In-Reply-To: References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> Date: Tue, 11 Mar 2014 07:03:47 -0700 Message-ID: From: Vincent Chen To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=001a113304705efe4004f4553079 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/_LMmc6jxY1A4pYB9SXcXbYsLYJE Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 11 Mar 2014 14:03:58 -0000 --001a113304705efe4004f4553079 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andy, Brian, I've been stewing on this for a while. I guess at issue are really 2 things= : 1. Whether or not the Device understands the parameter name 2. Whether or not the Device understands the parameter value Currently, "must not ignore parameter" is focused on 1. Whether or not the device understands the value and what it should do with unrecognized values is defined by the regulatory domain. Of course, we can back off and say both 1 and 2, as Brian suggests, are left up to the regulatory domain. But note that the language here is specifically in the ETSI section. - Will different countries that adopt the ETSI rules have different requirements? Thoughts? -vince On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian wrote= : > Note that we could eliminate the text in this doc and rely on the > relevant regulations to force devices to use the parameter. As long as t= he > protocol can carry the value, then the regs can control what the device > must do. > > I suspect the concern about not understanding a value is probably > covered by the same solution. If the device is licensed for a particular > regulatory domain, then it will have to be able to handle all the values > defined for that domain. The protocol needs a statement to cover it > however. The usual advice is =E2=80=9Cignore it=E2=80=9D. > > Brian > > On Mar 6, 2014, at 5:18 AM, Andy Lee wrote: > > Thank you both for the additional clarifications. > > I think this is getting out-of-scope for the PAWS standard, but there is > no future-proofing guidance here either. If a device built today knows > what to do when etsiEnSimultaneousChannelOperationRestriction=3D"0" and > when etsiEnSimultaneousChannelOperationRestriction=3D"1", what should it = do > when a database sends a value it doesn't recognize in the future? > > The spec is clear about what to do when the parameter is not sent at > all, but no fallback behavior is defined for when the parameter takes on > new values never seen before. This seems to be clearly out-of-scope of > PAWS itself, and as Ben suggested, this should defer to the ETSI spec for > details. > > However, this still leaves the question of what "must not ignore" means. > Devices cannot process unknown future values, so how can they possibly > "not ignore" a field that is unrecognizable to them? > > At this point, I think all we can say is that if a device encounters > etsiEnSimultaneousChannelOperationRestriction=3D"1", it must follow the > ETSI power constraint rules. Any other statements about defaulting to > "0" and "must not ignore" seem superfluous. > > > Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 > > > On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe wro= te: > >> Thanks Vincent. >> >> I was attempting to capture what you just explained. I think that is wha= t >> I captured - reference the ETSI spec for what to do when the value is no= t >> zero. >> I had guessed that the intent of adding this param was to provide a way >> to signal that an additional constraint is applied to the channels being >> used. >> >> >> On 3/5/2014 6:50 PM, Vincent Chen wrote: >> >> Ben, Andy, >> >> From what I understood, the request is to add a parameter to the >> protocol with >> numeric string values, with a default value of "0". It does not limit th= e >> valid values >> to "0" or "1", and does not associate meaning to the values. The device >> behavior, >> upon receipt of the value, is defined by the ETSI specs, not the protoco= l >> doc. >> >> The "MUST NOT ignore" is intended to indicate that the device must >> understand >> the value, if present. The risk of not processing the value is that, if >> ETSI were to add >> another value that is more restrictive, the hard-coded device would be >> out of >> compliance. >> >> I believe the intent is to prevent hard-coding in devices. >> >> -vince >> >> >> On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe wr= ote: >> >>> I too was struggling with this wording. "Must not" is often problemati= c >>> for me, and I was struggling to figure out how we verify that device ha= s >>> not ignored a parameter when the value of the paramter has a value that >>> produces no observable behavior, such as the case Andy sites or the cas= e >>> where the value is zero. The logic should be: >>> >>> If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0) >>> Do what you were going to do anyway; >>> else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1) >>> Do not exceed the lower limit; >>> >>> The first condition looks to me pretty much the definition of "ignore" >>> (based on my experience as a parent :-). Only the second condition can >>> produce an observable change in the devices behavior. So if I have figu= red >>> it out correctly the requirement being stated is: >>> >>> If the etsiEnSimultaneousChannelOperationRestriction paramter is >>> provided and the value is 1, the Device MUST comply with the additiona= l >>> power restrictions when simultaneous transmission on multiple channel >>> operation defined in [reference]. >>> >>> Is that right? >>> >>> -Ben >>> >>> On 3/5/2014 4:17 PM, Andy Lee wrote: >>> >>> I have a question about the new parameter >>> etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is >>> provided, the Device MUST NOT ignore it." >>> >>> I can understand that if this parameter is provided and is set to "1", >>> that the device must honor it (reduce output power when using multiple >>> channels). >>> >>> But what if there is a device that "hard coded" to always apply the >>> power restriction when using multiple channels? This "conservative" >>> approach would always remain below the permitted emission limits regard= less >>> of whether this flag is set to "1" or "0". >>> >>> Are we saying that if this parameter is provided and is set to "0" >>> that the device must not apply the multi-channel power restrictions? W= hat >>> does it mean to say "MUST NOT ignore it" in such a case. >>> >>> >>> >>> >>> >>> Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 >>> >>> >>> On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen wrote: >>> >>>> PAWS, >>>> >>>> Draft 11 contains the following changes: >>>> - Separation of protocol and regulatory requirements. In essence, MAY= , >>>> MUST , SHOULD has been replaced where the text describes regulatory >>>> requirements and device behavior. They are replaced with just explanat= ory >>>> text. >>>> >>>> - Added the new ETSI parameter for simultaneous channel-operation >>>> restrictions >>>> >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-10&difftyp= e=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-11 >>>> >>>> -vince >>>> >>>> >>>> On Wed, Mar 5, 2014 at 7:09 AM, wrote: >>>> >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Protocol to Access WS database >>>>> Working Group of the IETF. >>>>> >>>>> Title : Protocol to Access White-Space (PAWS) >>>>> Databases >>>>> Authors : Vincent Chen >>>>> Subir Das >>>>> Lei Zhu >>>>> John Malyar >>>>> Peter J. McCann >>>>> Filename : draft-ietf-paws-protocol-11.txt >>>>> Pages : 108 >>>>> Date : 2014-03-05 >>>>> >>>>> Abstract: >>>>> Portions of the radio spectrum that are allocated to licensees are >>>>> available for non-interfering use. This available spectrum is >>>>> called >>>>> "White Space." Allowing secondary users access to available >>>>> spectrum >>>>> "unlocks" existing spectrum to maximize its utilization and to >>>>> provide opportunities for innovation, resulting in greater overall >>>>> spectrum utilization. >>>>> >>>>> One approach to manage spectrum sharing uses databases to report >>>>> spectrum availability to devices. To achieve interoperability amo= ng >>>>> multiple devices and databases, a standardized protocol must be >>>>> defined and implemented. This document defines such a protocol, t= he >>>>> "Protocol to Access White Space (PAWS) Databases". >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-paws-protocol-11 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-11 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>> >>>> >>>> >>>> -- >>>> -vince >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>>> >>> >>> >>> _______________________________________________ >>> paws mailing listpaws@ietf.orghttps://www.ietf.org/mailman/listinfo/paw= s >>> >>> >>> >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >> >> >> -- >> -vince >> >> >> >> _______________________________________________ >> 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 > > --=20 -vince --001a113304705efe4004f4553079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy, Brian,

I've been stewing on t= his for a while. I guess at issue are really 2 things:

=
=C2=A01. Whether or not the Device understands the parameter name

=C2=A02. Whether or not the Device understands the parameter= value

Currently, "must not ignore parameter&= quot; is focused on 1. Whether or not the device
understands the = value and what it should do with unrecognized values
is defined by the regulatory domain.

Of cours= e, we can back off and say both 1 and 2, as Brian suggests, are
l= eft up to the regulatory domain. But note that the language here is
specifically in the ETSI section.

=C2=A0- Wil= l different countries that adopt the ETSI rules have different requirements= ?

Thoughts?

-vince
<= /div>


On Thu, Mar 6= , 2014 at 2:11 AM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
Note that we could eliminate the text in this doc and rely on the relevant = regulations to force devices to use the parameter. =C2=A0As long as the pro= tocol can carry the value, then the regs can control what the device must d= o. =C2=A0

I suspect the concern about not understanding a value is probably cove= red by the same solution. =C2=A0If the device is licensed for a particular = regulatory domain, then it will have to be able to handle all the values de= fined for that domain. =C2=A0The protocol needs a statement to cover it however. =C2=A0The usual advice is =E2=80=9C= ignore it=E2=80=9D. =C2=A0

Brian
=C2=A0
On Mar 6, 2014, at 5:18 AM, Andy Lee <tvfool@google.com> wrote:

Thank you both for the additional clarifications.

I think this is getting out-of-scope for the PAWS standard, but there is no= future-proofing guidance here either. =C2=A0If a device built today knows = what to do when=C2=A0etsiEnSimultaneousChannelOperationRestriction=3D"0" and when=C2=A0etsiEnSimultaneousChannelOperationRestriction=3D"1", what should i= t do when a database sends a value it doesn't recognize=C2=A0in the future?

The spec i= s clear about what to do when the parameter is not sent at all, but no fall= back behavior is defined for when the parameter takes on new values never s= een before. =C2=A0This seems to be clearly out-of-scope of PAWS itself, and as Ben suggested, this should defer to th= e ETSI spec for details.

However, t= his still leaves the question of what "must not ignore" means. = =C2=A0Devices cannot process unknown future values, so how can they possibl= y "not ignore" a field that is unrecognizable to them?

At this po= int, I think all we can say is that if a device encounters=C2=A0etsiEnSimultaneousC= hannelOperationRestriction=3D"1", it=C2= =A0must follow the ETSI power constraint rules. =C2=A0Any other statements about de= faulting to "0" and "must not ignore" seem superfluous.=


Andy Lee=C2=A0| =C2=A0Google Inc. | =C2=A0tvfool@google.= com=C2=A0| =C2=A0408-230-0522


On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolf= e <ben@blindcreek.= com> wrote:
Thanks Vincent.=C2=A0

I was attempting to captur= e what you just explained. I think that is what I captured - reference the = ETSI spec for what to do when the value is not zero.
I had guessed that the intent of adding this param was to provide a way to = signal that an additional constraint is applied to the channels being used.=


On 3/5/2014 6:50 PM, Vincent Chen wrote:
Ben, Andy,

From what I understood, the request is to add a parameter to the proto= col with
numeric string values, with a default value of "0". It does = not limit the valid values
to "0" or "1", and does not associate meaning to t= he values. The device behavior,=C2=A0
upon receipt of the value, is defined by the ETSI specs, not the proto= col doc.

The "MUST NOT ignore" is intended to indicate that the devic= e must understand
the value, if present. The risk of not processing the value is that, i= f ETSI were to add
another value that is more restrictive, the hard-coded device would be= out of
compliance.

I believe the intent is to prevent hard-coding in devices.

-vince


On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolf= e <ben@blindcreek.= com> wrote:
I too was struggling with this wording.=C2=A0 = "Must not" is often problematic for me, and I was struggling to f= igure out how we verify that device has not ignored a parameter when the value of the paramter has a value that produces no observable beh= avior, such as the case Andy sites or the case where the value is zero. The= logic should be:

If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0)
=C2=A0=C2=A0 Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1)
=C2=A0=C2=A0 Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore&= quot; (based on my experience as a parent :-).=C2=A0 Only the second condit= ion can produce an observable change in the devices behavior. So if I have = figured it out correctly the requirement being stated=C2=A0 is:

If the etsiEnSimultaneousChannelOperationRestriction=C2=A0 paramter is pro= vided and the value is 1,=C2=A0 the Device MUST comply with the additional = power restrictions when simultaneous transmission on multiple channel operation defined in [reference].

Is that right?

-Ben
On 3/5/2014 4:17 PM, Andy Lee wrote:
I have a question about the new parameter etsiEnSimultaneo= usChannelOperationRestriction and the phrase "If it=C2=A0is provided, = the Device MUST NOT ignore it."

I can understand that if this parameter is provided and is set to &quo= t;1", that the device must honor it (reduce output power when using mu= ltiple channels).

But what if there is a device that "hard coded" to always ap= ply the power restriction when using multiple channels? =C2=A0This "co= nservative" approach would always remain below the permitted emission = limits regardless of whether this flag is set to "1" or "0&q= uot;.

Are we saying that if this parameter is provided and is set to "0= " that the device must not apply the multi-channel power restrictions?= =C2=A0What does it mean to say "MUST NOT ignore it" in such a ca= se.





Andy Lee=C2=A0| =C2=A0Google Inc. | =C2=A0tvfool@google.= com=C2=A0| =C2=A0408-230-0522


On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com<= /a>> wrote:


On Wed, Mar 5, 2014 at 7:09 AM, <interne= t-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Protocol to Access WS database Worki= ng Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Prot= ocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vincent C= hen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 108<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spectrum that are allocated to licensees= are
=C2=A0 =C2=A0available for non-interfering use. =C2=A0This available spectr= um is called
=C2=A0 =C2=A0"White Space." =C2=A0Allowing secondary users access= to available spectrum
=C2=A0 =C2=A0"unlocks" existing spectrum to maximize its utilizat= ion and to
=C2=A0 =C2=A0provide opportunities for innovation, resulting in greater ove= rall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spectrum sharing uses databases to repo= rt
=C2=A0 =C2=A0spectrum availability to devices. =C2=A0To achieve interoperab= ility among
=C2=A0 =C2=A0multiple devices and databases, a standardized protocol must b= e
=C2=A0 =C2=A0defined and implemented. =C2=A0This document defines such a pr= otocol, the
=C2=A0 =C2=A0"Protocol to Access White Space (PAWS) Databases".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-11


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

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

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



--
-vince

_______________________________________________
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


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




--
-vince


_______________________________________________
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


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




--
-vince
--001a113304705efe4004f4553079-- From nobody Wed Mar 12 05:21:58 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13EB1A0968 for ; Wed, 12 Mar 2014 05:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSFet-43_hHr for ; Wed, 12 Mar 2014 05:21:50 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8D71A0958 for ; Wed, 12 Mar 2014 05:21:49 -0700 (PDT) Received: from [85.158.139.3:58133] by server-12.bemta-5.messagelabs.com id 1E/81-03824-65150235; Wed, 12 Mar 2014 12:21:42 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-10.tower-90.messagelabs.com!1394626901!23089811!1 X-Originating-IP: [194.33.160.63] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24442 invoked from network); 12 Mar 2014 12:21:41 -0000 Received: from unknown (HELO WOK-INTRA-EDG01.intra.ofcom.local) (194.33.160.63) by server-10.tower-90.messagelabs.com with AES128-SHA encrypted SMTP; 12 Mar 2014 12:21:41 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG01.intra.ofcom.local (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.3.136.1; Wed, 12 Mar 2014 12:21:41 +0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%14]) with mapi id 14.03.0136.001; Wed, 12 Mar 2014 12:21:41 +0000 From: Cesar Gutierrez To: Vincent Chen , "Rosen, Brian" Thread-Topic: [paws] I-D Action: draft-ietf-paws-protocol-11.txt Thread-Index: AQHPOIT7Jct25cq6pUmjYZoMQ27WCJrSmv0AgACW34CAACZogIAABG+AgAAJ5QCAAB9tAIAAUbcAgAgcq4CAABOmoA== Date: Wed, 12 Mar 2014 12:21:47 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655B3CEEA1B@WOK-INTRA-EXC02.intra.ofcom.local> References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655B3CEEA1BWOKINTRAEXC02in_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/N69d_cqX-Lks1d8DObJB4pXc69Y Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 12:21:55 -0000 --_000_5D3E853BEE49C848BB63047C794C8655B3CEEA1BWOKINTRAEXC02in_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmluY2UgYW5kIGFsbCwNCg0KRm9yIGNvbXBsZXRlbmVzcywgdGhpcyB3aGF0IHRoZSBFVFNJIHN0 YW5kYXJkIHNheXM6DQoNCuKAnFNpbXVsdGFuZW91cyBjaGFubmVsIG9wZXJhdGlvbiBwb3dlciBy ZXN0cmljdGlvbiAoc2VlIG5vdGUgMik6IENhbiB0YWtlIHZhbHVlcyBvZiAwIG9yIDEuIEEgdmFs dWUgb2YgMSBpbmRpY2F0ZXMgdGhlIGRldmljZSB0aGF0IHRoZSBwb3dlciByZXN0cmljdGlvbiBp biBjbGF1c2UgNC4yLjMuMiBhcHBsaWVzLCBhIHZhbHVlIG9mIDAgaW5kaWNhdGVzIHRoYXQgdGhl IHBvd2VyIHJlc3RyaWN0aW9uIGRvZXMgbm90IGFwcGx5LiBUaGUgZGVmYXVsdCB2YWx1ZSBpcyAw Lg0KTk9URSAyOklmIHRoZSBzaW11bHRhbmVvdXMgY2hhbm5lbCBvcGVyYXRpb24gcG93ZXIgcmVz dHJpY3Rpb24gcGFyYW1ldGVyIGlzIG5vdCBwcm92aWRlZCwgdGhlIGRldmljZSBzaGFsbCB1c2Ug dGhlIGRlZmF1bHQgdmFsdWUgb2YgMC7igJ0NCg0KSSB0aGluayB0aGUgUEFXUyBzcGVjaWZpY2F0 aW9uIHNob3VsZCBiZSBjb3ZlciB0aGUgZm9sbG93aW5nIHR3byBjYXNlczoNCg0KLSAgICAgICBU aGUgZGF0YWJhc2UgZG9lcyBub3QgcHJvdmlkZSB0aGUgcGFyYW1ldGVyLiBUaGUgZGV2aWNl4oCZ cyBiZWhhdmlvdXIgc2hvdWxkIGJlIOKAnE5vIHBvd2VyIHJlc3RyaWN0aW9u4oCdLiBUaGlzIHJl cGVhdHMgTm90ZSAyIGluIEVUU0kgc3RhbmRhcmQgYnV0IGl0IGlzIGluIG15IHZpZXcgd29ydGgg Y2FwdHVyaW5nIGluIFBBV1MgaXRzZWxmDQoNCi0gICAgICAgVGhlIGRldmljZSByZWNlaXZlcyBh IHZhbHVlIGRpZmZlcmVudCBmcm9tIDAgb3IgMS4gVGhpcyBpcyBhIGNvbW11bmljYXRpb25zIGVy cm9yIG9yIGFuIGVycm9yIGluIHRoZSBkYXRhYmFzZeKAmXMgaW1wbGVtZW50YXRpb24gb2YgUEFX UyB2MTEsIHdoaWNoIHNob3VsZCBvbmx5IGFsbG93IGZvciB0d28gdmFsdWVzLiBJIHRoaW5rIFBB V1Mgc2hvdWxkIGNsYXJpZnkgdGhhdCB0aGUgZGV2aWNlIGJlaGF2aW91ciBzaG91bGQgYmUgdGhl IHNhbWUgYXMgYWJvdmUuDQoNCldoZXRoZXIgb3Igbm90IHRoZSBkZXZpY2UgdW5kZXJzdGFuZHMg dGhlIHBhcmFtZXRlciBuYW1lIGxvb2tzIGFuIG9kZCBxdWVzdGlvbiB0byBtZS4gSWYgYSBkZXZp Y2UgY2xhaW1zIHRvIGJlIFBBV1MgdjExIGNvbXBsaWFudCwgdGhlbiBJIHdvdWxkIGFzc3VtZSB0 aGF0IGl0IGNhbiBkZWNvZGUgYWxsIHBhcmFtZXRlcnMgdGhhdCBhcmUgZGVmaW5lZCBpbiB0aGUg c3BlYy4gT24gdGhlIG90aGVyIGhhbmQsIEkgYWdyZWUgdGhhdCB3aGV0aGVyIG9yIG5vdCB0aGUg ZGV2aWNlIHVuZGVyc3RhbmRzIHdoYXQgaXQgbXVzdCBkbyBpZiBpdCByZWNlaXZlcyBhIDEgaXMg YmV5b25kIHRoZSBzY29wZSBvZiBQQVdTLg0KDQpEaWZmZXJlbnQgY291bnRyaWVzIG1heSB3YW50 IHRvIGFkZCBuZXcgcG9zc2libGUgdmFsdWVzIHRvIHRoaXMgcGFyYW1ldGVyLCBidXQgdGhpcyB3 aWxsIHJlcXVpcmUgYW4gdXBkYXRlIG9mIHRoZSBFVFNJIHN0YW5kYXJkLiBDb21wbGlhbmNlIHdp dGggdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgRVRTSSBzdGFuZGFyZCByZXF1aXJlcyBzdXBw b3J0IG9mIHRoZXNlIHR3byB2YWx1ZXMgb25seS4NCg0KSXQgd2FzIGFza2VkIGluIExvbmRvbiB3 aGV0aGVyIHdlIGNvdWxkIGtub3cgdGhlIHZlcnNpb24gbnVtYmVyIG9mIHRoZSBFVFNJIHN0YW5k YXJkIHRoYXQgd2lsbCBiZSBwdWJsaXNoZWQgYW5kIGNpdGVkIGluIHRoZSBPZmZpY2lhbCBKb3Vy bmFsLiBUaGUgYW5zd2VyIGlzIG5vLiBBbmR5IG1lbnRpb25lZCBhIHdvcmthcm91bmQgdGhhdCB3 b3VsZCBhbGxvdyB0byBmb2xsb3cgdGhlIHVzdWFsIElFVEYgYXBwcm92YWwgcHJvY2VzcyBhbmQg Y2hhbmdlIHRoZSBFVFNJIHZlcnNpb24gbnVtYmVyIGF0IGEgbGF0ZXIgc3RhZ2Ug4oCTIHdlIHdp bGwgbmVlZCB0byB1c2UgdGhpcy4NCg0KDQpSZWdhcmRzLA0KQ2VzYXINCg0KDQpGcm9tOiBWaW5j ZW50IENoZW4gW21haWx0bzp2Y2hlbkBnb29nbGUuY29tXQ0KU2VudDogMTEgTWFyY2ggMjAxNCAx NDowNA0KVG86IFJvc2VuLCBCcmlhbg0KQ2M6IEFuZHkgTGVlOyBwYXdzQGlldGYub3JnOyBDZXNh ciBHdXRpZXJyZXoNClN1YmplY3Q6IFJlOiBbcGF3c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1w YXdzLXByb3RvY29sLTExLnR4dA0KDQpBbmR5LCBCcmlhbiwNCg0KSSd2ZSBiZWVuIHN0ZXdpbmcg b24gdGhpcyBmb3IgYSB3aGlsZS4gSSBndWVzcyBhdCBpc3N1ZSBhcmUgcmVhbGx5IDIgdGhpbmdz Og0KDQogMS4gV2hldGhlciBvciBub3QgdGhlIERldmljZSB1bmRlcnN0YW5kcyB0aGUgcGFyYW1l dGVyIG5hbWUNCg0KIDIuIFdoZXRoZXIgb3Igbm90IHRoZSBEZXZpY2UgdW5kZXJzdGFuZHMgdGhl IHBhcmFtZXRlciB2YWx1ZQ0KDQpDdXJyZW50bHksICJtdXN0IG5vdCBpZ25vcmUgcGFyYW1ldGVy IiBpcyBmb2N1c2VkIG9uIDEuIFdoZXRoZXIgb3Igbm90IHRoZSBkZXZpY2UNCnVuZGVyc3RhbmRz IHRoZSB2YWx1ZSBhbmQgd2hhdCBpdCBzaG91bGQgZG8gd2l0aCB1bnJlY29nbml6ZWQgdmFsdWVz DQppcyBkZWZpbmVkIGJ5IHRoZSByZWd1bGF0b3J5IGRvbWFpbi4NCg0KT2YgY291cnNlLCB3ZSBj YW4gYmFjayBvZmYgYW5kIHNheSBib3RoIDEgYW5kIDIsIGFzIEJyaWFuIHN1Z2dlc3RzLCBhcmUN CmxlZnQgdXAgdG8gdGhlIHJlZ3VsYXRvcnkgZG9tYWluLiBCdXQgbm90ZSB0aGF0IHRoZSBsYW5n dWFnZSBoZXJlIGlzDQpzcGVjaWZpY2FsbHkgaW4gdGhlIEVUU0kgc2VjdGlvbi4NCg0KIC0gV2ls bCBkaWZmZXJlbnQgY291bnRyaWVzIHRoYXQgYWRvcHQgdGhlIEVUU0kgcnVsZXMgaGF2ZSBkaWZm ZXJlbnQgcmVxdWlyZW1lbnRzPw0KDQpUaG91Z2h0cz8NCg0KLXZpbmNlDQoNCk9uIFRodSwgTWFy IDYsIDIwMTQgYXQgMjoxMSBBTSwgUm9zZW4sIEJyaWFuIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJp ejxtYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo+PiB3cm90ZToNCk5vdGUgdGhhdCB3ZSBj b3VsZCBlbGltaW5hdGUgdGhlIHRleHQgaW4gdGhpcyBkb2MgYW5kIHJlbHkgb24gdGhlIHJlbGV2 YW50IHJlZ3VsYXRpb25zIHRvIGZvcmNlIGRldmljZXMgdG8gdXNlIHRoZSBwYXJhbWV0ZXIuICBB cyBsb25nIGFzIHRoZSBwcm90b2NvbCBjYW4gY2FycnkgdGhlIHZhbHVlLCB0aGVuIHRoZSByZWdz IGNhbiBjb250cm9sIHdoYXQgdGhlIGRldmljZSBtdXN0IGRvLg0KDQpJIHN1c3BlY3QgdGhlIGNv bmNlcm4gYWJvdXQgbm90IHVuZGVyc3RhbmRpbmcgYSB2YWx1ZSBpcyBwcm9iYWJseSBjb3ZlcmVk IGJ5IHRoZSBzYW1lIHNvbHV0aW9uLiAgSWYgdGhlIGRldmljZSBpcyBsaWNlbnNlZCBmb3IgYSBw YXJ0aWN1bGFyIHJlZ3VsYXRvcnkgZG9tYWluLCB0aGVuIGl0IHdpbGwgaGF2ZSB0byBiZSBhYmxl IHRvIGhhbmRsZSBhbGwgdGhlIHZhbHVlcyBkZWZpbmVkIGZvciB0aGF0IGRvbWFpbi4gIFRoZSBw cm90b2NvbCBuZWVkcyBhIHN0YXRlbWVudCB0byBjb3ZlciBpdCBob3dldmVyLiAgVGhlIHVzdWFs IGFkdmljZSBpcyDigJxpZ25vcmUgaXTigJ0uDQoNCkJyaWFuDQoNCk9uIE1hciA2LCAyMDE0LCBh dCA1OjE4IEFNLCBBbmR5IExlZSA8dHZmb29sQGdvb2dsZS5jb208bWFpbHRvOnR2Zm9vbEBnb29n bGUuY29tPj4gd3JvdGU6DQoNCg0KVGhhbmsgeW91IGJvdGggZm9yIHRoZSBhZGRpdGlvbmFsIGNs YXJpZmljYXRpb25zLg0KDQpJIHRoaW5rIHRoaXMgaXMgZ2V0dGluZyBvdXQtb2Ytc2NvcGUgZm9y IHRoZSBQQVdTIHN0YW5kYXJkLCBidXQgdGhlcmUgaXMgbm8gZnV0dXJlLXByb29maW5nIGd1aWRh bmNlIGhlcmUgZWl0aGVyLiAgSWYgYSBkZXZpY2UgYnVpbHQgdG9kYXkga25vd3Mgd2hhdCB0byBk byB3aGVuIGV0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVyYXRpb25SZXN0cmljdGlvbj0iMCIg YW5kIHdoZW4gZXRzaUVuU2ltdWx0YW5lb3VzQ2hhbm5lbE9wZXJhdGlvblJlc3RyaWN0aW9uPSIx Iiwgd2hhdCBzaG91bGQgaXQgZG8gd2hlbiBhIGRhdGFiYXNlIHNlbmRzIGEgdmFsdWUgaXQgZG9l c24ndCByZWNvZ25pemUgaW4gdGhlIGZ1dHVyZT8NCg0KVGhlIHNwZWMgaXMgY2xlYXIgYWJvdXQg d2hhdCB0byBkbyB3aGVuIHRoZSBwYXJhbWV0ZXIgaXMgbm90IHNlbnQgYXQgYWxsLCBidXQgbm8g ZmFsbGJhY2sgYmVoYXZpb3IgaXMgZGVmaW5lZCBmb3Igd2hlbiB0aGUgcGFyYW1ldGVyIHRha2Vz IG9uIG5ldyB2YWx1ZXMgbmV2ZXIgc2VlbiBiZWZvcmUuICBUaGlzIHNlZW1zIHRvIGJlIGNsZWFy bHkgb3V0LW9mLXNjb3BlIG9mIFBBV1MgaXRzZWxmLCBhbmQgYXMgQmVuIHN1Z2dlc3RlZCwgdGhp cyBzaG91bGQgZGVmZXIgdG8gdGhlIEVUU0kgc3BlYyBmb3IgZGV0YWlscy4NCg0KSG93ZXZlciwg dGhpcyBzdGlsbCBsZWF2ZXMgdGhlIHF1ZXN0aW9uIG9mIHdoYXQgIm11c3Qgbm90IGlnbm9yZSIg bWVhbnMuICBEZXZpY2VzIGNhbm5vdCBwcm9jZXNzIHVua25vd24gZnV0dXJlIHZhbHVlcywgc28g aG93IGNhbiB0aGV5IHBvc3NpYmx5ICJub3QgaWdub3JlIiBhIGZpZWxkIHRoYXQgaXMgdW5yZWNv Z25pemFibGUgdG8gdGhlbT8NCg0KQXQgdGhpcyBwb2ludCwgSSB0aGluayBhbGwgd2UgY2FuIHNh eSBpcyB0aGF0IGlmIGEgZGV2aWNlIGVuY291bnRlcnMgZXRzaUVuU2ltdWx0YW5lb3VzQ2hhbm5l bE9wZXJhdGlvblJlc3RyaWN0aW9uPSIxIiwgaXQgbXVzdCBmb2xsb3cgdGhlIEVUU0kgcG93ZXIg Y29uc3RyYWludCBydWxlcy4gIEFueSBvdGhlciBzdGF0ZW1lbnRzIGFib3V0IGRlZmF1bHRpbmcg dG8gIjAiIGFuZCAibXVzdCBub3QgaWdub3JlIiBzZWVtIHN1cGVyZmx1b3VzLg0KDQoNCkFuZHkg TGVlIHwNCg0KIEdvb2dsZSBJbmMuIHwNCg0KIHR2Zm9vbEBnb29nbGUuY29tPG1haWx0bzp0dmZv b2xAZ29vZ2xlLmNvbT4gfA0KDQogNDA4LTIzMC0wNTIyPHRlbDo0MDgtMjMwLTA1MjI+DQoNCg0K T24gV2VkLCBNYXIgNSwgMjAxNCBhdCA3OjI2IFBNLCBCZW5qYW1pbiBBLiBSb2xmZSA8YmVuQGJs aW5kY3JlZWsuY29tPG1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20+PiB3cm90ZToNClRoYW5rcyBW aW5jZW50Lg0KDQpJIHdhcyBhdHRlbXB0aW5nIHRvIGNhcHR1cmUgd2hhdCB5b3UganVzdCBleHBs YWluZWQuIEkgdGhpbmsgdGhhdCBpcyB3aGF0IEkgY2FwdHVyZWQgLSByZWZlcmVuY2UgdGhlIEVU U0kgc3BlYyBmb3Igd2hhdCB0byBkbyB3aGVuIHRoZSB2YWx1ZSBpcyBub3QgemVyby4NCkkgaGFk IGd1ZXNzZWQgdGhhdCB0aGUgaW50ZW50IG9mIGFkZGluZyB0aGlzIHBhcmFtIHdhcyB0byBwcm92 aWRlIGEgd2F5IHRvIHNpZ25hbCB0aGF0IGFuIGFkZGl0aW9uYWwgY29uc3RyYWludCBpcyBhcHBs aWVkIHRvIHRoZSBjaGFubmVscyBiZWluZyB1c2VkLg0KDQpPbiAzLzUvMjAxNCA2OjUwIFBNLCBW aW5jZW50IENoZW4gd3JvdGU6DQpCZW4sIEFuZHksDQoNCkZyb20gd2hhdCBJIHVuZGVyc3Rvb2Qs IHRoZSByZXF1ZXN0IGlzIHRvIGFkZCBhIHBhcmFtZXRlciB0byB0aGUgcHJvdG9jb2wgd2l0aA0K bnVtZXJpYyBzdHJpbmcgdmFsdWVzLCB3aXRoIGEgZGVmYXVsdCB2YWx1ZSBvZiAiMCIuIEl0IGRv ZXMgbm90IGxpbWl0IHRoZSB2YWxpZCB2YWx1ZXMNCnRvICIwIiBvciAiMSIsIGFuZCBkb2VzIG5v dCBhc3NvY2lhdGUgbWVhbmluZyB0byB0aGUgdmFsdWVzLiBUaGUgZGV2aWNlIGJlaGF2aW9yLA0K dXBvbiByZWNlaXB0IG9mIHRoZSB2YWx1ZSwgaXMgZGVmaW5lZCBieSB0aGUgRVRTSSBzcGVjcywg bm90IHRoZSBwcm90b2NvbCBkb2MuDQoNClRoZSAiTVVTVCBOT1QgaWdub3JlIiBpcyBpbnRlbmRl ZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBkZXZpY2UgbXVzdCB1bmRlcnN0YW5kDQp0aGUgdmFsdWUs IGlmIHByZXNlbnQuIFRoZSByaXNrIG9mIG5vdCBwcm9jZXNzaW5nIHRoZSB2YWx1ZSBpcyB0aGF0 LCBpZiBFVFNJIHdlcmUgdG8gYWRkDQphbm90aGVyIHZhbHVlIHRoYXQgaXMgbW9yZSByZXN0cmlj dGl2ZSwgdGhlIGhhcmQtY29kZWQgZGV2aWNlIHdvdWxkIGJlIG91dCBvZg0KY29tcGxpYW5jZS4N Cg0KSSBiZWxpZXZlIHRoZSBpbnRlbnQgaXMgdG8gcHJldmVudCBoYXJkLWNvZGluZyBpbiBkZXZp Y2VzLg0KDQotdmluY2UNCg0KT24gV2VkLCBNYXIgNSwgMjAxNCBhdCA2OjM0IFBNLCBCZW5qYW1p biBBLiBSb2xmZSA8YmVuQGJsaW5kY3JlZWsuY29tPG1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20+ PiB3cm90ZToNCkkgdG9vIHdhcyBzdHJ1Z2dsaW5nIHdpdGggdGhpcyB3b3JkaW5nLiAgIk11c3Qg bm90IiBpcyBvZnRlbiBwcm9ibGVtYXRpYyBmb3IgbWUsIGFuZCBJIHdhcyBzdHJ1Z2dsaW5nIHRv IGZpZ3VyZSBvdXQgaG93IHdlIHZlcmlmeSB0aGF0IGRldmljZSBoYXMgbm90IGlnbm9yZWQgYSBw YXJhbWV0ZXIgd2hlbiB0aGUgdmFsdWUgb2YgdGhlIHBhcmFtdGVyIGhhcyBhIHZhbHVlIHRoYXQg cHJvZHVjZXMgbm8gb2JzZXJ2YWJsZSBiZWhhdmlvciwgc3VjaCBhcyB0aGUgY2FzZSBBbmR5IHNp dGVzIG9yIHRoZSBjYXNlIHdoZXJlIHRoZSB2YWx1ZSBpcyB6ZXJvLiBUaGUgbG9naWMgc2hvdWxk IGJlOg0KDQpJZiAoZXRzaUVuU2ltdWx0YW5lb3VzQ2hhbm5lbE9wZXJhdGlvblJlc3RyaWN0aW9u ID09IDApDQogICBEbyB3aGF0IHlvdSB3ZXJlIGdvaW5nIHRvIGRvIGFueXdheTsNCmVsc2UgaWYg KGV0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVyYXRpb25SZXN0cmljdGlvbiA9PSAxKQ0KICAg RG8gbm90IGV4Y2VlZCB0aGUgbG93ZXIgbGltaXQ7DQoNClRoZSBmaXJzdCBjb25kaXRpb24gbG9v a3MgdG8gbWUgcHJldHR5IG11Y2ggdGhlIGRlZmluaXRpb24gb2YgImlnbm9yZSIgKGJhc2VkIG9u IG15IGV4cGVyaWVuY2UgYXMgYSBwYXJlbnQgOi0pLiAgT25seSB0aGUgc2Vjb25kIGNvbmRpdGlv biBjYW4gcHJvZHVjZSBhbiBvYnNlcnZhYmxlIGNoYW5nZSBpbiB0aGUgZGV2aWNlcyBiZWhhdmlv ci4gU28gaWYgSSBoYXZlIGZpZ3VyZWQgaXQgb3V0IGNvcnJlY3RseSB0aGUgcmVxdWlyZW1lbnQg YmVpbmcgc3RhdGVkICBpczoNCg0KSWYgdGhlIGV0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVy YXRpb25SZXN0cmljdGlvbiAgcGFyYW10ZXIgaXMgcHJvdmlkZWQgYW5kIHRoZSB2YWx1ZSBpcyAx LCAgdGhlIERldmljZSBNVVNUIGNvbXBseSB3aXRoIHRoZSBhZGRpdGlvbmFsIHBvd2VyIHJlc3Ry aWN0aW9ucyB3aGVuIHNpbXVsdGFuZW91cyB0cmFuc21pc3Npb24gb24gbXVsdGlwbGUgY2hhbm5l bCBvcGVyYXRpb24gZGVmaW5lZCBpbiBbcmVmZXJlbmNlXS4NCg0KSXMgdGhhdCByaWdodD8NCg0K LUJlbg0KT24gMy81LzIwMTQgNDoxNyBQTSwgQW5keSBMZWUgd3JvdGU6DQpJIGhhdmUgYSBxdWVz dGlvbiBhYm91dCB0aGUgbmV3IHBhcmFtZXRlciBldHNpRW5TaW11bHRhbmVvdXNDaGFubmVsT3Bl cmF0aW9uUmVzdHJpY3Rpb24gYW5kIHRoZSBwaHJhc2UgIklmIGl0IGlzIHByb3ZpZGVkLCB0aGUg RGV2aWNlIE1VU1QgTk9UIGlnbm9yZSBpdC4iDQoNCkkgY2FuIHVuZGVyc3RhbmQgdGhhdCBpZiB0 aGlzIHBhcmFtZXRlciBpcyBwcm92aWRlZCBhbmQgaXMgc2V0IHRvICIxIiwgdGhhdCB0aGUgZGV2 aWNlIG11c3QgaG9ub3IgaXQgKHJlZHVjZSBvdXRwdXQgcG93ZXIgd2hlbiB1c2luZyBtdWx0aXBs ZSBjaGFubmVscykuDQoNCkJ1dCB3aGF0IGlmIHRoZXJlIGlzIGEgZGV2aWNlIHRoYXQgImhhcmQg Y29kZWQiIHRvIGFsd2F5cyBhcHBseSB0aGUgcG93ZXIgcmVzdHJpY3Rpb24gd2hlbiB1c2luZyBt dWx0aXBsZSBjaGFubmVscz8gIFRoaXMgImNvbnNlcnZhdGl2ZSIgYXBwcm9hY2ggd291bGQgYWx3 YXlzIHJlbWFpbiBiZWxvdyB0aGUgcGVybWl0dGVkIGVtaXNzaW9uIGxpbWl0cyByZWdhcmRsZXNz IG9mIHdoZXRoZXIgdGhpcyBmbGFnIGlzIHNldCB0byAiMSIgb3IgIjAiLg0KDQpBcmUgd2Ugc2F5 aW5nIHRoYXQgaWYgdGhpcyBwYXJhbWV0ZXIgaXMgcHJvdmlkZWQgYW5kIGlzIHNldCB0byAiMCIg dGhhdCB0aGUgZGV2aWNlIG11c3Qgbm90IGFwcGx5IHRoZSBtdWx0aS1jaGFubmVsIHBvd2VyIHJl c3RyaWN0aW9ucz8gIFdoYXQgZG9lcyBpdCBtZWFuIHRvIHNheSAiTVVTVCBOT1QgaWdub3JlIGl0 IiBpbiBzdWNoIGEgY2FzZS4NCg0KDQoNCg0KDQpBbmR5IExlZSB8DQoNCiBHb29nbGUgSW5jLiB8 DQoNCiB0dmZvb2xAZ29vZ2xlLmNvbTxtYWlsdG86dHZmb29sQGdvb2dsZS5jb20+IHwNCg0KIDQw OC0yMzAtMDUyMjx0ZWw6NDA4LTIzMC0wNTIyPg0KDQoNCk9uIFdlZCwgTWFyIDUsIDIwMTQgYXQg NzoxNyBBTSwgVmluY2VudCBDaGVuIDx2Y2hlbkBnb29nbGUuY29tPG1haWx0bzp2Y2hlbkBnb29n bGUuY29tPj4gd3JvdGU6DQpQQVdTLA0KDQpEcmFmdCAxMSBjb250YWlucyB0aGUgZm9sbG93aW5n IGNoYW5nZXM6DQogLSBTZXBhcmF0aW9uIG9mIHByb3RvY29sIGFuZCByZWd1bGF0b3J5IHJlcXVp cmVtZW50cy4gSW4gZXNzZW5jZSwgTUFZLCBNVVNUICwgU0hPVUxEIGhhcyBiZWVuIHJlcGxhY2Vk IHdoZXJlIHRoZSB0ZXh0IGRlc2NyaWJlcyByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyBhbmQgZGV2 aWNlIGJlaGF2aW9yLiBUaGV5IGFyZSByZXBsYWNlZCB3aXRoIGp1c3QgZXhwbGFuYXRvcnkgdGV4 dC4NCg0KIC0gQWRkZWQgdGhlIG5ldyBFVFNJIHBhcmFtZXRlciBmb3Igc2ltdWx0YW5lb3VzIGNo YW5uZWwtb3BlcmF0aW9uIHJlc3RyaWN0aW9ucw0KDQpEaWZmOiBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLXBhd3MtcHJvdG9jb2wtMTAmZGlmZnR5cGU9LS1odG1s JnN1Ym1pdD1HbyUyMSZ1cmwyPWRyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC0xMQ0KDQotdmluY2UN Cg0KT24gV2VkLCBNYXIgNSwgMjAxNCBhdCA3OjA5IEFNLCA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KQSBOZXcgSW50 ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz IGRpcmVjdG9yaWVzLg0KIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFByb3RvY29s IHRvIEFjY2VzcyBXUyBkYXRhYmFzZSBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAg ICAgIFRpdGxlICAgICAgICAgICA6IFByb3RvY29sIHRvIEFjY2VzcyBXaGl0ZS1TcGFjZSAoUEFX UykgRGF0YWJhc2VzDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFZpbmNlbnQgQ2hlbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICBTdWJpciBEYXMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgTGVpIFpodQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBKb2huIE1hbHlhcg0KICAgICAg ICAgICAgICAgICAgICAgICAgICBQZXRlciBKLiBNY0Nhbm4NCiAgICAgICAgRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sLTExLnR4dA0KICAgICAgICBQYWdlcyAgICAg ICAgICAgOiAxMDgNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNC0wMy0wNQ0KDQpBYnN0 cmFjdDoNCiAgIFBvcnRpb25zIG9mIHRoZSByYWRpbyBzcGVjdHJ1bSB0aGF0IGFyZSBhbGxvY2F0 ZWQgdG8gbGljZW5zZWVzIGFyZQ0KICAgYXZhaWxhYmxlIGZvciBub24taW50ZXJmZXJpbmcgdXNl LiAgVGhpcyBhdmFpbGFibGUgc3BlY3RydW0gaXMgY2FsbGVkDQogICAiV2hpdGUgU3BhY2UuIiAg QWxsb3dpbmcgc2Vjb25kYXJ5IHVzZXJzIGFjY2VzcyB0byBhdmFpbGFibGUgc3BlY3RydW0NCiAg ICJ1bmxvY2tzIiBleGlzdGluZyBzcGVjdHJ1bSB0byBtYXhpbWl6ZSBpdHMgdXRpbGl6YXRpb24g YW5kIHRvDQogICBwcm92aWRlIG9wcG9ydHVuaXRpZXMgZm9yIGlubm92YXRpb24sIHJlc3VsdGlu ZyBpbiBncmVhdGVyIG92ZXJhbGwNCiAgIHNwZWN0cnVtIHV0aWxpemF0aW9uLg0KDQogICBPbmUg YXBwcm9hY2ggdG8gbWFuYWdlIHNwZWN0cnVtIHNoYXJpbmcgdXNlcyBkYXRhYmFzZXMgdG8gcmVw b3J0DQogICBzcGVjdHJ1bSBhdmFpbGFiaWxpdHkgdG8gZGV2aWNlcy4gIFRvIGFjaGlldmUgaW50 ZXJvcGVyYWJpbGl0eSBhbW9uZw0KICAgbXVsdGlwbGUgZGV2aWNlcyBhbmQgZGF0YWJhc2VzLCBh IHN0YW5kYXJkaXplZCBwcm90b2NvbCBtdXN0IGJlDQogICBkZWZpbmVkIGFuZCBpbXBsZW1lbnRl ZC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzdWNoIGEgcHJvdG9jb2wsIHRoZQ0KICAgIlByb3Rv Y29sIHRvIEFjY2VzcyBXaGl0ZSBTcGFjZSAoUEFXUykgRGF0YWJhc2VzIi4NCg0KDQpUaGUgSUVU RiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC8NCg0KVGhlcmUn cyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBhd3MtcHJvdG9jb2wtMTENCg0KQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sLTExDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvPi4NCg0KSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1h aWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzDQoNCg0KDQotLQ0KLXZpbmNlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWls dG86cGF3c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KcGF3cyBtYWlsaW5nIGxpc3QNCg0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRm Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFp bGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg0KDQotLQ0KLXZpbmNlDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBhd3MgbWFp bGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRm Lm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQoN Cg0KLS0NCi12aW5jZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCkZv ciBtb3JlIGluZm9ybWF0aW9uIHZpc2l0IHd3dy5vZmNvbS5vcmcudWsNCg0KVGhpcyBlbWFpbCAo YW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhl IHVzZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2Fn ZSBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uDQoNClRoaXMgZW1haWwgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcy4gSG93ZXZlciwgeW91IG9wZW4gYW55IGF0dGFjaG1lbnRzIGF0 IHlvdXIgb3duIHJpc2suDQoNCkFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhl IHZpZXdzIG9yIG9waW5pb25zIG9mIE9mY29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVy d2lzZS4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKg0K --_000_5D3E853BEE49C848BB63047C794C8655B3CEEA1BWOKINTRAEXC02in_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6SGVsdmV0aWNhfQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGlu Z3N9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nc30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hfQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhc30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXN9DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIn0NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lfQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lfQ0KcHJlDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3In0NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bWFyZ2luLXRvcDowY207DQoJbWFy Z2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIn0NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7Zm9udC1mYW1pbHk6Q29uc29sYXN9DQpzcGFuLmhvZW56Yg0KCXt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojNUUyNDND fQ0KLk1zb0NocERlZmF1bHQNCgl7Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIn0NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXttYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbX0NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtfQ0KLS0+DQo8L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5WaW5jZSBhbmQgYWxsLDwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6 IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5Gb3IgY29tcGxldGVuZXNzLCB0aGlz IHdoYXQgdGhlIEVUU0kgc3RhbmRhcmQgc2F5czo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcU2ltdWx0YW5lb3VzIGNo YW5uZWwgb3BlcmF0aW9uIHBvd2VyIHJlc3RyaWN0aW9uIChzZWUgbm90ZSAyKTogQ2FuIHRha2Ug dmFsdWVzIG9mIDAgb3IgMS4gQSB2YWx1ZSBvZiAxIGluZGljYXRlcyB0aGUgZGV2aWNlIHRoYXQg dGhlIHBvd2VyIHJlc3RyaWN0aW9uIGluIGNsYXVzZSA0LjIuMy4yIGFwcGxpZXMsIGEgdmFsdWUg b2YgMCBpbmRpY2F0ZXMgdGhhdCB0aGUgcG93ZXIgcmVzdHJpY3Rpb24gZG9lcyBub3QNCiBhcHBs eS4gVGhlIGRlZmF1bHQgdmFsdWUgaXMgMC48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6IzVFMjQzQyI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5PVEUgMjpJZiB0 aGUgc2ltdWx0YW5lb3VzIGNoYW5uZWwgb3BlcmF0aW9uIHBvd2VyIHJlc3RyaWN0aW9uIHBhcmFt ZXRlciBpcyBub3QgcHJvdmlkZWQsIHRoZSBkZXZpY2Ugc2hhbGwgdXNlIHRoZSBkZWZhdWx0IHZh bHVlIG9mIDAu4oCdPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1RTI0M0Mi PkkgdGhpbmsgdGhlIFBBV1Mgc3BlY2lmaWNhdGlvbiBzaG91bGQgYmUgY292ZXIgdGhlIGZvbGxv d2luZyB0d28gY2FzZXM6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+PHNwYW4gc3R5bGU9IiI+LTxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+VGhlIGRhdGFiYXNlIGRvZXMgbm90IHBy b3ZpZGUgdGhlIHBhcmFtZXRlci4gVGhlIGRldmljZeKAmXMgYmVoYXZpb3VyIHNob3VsZCBiZSDi gJxObyBwb3dlciByZXN0cmljdGlvbuKAnS4gVGhpcyByZXBlYXRzIE5vdGUgMiBpbiBFVFNJIHN0 YW5kYXJkIGJ1dCBpdCBpcyBpbiBteSB2aWV3DQogd29ydGggY2FwdHVyaW5nIGluIFBBV1MgaXRz ZWxmPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0OyB0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzVFMjQzQyI+PHNwYW4gc3R5bGU9IiI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzVFMjQzQyI+VGhlIGRldmljZSByZWNlaXZlcyBhIHZhbHVlIGRpZmZlcmVu dCBmcm9tIDAgb3IgMS4gVGhpcyBpcyBhIGNvbW11bmljYXRpb25zIGVycm9yIG9yIGFuIGVycm9y IGluIHRoZSBkYXRhYmFzZeKAmXMgaW1wbGVtZW50YXRpb24gb2YgUEFXUyB2MTEsIHdoaWNoIHNo b3VsZCBvbmx5DQogYWxsb3cgZm9yIHR3byB2YWx1ZXMuIEkgdGhpbmsgUEFXUyBzaG91bGQgY2xh cmlmeSB0aGF0IHRoZSBkZXZpY2UgYmVoYXZpb3VyIHNob3VsZCBiZSB0aGUgc2FtZSBhcyBhYm92 ZS48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGNvbG9yOiM1RTI0M0MiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+V2hldGhlciBv ciBub3QgdGhlIGRldmljZSB1bmRlcnN0YW5kcyB0aGUgcGFyYW1ldGVyIG5hbWUgbG9va3MgYW4g b2RkIHF1ZXN0aW9uIHRvIG1lLiBJZiBhIGRldmljZSBjbGFpbXMgdG8gYmUgUEFXUyB2MTEgY29t cGxpYW50LCB0aGVuIEkgd291bGQgYXNzdW1lIHRoYXQNCiBpdCBjYW4gZGVjb2RlIGFsbCBwYXJh bWV0ZXJzIHRoYXQgYXJlIGRlZmluZWQgaW4gdGhlIHNwZWMuIE9uIHRoZSBvdGhlciBoYW5kLCBJ IGFncmVlIHRoYXQgd2hldGhlciBvciBub3QgdGhlIGRldmljZSB1bmRlcnN0YW5kcyB3aGF0IGl0 IG11c3QgZG8gaWYgaXQgcmVjZWl2ZXMgYSAxIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgUEFXUy4N Cjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgY29sb3I6IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5EaWZmZXJlbnQg Y291bnRyaWVzIG1heSB3YW50IHRvIGFkZCBuZXcgcG9zc2libGUgdmFsdWVzIHRvIHRoaXMgcGFy YW1ldGVyLCBidXQgdGhpcyB3aWxsIHJlcXVpcmUgYW4gdXBkYXRlIG9mIHRoZSBFVFNJIHN0YW5k YXJkLiBDb21wbGlhbmNlIHdpdGggdGhlIGN1cnJlbnQNCiB2ZXJzaW9uIG9mIHRoZSBFVFNJIHN0 YW5kYXJkIHJlcXVpcmVzIHN1cHBvcnQgb2YgdGhlc2UgdHdvIHZhbHVlcyBvbmx5Ljwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsg Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj5JdCB3YXMgYXNrZWQgaW4gTG9u ZG9uIHdoZXRoZXIgd2UgY291bGQga25vdyB0aGUgdmVyc2lvbiBudW1iZXIgb2YgdGhlIEVUU0kg c3RhbmRhcmQgdGhhdCB3aWxsIGJlIHB1Ymxpc2hlZCBhbmQgY2l0ZWQgaW4gdGhlIE9mZmljaWFs IEpvdXJuYWwuIFRoZSBhbnN3ZXIgaXMNCiBuby4gQW5keSBtZW50aW9uZWQgYSB3b3JrYXJvdW5k IHRoYXQgd291bGQgYWxsb3cgdG8gZm9sbG93IHRoZSB1c3VhbCBJRVRGIGFwcHJvdmFsIHByb2Nl c3MgYW5kIGNoYW5nZSB0aGUgRVRTSSB2ZXJzaW9uIG51bWJlciBhdCBhIGxhdGVyIHN0YWdlIOKA kyB3ZSB3aWxsIG5lZWQgdG8gdXNlIHRoaXMuPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj4mbmJzcDs8L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOiM1RTI0M0MiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzVFMjQzQyI+UmVnYXJkcyw8L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiM1RTI0M0MiPkNlc2FyPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNUUyNDNDIj4mbmJzcDsNCjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6 IzVFMjQzQyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmluY2VudCBDaGVuIFttYWls dG86dmNoZW5AZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMSBNYXJjaCAyMDE0IDE0 OjA0PGJyPg0KPGI+VG86PC9iPiBSb3NlbiwgQnJpYW48YnI+DQo8Yj5DYzo8L2I+IEFuZHkgTGVl OyBwYXdzQGlldGYub3JnOyBDZXNhciBHdXRpZXJyZXo8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtwYXdzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXBhd3MtcHJvdG9jb2wtMTEudHh0PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmR5LCBCcmlhbiw8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBiZWVu IHN0ZXdpbmcgb24gdGhpcyBmb3IgYSB3aGlsZS4gSSBndWVzcyBhdCBpc3N1ZSBhcmUgcmVhbGx5 IDIgdGhpbmdzOjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzEuIFdoZXRo ZXIgb3Igbm90IHRoZSBEZXZpY2UgdW5kZXJzdGFuZHMgdGhlIHBhcmFtZXRlciBuYW1lPC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Mi4gV2hldGhlciBvciBub3QgdGhlIERl dmljZSB1bmRlcnN0YW5kcyB0aGUgcGFyYW1ldGVyIHZhbHVlPC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q3VycmVudGx5LCAmcXVvdDttdXN0IG5vdCBpZ25vcmUgcGFyYW1ldGVyJnF1 b3Q7IGlzIGZvY3VzZWQgb24gMS4gV2hldGhlciBvciBub3QgdGhlIGRldmljZTwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVuZGVyc3RhbmRzIHRoZSB2YWx1ZSBhbmQg d2hhdCBpdCBzaG91bGQgZG8gd2l0aCB1bnJlY29nbml6ZWQgdmFsdWVzPC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgZGVmaW5lZCBieSB0aGUgcmVndWxhdG9yeSBk b21haW4uPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2YgY291cnNlLCB3ZSBjYW4g YmFjayBvZmYgYW5kIHNheSBib3RoIDEgYW5kIDIsIGFzIEJyaWFuIHN1Z2dlc3RzLCBhcmU8L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5sZWZ0IHVwIHRvIHRoZSByZWd1 bGF0b3J5IGRvbWFpbi4gQnV0IG5vdGUgdGhhdCB0aGUgbGFuZ3VhZ2UgaGVyZSBpczwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNwZWNpZmljYWxseSBpbiB0aGUgRVRT SSBzZWN0aW9uLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0gV2lsbCBk aWZmZXJlbnQgY291bnRyaWVzIHRoYXQgYWRvcHQgdGhlIEVUU0kgcnVsZXMgaGF2ZSBkaWZmZXJl bnQgcmVxdWlyZW1lbnRzPzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3VnaHRz PzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi12aW5jZTwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBNYXIg NiwgMjAxNCBhdCAyOjExIEFNLCBSb3NlbiwgQnJpYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpCcmlh bi5Sb3NlbkBuZXVzdGFyLmJpeiIgdGFyZ2V0PSJfYmxhbmsiPkJyaWFuLlJvc2VuQG5ldXN0YXIu Yml6PC9hPiZndDsgd3JvdGU6PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUg dGhhdCB3ZSBjb3VsZCBlbGltaW5hdGUgdGhlIHRleHQgaW4gdGhpcyBkb2MgYW5kIHJlbHkgb24g dGhlIHJlbGV2YW50IHJlZ3VsYXRpb25zIHRvIGZvcmNlIGRldmljZXMgdG8gdXNlIHRoZSBwYXJh bWV0ZXIuICZuYnNwO0FzIGxvbmcgYXMgdGhlIHByb3RvY29sIGNhbiBjYXJyeSB0aGUgdmFsdWUs IHRoZW4gdGhlIHJlZ3MgY2FuIGNvbnRyb2wgd2hhdCB0aGUgZGV2aWNlIG11c3QgZG8uICZuYnNw Ow0KPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VzcGVjdCB0aGUgY29uY2VybiBhYm91dCBu b3QgdW5kZXJzdGFuZGluZyBhIHZhbHVlIGlzIHByb2JhYmx5IGNvdmVyZWQgYnkgdGhlIHNhbWUg c29sdXRpb24uICZuYnNwO0lmIHRoZSBkZXZpY2UgaXMgbGljZW5zZWQgZm9yIGEgcGFydGljdWxh ciByZWd1bGF0b3J5IGRvbWFpbiwgdGhlbiBpdCB3aWxsIGhhdmUgdG8gYmUgYWJsZSB0byBoYW5k bGUgYWxsIHRoZSB2YWx1ZXMgZGVmaW5lZCBmb3IgdGhhdCBkb21haW4uDQogJm5ic3A7VGhlIHBy b3RvY29sIG5lZWRzIGEgc3RhdGVtZW50IHRvIGNvdmVyIGl0IGhvd2V2ZXIuICZuYnNwO1RoZSB1 c3VhbCBhZHZpY2UgaXMg4oCcaWdub3JlIGl04oCdLiAmbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5ic3A7 PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij5Ccmlhbjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDYsIDIwMTQsIGF0IDU6 MTggQU0sIEFuZHkgTGVlICZsdDs8YSBocmVmPSJtYWlsdG86dHZmb29sQGdvb2dsZS5jb20iIHRh cmdldD0iX2JsYW5rIj50dmZvb2xAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgYm90aCBmb3IgdGhlIGFkZGl0aW9uYWwgY2xh cmlmaWNhdGlvbnMuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgaXMgZ2V0 dGluZyBvdXQtb2Ytc2NvcGUgZm9yIHRoZSBQQVdTIHN0YW5kYXJkLCBidXQgdGhlcmUgaXMgbm8g ZnV0dXJlLXByb29maW5nIGd1aWRhbmNlIGhlcmUgZWl0aGVyLiAmbmJzcDtJZiBhIGRldmljZSBi dWlsdCB0b2RheSBrbm93cyB3aGF0IHRvIGRvIHdoZW4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+ZXRzaUVuU2ltdWx0YW5lb3VzQ2hhbm5lbE9wZXJhdGlvblJlc3RyaWN0aW9uPSZx dW90OzAmcXVvdDsNCiBhbmQgd2hlbiZuYnNwO2V0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVy YXRpb25SZXN0cmljdGlvbj0mcXVvdDsxJnF1b3Q7LCB3aGF0IHNob3VsZCBpdCBkbyB3aGVuIGEg ZGF0YWJhc2Ugc2VuZHMgYSB2YWx1ZSBpdCBkb2Vzbid0IHJlY29nbml6ZSZuYnNwO2luIHRoZSBm dXR1cmU/PC9zcGFuPg0KPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UaGUgc3BlYyBpcyBjbGVhciBhYm91dCB3aGF0IHRvIGRvIHdoZW4gdGhlIHBh cmFtZXRlciBpcyBub3Qgc2VudCBhdCBhbGwsIGJ1dCBubyBmYWxsYmFjayBiZWhhdmlvciBpcyBk ZWZpbmVkIGZvciB3aGVuIHRoZSBwYXJhbWV0ZXIgdGFrZXMgb24gbmV3IHZhbHVlcyBuZXZlciBz ZWVuIGJlZm9yZS4NCiAmbmJzcDtUaGlzIHNlZW1zIHRvIGJlIGNsZWFybHkgb3V0LW9mLXNjb3Bl IG9mIFBBV1MgaXRzZWxmLCBhbmQgYXMgQmVuIHN1Z2dlc3RlZCwgdGhpcyBzaG91bGQgZGVmZXIg dG8gdGhlIEVUU0kgc3BlYyBmb3IgZGV0YWlscy48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhvd2V2ZXIsIHRoaXMgc3Rp bGwgbGVhdmVzIHRoZSBxdWVzdGlvbiBvZiB3aGF0ICZxdW90O211c3Qgbm90IGlnbm9yZSZxdW90 OyBtZWFucy4gJm5ic3A7RGV2aWNlcyBjYW5ub3QgcHJvY2VzcyB1bmtub3duIGZ1dHVyZSB2YWx1 ZXMsIHNvIGhvdyBjYW4gdGhleSBwb3NzaWJseSAmcXVvdDtub3QgaWdub3JlJnF1b3Q7IGEgZmll bGQgdGhhdA0KIGlzIHVucmVjb2duaXphYmxlIHRvIHRoZW0/PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdCB0aGlzIHBv aW50LCBJIHRoaW5rIGFsbCB3ZSBjYW4gc2F5IGlzIHRoYXQgaWYgYSBkZXZpY2UgZW5jb3VudGVy cyZuYnNwO2V0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVyYXRpb25SZXN0cmljdGlvbj0mcXVv dDsxJnF1b3Q7LCBpdCZuYnNwO211c3QgZm9sbG93IHRoZSBFVFNJIHBvd2VyIGNvbnN0cmFpbnQg cnVsZXMuICZuYnNwO0FueQ0KIG90aGVyIHN0YXRlbWVudHMgYWJvdXQgZGVmYXVsdGluZyB0byAm cXVvdDswJnF1b3Q7IGFuZCAmcXVvdDttdXN0IG5vdCBpZ25vcmUmcXVvdDsgc2VlbSBzdXBlcmZs dW91cy48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnIgY2xlYXI9ImFsbCI+DQo8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9y ZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0K PHRkIG5vd3JhcD0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQgI0Q1MEYy NSAxLjVwdDsgcGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7IGNvbG9yOiM1NTU1NTUiPkFuZHkgTGVlJm5ic3A7fDwvc3Bhbj48L3A+DQo8L3Rk Pg0KPHRkIG5vd3JhcD0iIiBzdHlsZT0iYm9yZGVyOm5vbmU7IGJvcmRlci10b3A6c29saWQgIzMz NjlFOCAxLjVwdDsgcGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGNvbG9yOiM1NTU1NTUiPiZuYnNwO0dvb2dsZSBJbmMuIHw8L3NwYW4+PC9w Pg0KPC90ZD4NCjx0ZCBub3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNv bGlkICMwMDk5MzkgMS41cHQ7IHBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNTU1NTU1Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9IiI+PGEgaHJlZj0ibWFpbHRvOnR2Zm9vbEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPnR2Zm9vbEBnb29nbGUuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNv bG9yOiM1NTU1NTUiPiZuYnNwO3w8L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBub3dyYXA9IiIgc3R5 bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNvbGlkICNFRUIyMTEgMS41cHQ7IHBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjoj NTU1NTU1Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9IiI+PGEgaHJlZj0idGVsOjQwOC0yMzAt MDUyMiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij40MDgtMjMwLTA1MjI8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgY29sb3I6IzU1NTU1NSI+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0K PC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFdlZCwgTWFyIDUsIDIwMTQgYXQgNzoyNiBQTSwgQmVuamFtaW4gQS4gUm9sZmUgJmx0 OzxhIGhyZWY9Im1haWx0bzpiZW5AYmxpbmRjcmVlay5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5A YmxpbmRjcmVlay5jb208L2E+Jmd0OyB3cm90ZTo8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDsgZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlRoYW5rcyBWaW5jZW50LiZuYnNwOw0KPGJyPg0KPC9zcGFuPjxicj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTMuNXB0OyBmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSB3YXMgYXR0ZW1wdGluZyB0byBjYXB0dXJlIHdo YXQgeW91IGp1c3QgZXhwbGFpbmVkLiBJIHRoaW5rIHRoYXQgaXMgd2hhdCBJIGNhcHR1cmVkIC0g cmVmZXJlbmNlIHRoZSBFVFNJIHNwZWMgZm9yIHdoYXQgdG8gZG8gd2hlbiB0aGUgdmFsdWUgaXMg bm90IHplcm8uDQo8YnI+DQpJIGhhZCBndWVzc2VkIHRoYXQgdGhlIGludGVudCBvZiBhZGRpbmcg dGhpcyBwYXJhbSB3YXMgdG8gcHJvdmlkZSBhIHdheSB0byBzaWduYWwgdGhhdCBhbiBhZGRpdGlv bmFsIGNvbnN0cmFpbnQgaXMgYXBwbGllZCB0byB0aGUgY2hhbm5lbHMgYmVpbmcgdXNlZC48YnI+ DQo8YnI+DQo8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gMy81LzIwMTQgNjo1MCBQTSwgVmluY2VudCBDaGVuIHdyb3RlOjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7IG1hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbiwgQW5keSwgPC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZyb20gd2hhdCBJIHVuZGVyc3Rvb2QsIHRoZSByZXF1ZXN0IGlzIHRvIGFk ZCBhIHBhcmFtZXRlciB0byB0aGUgcHJvdG9jb2wgd2l0aDwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPm51bWVyaWMgc3RyaW5nIHZhbHVlcywgd2l0aCBhIGRlZmF1bHQg dmFsdWUgb2YgJnF1b3Q7MCZxdW90Oy4gSXQgZG9lcyBub3QgbGltaXQgdGhlIHZhbGlkIHZhbHVl czwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvICZxdW90OzAmcXVv dDsgb3IgJnF1b3Q7MSZxdW90OywgYW5kIGRvZXMgbm90IGFzc29jaWF0ZSBtZWFuaW5nIHRvIHRo ZSB2YWx1ZXMuIFRoZSBkZXZpY2UgYmVoYXZpb3IsJm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dXBvbiByZWNlaXB0IG9mIHRoZSB2YWx1ZSwgaXMgZGVmaW5l ZCBieSB0aGUgRVRTSSBzcGVjcywgbm90IHRoZSBwcm90b2NvbCBkb2MuPC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlICZxdW90O01VU1QgTk9UIGlnbm9yZSZxdW90OyBpcyBpbnRl bmRlZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBkZXZpY2UgbXVzdCB1bmRlcnN0YW5kPC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIHZhbHVlLCBpZiBwcmVzZW50LiBU aGUgcmlzayBvZiBub3QgcHJvY2Vzc2luZyB0aGUgdmFsdWUgaXMgdGhhdCwgaWYgRVRTSSB3ZXJl IHRvIGFkZDwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFub3RoZXIg dmFsdWUgdGhhdCBpcyBtb3JlIHJlc3RyaWN0aXZlLCB0aGUgaGFyZC1jb2RlZCBkZXZpY2Ugd291 bGQgYmUgb3V0IG9mPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29t cGxpYW5jZS48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgdGhlIGlu dGVudCBpcyB0byBwcmV2ZW50IGhhcmQtY29kaW5nIGluIGRldmljZXMuPC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LXZpbmNlPC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciA1LCAyMDE0IGF0IDY6MzQg UE0sIEJlbmphbWluIEEuIFJvbGZlICZsdDs8YSBocmVmPSJtYWlsdG86YmVuQGJsaW5kY3JlZWsu Y29tIiB0YXJnZXQ9Il9ibGFuayI+YmVuQGJsaW5kY3JlZWsuY29tPC9hPiZndDsgd3JvdGU6PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHRvbyB3YXMgc3RydWdnbGluZyB3 aXRoIHRoaXMgd29yZGluZy4mbmJzcDsgJnF1b3Q7TXVzdCBub3QmcXVvdDsgaXMgb2Z0ZW4gcHJv YmxlbWF0aWMgZm9yIG1lLCBhbmQgSSB3YXMgc3RydWdnbGluZyB0byBmaWd1cmUgb3V0IGhvdyB3 ZSB2ZXJpZnkgdGhhdCBkZXZpY2UNCiBoYXMgbm90IGlnbm9yZWQgYSBwYXJhbWV0ZXIgd2hlbiB0 aGUgdmFsdWUgb2YgdGhlIHBhcmFtdGVyIGhhcyBhIHZhbHVlIHRoYXQgcHJvZHVjZXMgbm8gb2Jz ZXJ2YWJsZSBiZWhhdmlvciwgc3VjaCBhcyB0aGUgY2FzZSBBbmR5IHNpdGVzIG9yIHRoZSBjYXNl IHdoZXJlIHRoZSB2YWx1ZSBpcyB6ZXJvLiBUaGUgbG9naWMgc2hvdWxkIGJlOg0KPGJyPg0KPGJy Pg0KSWYgKGV0c2lFblNpbXVsdGFuZW91c0NoYW5uZWxPcGVyYXRpb25SZXN0cmljdGlvbiA9PSAw KTxicj4NCiZuYnNwOyZuYnNwOyBEbyB3aGF0IHlvdSB3ZXJlIGdvaW5nIHRvIGRvIGFueXdheTs8 YnI+DQplbHNlIGlmIChldHNpRW5TaW11bHRhbmVvdXNDaGFubmVsT3BlcmF0aW9uUmVzdHJpY3Rp b24gPT0gMSk8YnI+DQombmJzcDsmbmJzcDsgRG8gbm90IGV4Y2VlZCB0aGUgbG93ZXIgbGltaXQ7 PGJyPg0KPGJyPg0KVGhlIGZpcnN0IGNvbmRpdGlvbiBsb29rcyB0byBtZSBwcmV0dHkgbXVjaCB0 aGUgZGVmaW5pdGlvbiBvZiAmcXVvdDtpZ25vcmUmcXVvdDsgKGJhc2VkIG9uIG15IGV4cGVyaWVu Y2UgYXMgYSBwYXJlbnQgOi0pLiZuYnNwOyBPbmx5IHRoZSBzZWNvbmQgY29uZGl0aW9uIGNhbiBw cm9kdWNlIGFuIG9ic2VydmFibGUgY2hhbmdlIGluIHRoZSBkZXZpY2VzIGJlaGF2aW9yLiBTbyBp ZiBJIGhhdmUgZmlndXJlZCBpdCBvdXQgY29ycmVjdGx5IHRoZSByZXF1aXJlbWVudCBiZWluZw0K IHN0YXRlZCZuYnNwOyBpczo8YnI+DQo8YnI+DQpJZiB0aGUgZXRzaUVuU2ltdWx0YW5lb3VzQ2hh bm5lbE9wZXJhdGlvblJlc3RyaWN0aW9uJm5ic3A7IHBhcmFtdGVyIGlzIHByb3ZpZGVkIGFuZCB0 aGUgdmFsdWUgaXMgMSwmbmJzcDsgdGhlIERldmljZSBNVVNUIGNvbXBseSB3aXRoIHRoZSBhZGRp dGlvbmFsIHBvd2VyIHJlc3RyaWN0aW9ucyB3aGVuIHNpbXVsdGFuZW91cyB0cmFuc21pc3Npb24g b24gbXVsdGlwbGUgY2hhbm5lbCBvcGVyYXRpb24gZGVmaW5lZCBpbiBbcmVmZXJlbmNlXS48YnI+ DQo8YnI+DQpJcyB0aGF0IHJpZ2h0Pzxicj4NCjxicj4NCi1CZW48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMy81LzIwMTQgNDoxNyBQTSwg QW5keSBMZWUgd3JvdGU6PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDsgbWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIG5ldyBwYXJhbWV0ZXIgZXRzaUVuU2ltdWx0 YW5lb3VzQ2hhbm5lbE9wZXJhdGlvblJlc3RyaWN0aW9uIGFuZCB0aGUgcGhyYXNlICZxdW90O0lm IGl0Jm5ic3A7aXMgcHJvdmlkZWQsIHRoZSBEZXZpY2UgTVVTVCBOT1QgaWdub3JlIGl0LiZxdW90 Ow0KPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY2FuIHVuZGVyc3RhbmQgdGhhdCBpZiB0aGlz IHBhcmFtZXRlciBpcyBwcm92aWRlZCBhbmQgaXMgc2V0IHRvICZxdW90OzEmcXVvdDssIHRoYXQg dGhlIGRldmljZSBtdXN0IGhvbm9yIGl0IChyZWR1Y2Ugb3V0cHV0IHBvd2VyIHdoZW4gdXNpbmcg bXVsdGlwbGUgY2hhbm5lbHMpLjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB3 aGF0IGlmIHRoZXJlIGlzIGEgZGV2aWNlIHRoYXQgJnF1b3Q7aGFyZCBjb2RlZCZxdW90OyB0byBh bHdheXMgYXBwbHkgdGhlIHBvd2VyIHJlc3RyaWN0aW9uIHdoZW4gdXNpbmcgbXVsdGlwbGUgY2hh bm5lbHM/ICZuYnNwO1RoaXMgJnF1b3Q7Y29uc2VydmF0aXZlJnF1b3Q7IGFwcHJvYWNoIHdvdWxk IGFsd2F5cyByZW1haW4gYmVsb3cgdGhlIHBlcm1pdHRlZCBlbWlzc2lvbiBsaW1pdHMgcmVnYXJk bGVzcyBvZiB3aGV0aGVyIHRoaXMgZmxhZyBpcw0KIHNldCB0byAmcXVvdDsxJnF1b3Q7IG9yICZx dW90OzAmcXVvdDsuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHdlIHNheWlu ZyB0aGF0IGlmIHRoaXMgcGFyYW1ldGVyIGlzIHByb3ZpZGVkIGFuZCBpcyBzZXQgdG8gJnF1b3Q7 MCZxdW90OyB0aGF0IHRoZSBkZXZpY2UgbXVzdCBub3QgYXBwbHkgdGhlIG11bHRpLWNoYW5uZWwg cG93ZXIgcmVzdHJpY3Rpb25zPyAmbmJzcDtXaGF0IGRvZXMgaXQgbWVhbiB0byBzYXkgJnF1b3Q7 TVVTVCBOT1QgaWdub3JlIGl0JnF1b3Q7IGluIHN1Y2ggYSBjYXNlLjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4N Cjx0Ym9keT4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXIt dG9wOnNvbGlkICNENTBGMjUgMS41cHQ7IHBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNTU1NTU1Ij5BbmR5IExlZSZuYnNwO3w8 L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBub3dyYXA9IiIgc3R5bGU9ImJvcmRlcjpub25lOyBib3Jk ZXItdG9wOnNvbGlkICMzMzY5RTggMS41cHQ7IHBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojNTU1NTU1Ij4mbmJzcDtHb29nbGUg SW5jLiB8PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgbm93cmFwPSIiIHN0eWxlPSJib3JkZXI6bm9u ZTsgYm9yZGVyLXRvcDpzb2xpZCAjMDA5OTM5IDEuNXB0OyBwYWRkaW5nOjBjbSAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzU1NTU1NSI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxhIGhyZWY9Im1haWx0bzp0dmZvb2xAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50dmZvb2xAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjojNTU1NTU1Ij4mbmJzcDt8PC9zcGFuPjwvcD4NCjwvdGQ+DQo8 dGQgbm93cmFwPSIiIHN0eWxlPSJib3JkZXI6bm9uZTsgYm9yZGVyLXRvcDpzb2xpZCAjRUVCMjEx IDEuNXB0OyBwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsgY29sb3I6IzU1NTU1NSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSIiPjxhIGhy ZWY9InRlbDo0MDgtMjMwLTA1MjIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+NDA4LTIzMC0w NTIyPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiM1NTU1NTUiPjwvc3Bhbj48L3A+ DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciA1LCAyMDE0IGF0IDc6MTcgQU0sIFZpbmNl bnQgQ2hlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZjaGVuQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj52Y2hlbkBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBBV1MsIDwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EcmFmdCAxMSBjb250 YWlucyB0aGUgZm9sbG93aW5nIGNoYW5nZXM6PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7LSBTZXBhcmF0aW9uIG9mIHByb3RvY29sIGFuZCByZWd1bGF0b3J5 IHJlcXVpcmVtZW50cy4gSW4gZXNzZW5jZSwgTUFZLCBNVVNUICwgU0hPVUxEIGhhcyBiZWVuIHJl cGxhY2VkIHdoZXJlIHRoZSB0ZXh0IGRlc2NyaWJlcyByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyBh bmQgZGV2aWNlIGJlaGF2aW9yLiBUaGV5IGFyZSByZXBsYWNlZCB3aXRoIGp1c3QgZXhwbGFuYXRv cnkgdGV4dC48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstIEFkZGVkIHRo ZSBuZXcgRVRTSSBwYXJhbWV0ZXIgZm9yIHNpbXVsdGFuZW91cyBjaGFubmVsLW9wZXJhdGlvbiBy ZXN0cmljdGlvbnM8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EaWZmOiZuYnNwOzxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtcGF3cy1w cm90b2NvbC0xMCZhbXA7ZGlmZnR5cGU9LS1odG1sJmFtcDtzdWJtaXQ9R28lMjEmYW1wO3VybDI9 ZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sLTExIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sLTEwJmFtcDtkaWZm dHlwZT0tLWh0bWwmYW1wO3N1Ym1pdD1HbyUyMSZhbXA7dXJsMj1kcmFmdC1pZXRmLXBhd3MtcHJv dG9jb2wtMTE8L2E+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LXZpbmNlPC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDUsIDIwMTQgYXQgNzowOSBBTSwgJmx0OzxhIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KJm5ic3A7VGhpcyBkcmFmdCBpcyBh IHdvcmsgaXRlbSBvZiB0aGUgUHJvdG9jb2wgdG8gQWNjZXNzIFdTIGRhdGFiYXNlIFdvcmtpbmcg R3JvdXAgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBQcm90b2NvbCB0byBB Y2Nlc3MgV2hpdGUtU3BhY2UgKFBBV1MpIERhdGFiYXNlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBBdXRob3JzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IFZpbmNlbnQg Q2hlbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJpciBEYXM8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTGVpIFpodTxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKb2huIE1hbHlhcjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBQZXRlciBKLiBNY0Nhbm48YnI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgRmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1p ZXRmLXBhd3MtcHJvdG9jb2wtMTEudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAxMDg8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogMjAxNC0wMy0wNTxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNw OyAmbmJzcDtQb3J0aW9ucyBvZiB0aGUgcmFkaW8gc3BlY3RydW0gdGhhdCBhcmUgYWxsb2NhdGVk IHRvIGxpY2Vuc2VlcyBhcmU8YnI+DQombmJzcDsgJm5ic3A7YXZhaWxhYmxlIGZvciBub24taW50 ZXJmZXJpbmcgdXNlLiAmbmJzcDtUaGlzIGF2YWlsYWJsZSBzcGVjdHJ1bSBpcyBjYWxsZWQ8YnI+ DQombmJzcDsgJm5ic3A7JnF1b3Q7V2hpdGUgU3BhY2UuJnF1b3Q7ICZuYnNwO0FsbG93aW5nIHNl Y29uZGFyeSB1c2VycyBhY2Nlc3MgdG8gYXZhaWxhYmxlIHNwZWN0cnVtPGJyPg0KJm5ic3A7ICZu YnNwOyZxdW90O3VubG9ja3MmcXVvdDsgZXhpc3Rpbmcgc3BlY3RydW0gdG8gbWF4aW1pemUgaXRz IHV0aWxpemF0aW9uIGFuZCB0bzxicj4NCiZuYnNwOyAmbmJzcDtwcm92aWRlIG9wcG9ydHVuaXRp ZXMgZm9yIGlubm92YXRpb24sIHJlc3VsdGluZyBpbiBncmVhdGVyIG92ZXJhbGw8YnI+DQombmJz cDsgJm5ic3A7c3BlY3RydW0gdXRpbGl6YXRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO09u ZSBhcHByb2FjaCB0byBtYW5hZ2Ugc3BlY3RydW0gc2hhcmluZyB1c2VzIGRhdGFiYXNlcyB0byBy ZXBvcnQ8YnI+DQombmJzcDsgJm5ic3A7c3BlY3RydW0gYXZhaWxhYmlsaXR5IHRvIGRldmljZXMu ICZuYnNwO1RvIGFjaGlldmUgaW50ZXJvcGVyYWJpbGl0eSBhbW9uZzxicj4NCiZuYnNwOyAmbmJz cDttdWx0aXBsZSBkZXZpY2VzIGFuZCBkYXRhYmFzZXMsIGEgc3RhbmRhcmRpemVkIHByb3RvY29s IG11c3QgYmU8YnI+DQombmJzcDsgJm5ic3A7ZGVmaW5lZCBhbmQgaW1wbGVtZW50ZWQuICZuYnNw O1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBzdWNoIGEgcHJvdG9jb2wsIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsmcXVvdDtQcm90b2NvbCB0byBBY2Nlc3MgV2hpdGUgU3BhY2UgKFBBV1MpIERhdGFiYXNl cyZxdW90Oy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXBhd3MtcHJvdG9jb2wvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sLzwv YT48YnI+DQo8YnI+DQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDo8YnI+DQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXBh d3MtcHJvdG9jb2wtMTEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXBhd3MtcHJvdG9jb2wtMTE8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC0xMSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtcGF3cy1wcm90b2NvbC0xMTwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+DQp0 b29scy5pZXRmLm9yZzwvYT4uPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvIiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy88L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3M8L2E+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xl YXI9ImFsbCI+DQo8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiM4ODg4ODgiPi0tIDxicj4NCi12aW5jZSA8L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGF3cyBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3ByZT4NCjxwcmU+cGF3cyBtYWlsaW5nIGxpc3Q8 L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5wYXdzQGlldGYub3JnPC9hPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcGF3cyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJy Pg0KLXZpbmNlIDwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnBhd3MgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wYXdzQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcGF3czwvYT48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3M8L2E+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0tIDxicj4NCi12aW5jZSA8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhy Pg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIyIj48YnI+DQoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQpG b3IgbW9yZSBpbmZvcm1hdGlvbiB2aXNpdCB3d3cub2Zjb20ub3JnLnVrPGJyPg0KPGJyPg0KVGhp cyBlbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZCBmb3IgdGhlIHVzZSBvZiB0aGUgYWRkcmVzc2VlIG9ubHkuPGJyPg0KPGJyPg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIG9mIHRoZSBtZXNzYWdlIGFuZCBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbS48YnI+DQo8 YnI+DQpUaGlzIGVtYWlsIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMuIEhvd2V2ZXIsIHlv dSBvcGVuIGFueSBhdHRhY2htZW50cyBhdCB5b3VyIG93biByaXNrLjxicj4NCjxicj4NCkFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bCBzZW5kZXIgYW5kIGRvIG5vdCByZXByZXNlbnQgdGhlIHZpZXdzIG9yIG9waW5pb25zIG9mIE9m Y29tIHVubGVzcyBleHByZXNzbHkgc3RhdGVkIG90aGVyd2lzZS48YnI+DQoqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8YnI+DQo8L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5D3E853BEE49C848BB63047C794C8655B3CEEA1BWOKINTRAEXC02in_-- From nobody Wed Mar 12 13:41:38 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2A21A0496 for ; Wed, 12 Mar 2014 13:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTkDMxIrtueA for ; Wed, 12 Mar 2014 13:41:29 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51B1A0709 for ; Wed, 12 Mar 2014 13:41:28 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so86962qcx.4 for ; Wed, 12 Mar 2014 13:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ntmrBUCo1ORwgRhYLfwYsfCKOfLNFUHqsuUOYWknItc=; b=ht8YEnWbrvnE7Je93Qx6TqKjRY11c/ED0lViKraWH2Jme/UMrAtcUyYDKDTmsrbTHY R5pVHNEaeVoRyuYCz8Q+gTg9FbgnZfGsx2vgpxjvcTWpEB7tIRTovSYSgdJMgVPKULAv asPhMYqblA+7vPJg2Onv3UYqN7jQGghm5032ahCRLsggOpE1/JnYt5J8t7OhnNjv5LDg SZMSWkhSe0nn21OiVUP2caNi6m6No2FHSDajvU0dy4LacZNvv5nXa7xC3fS44YX/AaTB PirfQIBq4KK7ADxmVw0zsMuRlPhmVEcQwA9mDIx7c/FAtctGtvJJ4+5RTtWaxZAYU74B MhLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ntmrBUCo1ORwgRhYLfwYsfCKOfLNFUHqsuUOYWknItc=; b=cWfLAYZBwECOzFPSHoWGvOlAN198ZES0wBDqVS+BQFPgdVaOeQOTEkXGUOxdkv+4fi ucuMefQFDPoouI7HM5Tr/x3tVDBT3xy7/bv2pl0225A2f4ZWHSQzaiMRajgZURTXoZQ4 DiAGhDFJxyuDuuPHgSdm8gu5E0tSzSIYSSYL0rr3rjpYikBTCtU8Kfst+3OgJC6IXdER 0dk+QjcKjLucmnslHZGDdri/1oTnRzsgojxP/xFVb0ql5FYbU7Y3HCyXgphjhL++rLVf EhvokKEH2UpQyKkDSIr60Qn3o69bAWQkv+1c8I+H9xVQMYwnh+ImEZ6kTlhKZVVroESW cAOw== X-Gm-Message-State: ALoCoQlvGtZtPVGZPkV1w9pN/U5bD8ta+BH0ekk/x+h38U5CT4mDYDbIu4j55PHamdoWldcV39a7tAv6ZoBKz/sIkxG0fAwGt2+xLvXPZHxFuKvNHLrwDvr43n7TA5Sba+CO4wfbKMVtp6XZTCsiZNLMBySqHZ6OqS3AI7bEsCFJAbACniC3Cgv5c5PGO/BCMMUeZkQecE6Z MIME-Version: 1.0 X-Received: by 10.140.49.50 with SMTP id p47mr25875132qga.4.1394656882077; Wed, 12 Mar 2014 13:41:22 -0700 (PDT) Received: by 10.229.97.1 with HTTP; Wed, 12 Mar 2014 13:41:21 -0700 (PDT) In-Reply-To: <5D3E853BEE49C848BB63047C794C8655B3CEEA1B@WOK-INTRA-EXC02.intra.ofcom.local> References: <20140305150948.15948.63085.idtracker@ietfa.amsl.com> <5D3E853BEE49C848BB63047C794C8655B3CEEA1B@WOK-INTRA-EXC02.intra.ofcom.local> Date: Wed, 12 Mar 2014 13:41:21 -0700 Message-ID: From: Andy Lee To: Cesar Gutierrez Content-Type: multipart/alternative; boundary=001a11351cfc0a5f1104f46edc60 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/cFUSEnFBczj8fAkBUCG-GV5jD4o Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 20:41:34 -0000 --001a11351cfc0a5f1104f46edc60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with everyone's comments. I think the "must not ignore" wording is what started this conversation because it hints at some kind of behavior that is not in the scope of the protocol itself. It would be nice if we could remove or change just this bit of wording. I believe that all we are really trying to say is that: - etsiEnSimultaneousChannelOperationRestriction is an optional parameter - Its value can only be set to "0" or "1" - If the parameter is missing or malformed in any way (e.g., not "0" or "1"), it defaults to etsiEnSimultaneousChannelOperationRestriction=3D"0" - For details about what to do when this parameter is "0" or "1", refer to ETSI-xxx-yyy If or when the ETSI standard is updated to expand the meaning of this parameter, the ETSI and PAWS specs need to updated to reflect those changes. At that time, there should probably also be consideration given to legacy devices that won't understand the extended meaning of this parameter, and what the recommended handling of those cases should be. Since we don't know if this scenario will ever happen, we don't need to do anything about it right now. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 12, 2014 at 5:21 AM, Cesar Gutierrez < Cesar.Gutierrez@ofcom.org.uk> wrote: > Vince and all, > > > > For completeness, this what the ETSI standard says: > > > > =E2=80=9CSimultaneous channel operation power restriction (see note 2): C= an take > values of 0 or 1. A value of 1 indicates the device that the power > restriction in clause 4.2.3.2 applies, a value of 0 indicates that the > power restriction does not apply. The default value is 0. > > NOTE 2:If the simultaneous channel operation power restriction parameter > is not provided, the device shall use the default value of 0.=E2=80=9D > > > > I think the PAWS specification should be cover the following two cases: > > - The database does not provide the parameter. The device=E2=80=99s > behaviour should be =E2=80=9CNo power restriction=E2=80=9D. This repeats = Note 2 in ETSI > standard but it is in my view worth capturing in PAWS itself > > - The device receives a value different from 0 or 1. This is a > communications error or an error in the database=E2=80=99s implementation= of PAWS > v11, which should only allow for two values. I think PAWS should clarify > that the device behaviour should be the same as above. > > > > Whether or not the device understands the parameter name looks an odd > question to me. If a device claims to be PAWS v11 compliant, then I would > assume that it can decode all parameters that are defined in the spec. On > the other hand, I agree that whether or not the device understands what i= t > must do if it receives a 1 is beyond the scope of PAWS. > > > > Different countries may want to add new possible values to this parameter= , > but this will require an update of the ETSI standard. Compliance with the > current version of the ETSI standard requires support of these two values > only. > > > > It was asked in London whether we could know the version number of the > ETSI standard that will be published and cited in the Official Journal. T= he > answer is no. Andy mentioned a workaround that would allow to follow the > usual IETF approval process and change the ETSI version number at a later > stage =E2=80=93 we will need to use this. > > > > > > Regards, > > Cesar > > > > > > *From:* Vincent Chen [mailto:vchen@google.com] > *Sent:* 11 March 2014 14:04 > *To:* Rosen, Brian > *Cc:* Andy Lee; paws@ietf.org; Cesar Gutierrez > *Subject:* Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt > > > > Andy, Brian, > > > > I've been stewing on this for a while. I guess at issue are really 2 > things: > > > > 1. Whether or not the Device understands the parameter name > > > > 2. Whether or not the Device understands the parameter value > > > > Currently, "must not ignore parameter" is focused on 1. Whether or not th= e > device > > understands the value and what it should do with unrecognized values > > is defined by the regulatory domain. > > > > Of course, we can back off and say both 1 and 2, as Brian suggests, are > > left up to the regulatory domain. But note that the language here is > > specifically in the ETSI section. > > > > - Will different countries that adopt the ETSI rules have different > requirements? > > > > Thoughts? > > > > -vince > > > > On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian > wrote: > > Note that we could eliminate the text in this doc and rely on the relevan= t > regulations to force devices to use the parameter. As long as the protoc= ol > can carry the value, then the regs can control what the device must do. > > > > I suspect the concern about not understanding a value is probably covered > by the same solution. If the device is licensed for a particular > regulatory domain, then it will have to be able to handle all the values > defined for that domain. The protocol needs a statement to cover it > however. The usual advice is =E2=80=9Cignore it=E2=80=9D. > > > > Brian > > > > On Mar 6, 2014, at 5:18 AM, Andy Lee wrote: > > > > Thank you both for the additional clarifications. > > > > I think this is getting out-of-scope for the PAWS standard, but there is > no future-proofing guidance here either. If a device built today knows > what to do when etsiEnSimultaneousChannelOperationRestriction=3D"0" and > when etsiEnSimultaneousChannelOperationRestriction=3D"1", what should it = do > when a database sends a value it doesn't recognize in the future? > > > > The spec is clear about what to do when the parameter is not sent at all, > but no fallback behavior is defined for when the parameter takes on new > values never seen before. This seems to be clearly out-of-scope of PAWS > itself, and as Ben suggested, this should defer to the ETSI spec for > details. > > > > However, this still leaves the question of what "must not ignore" means. > Devices cannot process unknown future values, so how can they possibly > "not ignore" a field that is unrecognizable to them? > > > > At this point, I think all we can say is that if a device > encounters etsiEnSimultaneousChannelOperationRestriction=3D"1", it must > follow the ETSI power constraint rules. Any other statements about > defaulting to "0" and "must not ignore" seem superfluous. > > > > > Andy Lee | > > Google Inc. | > > tvfool@google.com | > > 408-230-0522 > > > > On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe > wrote: > > Thanks Vincent. > > I was attempting to capture what you just explained. I think that is what > I captured - reference the ETSI spec for what to do when the value is not > zero. > I had guessed that the intent of adding this param was to provide a way t= o > signal that an additional constraint is applied to the channels being use= d. > > On 3/5/2014 6:50 PM, Vincent Chen wrote: > > Ben, Andy, > > > > From what I understood, the request is to add a parameter to the protocol > with > > numeric string values, with a default value of "0". It does not limit the > valid values > > to "0" or "1", and does not associate meaning to the values. The device > behavior, > > upon receipt of the value, is defined by the ETSI specs, not the protocol > doc. > > > > The "MUST NOT ignore" is intended to indicate that the device must > understand > > the value, if present. The risk of not processing the value is that, if > ETSI were to add > > another value that is more restrictive, the hard-coded device would be ou= t > of > > compliance. > > > > I believe the intent is to prevent hard-coding in devices. > > > > -vince > > > > On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe > wrote: > > I too was struggling with this wording. "Must not" is often problematic > for me, and I was struggling to figure out how we verify that device has > not ignored a parameter when the value of the paramter has a value that > produces no observable behavior, such as the case Andy sites or the case > where the value is zero. The logic should be: > > If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0) > Do what you were going to do anyway; > else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1) > Do not exceed the lower limit; > > The first condition looks to me pretty much the definition of "ignore" > (based on my experience as a parent :-). Only the second condition can > produce an observable change in the devices behavior. So if I have figure= d > it out correctly the requirement being stated is: > > If the etsiEnSimultaneousChannelOperationRestriction paramter is provide= d > and the value is 1, the Device MUST comply with the additional power > restrictions when simultaneous transmission on multiple channel operation > defined in [reference]. > > Is that right? > > -Ben > > On 3/5/2014 4:17 PM, Andy Lee wrote: > > I have a question about the new parameter > etsiEnSimultaneousChannelOperationRestriction and the phrase "If it is > provided, the Device MUST NOT ignore it." > > > > I can understand that if this parameter is provided and is set to "1", > that the device must honor it (reduce output power when using multiple > channels). > > > > But what if there is a device that "hard coded" to always apply the power > restriction when using multiple channels? This "conservative" approach > would always remain below the permitted emission limits regardless of > whether this flag is set to "1" or "0". > > > > Are we saying that if this parameter is provided and is set to "0" that > the device must not apply the multi-channel power restrictions? What doe= s > it mean to say "MUST NOT ignore it" in such a case. > > > > > > > > > > > Andy Lee | > > Google Inc. | > > tvfool@google.com | > > 408-230-0522 > > > > On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen wrote: > > PAWS, > > > > Draft 11 contains the following changes: > > - Separation of protocol and regulatory requirements. In essence, MAY, > MUST , SHOULD has been replaced where the text describes regulatory > requirements and device behavior. They are replaced with just explanatory > text. > > > > - Added the new ETSI parameter for simultaneous channel-operation > restrictions > > > > Diff: > http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-10&difftype= =3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-11 > > > > -vince > > > > On Wed, Mar 5, 2014 at 7:09 AM, wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol to Access WS database Working > Group of the IETF. > > Title : Protocol to Access White-Space (PAWS) Databases > Authors : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-11.txt > Pages : 108 > Date : 2014-03-05 > > Abstract: > Portions of the radio spectrum that are allocated to licensees are > available for non-interfering use. This available spectrum is called > "White Space." Allowing secondary users access to available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater overall > spectrum utilization. > > One approach to manage spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space (PAWS) Databases". > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-11 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > > -- > -vince > > > _______________________________________________ > 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 > > > > > > -- > -vince > > > > > _______________________________________________ > 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 > > > > > > -- > -vince > > ------------------------------ > > > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use > of the addressee only. > > If you have received this email in error please notify the originator of > the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s > at your own risk. > > Any views expressed in this message are those of the individual sender an= d > do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > > *************************************************************************= ***************************************** > --001a11351cfc0a5f1104f46edc60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with everyone's comments.

I= think the "must not ignore" wording is what started this convers= ation because it hints at some kind of behavior that is not in the scope of= the protocol itself. =C2=A0It would be nice if we could remove or change j= ust this bit of wording.

I believe that all we are really trying to say is that:=
  • etsiEnSimultaneousChannelOperationRestriction is an optional parameter
  • Its va= lue can only be set to "0" or "1"
  • If the parameter is m= issing or malformed in any way (e.g., not "0" or "1"), = it defaults to=C2=A0etsiEnSimultaneousChannelOperationRestriction=3D"0"
  • For details= about what to do when this parameter is "0" or "1", re= fer to ETSI-xxx-yyy
<= br>
If or when the ETS= I standard is updated to expand the meaning of this parameter, the ETSI and= PAWS specs need to updated to reflect those changes. =C2=A0At that time, t= here should probably also be consideration given to legacy devices that won= 't understand the extended meaning of this parameter, and what the reco= mmended handling of those cases should be. =C2=A0Since we don't know if= this scenario will ever happen, we don't need to do anything about it = right now.


Andy Lee=C2=A0|=C2=A0Google Inc. | =C2=A0tvfool@google.= com=C2=A0|=C2=A0408-230-0522


On Wed, Mar 12, 2014 at 5:21 AM, Cesar G= utierrez <Cesar.Gutierrez@ofcom.org.uk> wrote:

Vince and all,

=C2=A0

For completeness, this what= the ETSI standard says:

=C2=A0

=E2=80=9CSimultaneous channel operation power restri= ction (see note 2): Can take values of 0 or 1. A value of 1 indicates the d= evice that the power restriction in clause 4.2.3.2 applies, a value of 0 in= dicates that the power restriction does not apply. The default value is 0.

NOTE 2:If the simultaneous channel operation power r= estriction parameter is not provided, the device shall use the default valu= e of 0.=E2=80=9D

=C2=A0

I think the PAWS specificat= ion should be cover the following two cases:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The database does not provide= the parameter. The device=E2=80=99s behaviour should be =E2=80=9CNo power = restriction=E2=80=9D. This repeats Note 2 in ETSI standard but it is in my = view worth capturing in PAWS itself

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The device receives a value d= ifferent from 0 or 1. This is a communications error or an error in the dat= abase=E2=80=99s implementation of PAWS v11, which should only allow for two values. I think PAWS should clarify that the device behaviou= r should be the same as above.

=C2=A0

Whether or not the device u= nderstands the parameter name looks an odd question to me. If a device clai= ms to be PAWS v11 compliant, then I would assume that it can decode all parameters that are defined in the spec. On the other ha= nd, I agree that whether or not the device understands what it must do if i= t receives a 1 is beyond the scope of PAWS.

=C2=A0

Different countries may wan= t to add new possible values to this parameter, but this will require an up= date of the ETSI standard. Compliance with the current version of the ETSI standard requires support of these two values only.

=C2=A0

It was asked in London whet= her we could know the version number of the ETSI standard that will be publ= ished and cited in the Official Journal. The answer is no. Andy mentioned a workaround that would allow to follow the usual IETF = approval process and change the ETSI version number at a later stage =E2=80= =93 we will need to use this.

=C2=A0

=C2=A0

Regards,

Cesar

=C2=A0

=C2=A0

From: Vincent Chen [mailto:vchen@google.com]
Sent: 11 March 2014 14:04
To: Rosen, Brian
Cc: Andy Lee; paw= s@ietf.org; Cesar Gutierrez
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt

=C2=A0

Andy, Brian,

=C2=A0

I've been stewing on this for a while. I guess a= t issue are really 2 things:

=C2=A0

=C2=A01. Whether or not the Device understands the p= arameter name

=C2=A0

=C2=A02. Whether or not the Device understands the p= arameter value

=C2=A0

Currently, "must not ignore parameter" is = focused on 1. Whether or not the device

understands the value and what it should do with unr= ecognized values

is defined by the regulatory domain.

=C2=A0

Of course, we can back off and say both 1 and 2, as = Brian suggests, are

left up to the regulatory domain. But note that the = language here is

specifically in the ETSI section.

=C2=A0

=C2=A0- Will different countries that adopt the ETSI= rules have different requirements?

=C2=A0

Thoughts?

=C2=A0

-vince

=C2=A0

On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian <Brian.Rosen@neust= ar.biz> wrote:

Note that we could eliminate the text in this doc an= d rely on the relevant regulations to force devices to use the parameter. = =C2=A0As long as the protocol can carry the value, then the regs can contro= l what the device must do. =C2=A0

=C2=A0

I suspect the concern about not understanding a valu= e is probably covered by the same solution. =C2=A0If the device is licensed= for a particular regulatory domain, then it will have to be able to handle= all the values defined for that domain. =C2=A0The protocol needs a statement to cover it however. =C2=A0The usual = advice is =E2=80=9Cignore it=E2=80=9D. =C2=A0

=C2=A0

Brian

=C2=A0

On Mar 6, 2014, at 5:18 AM, Andy Lee <tvfool@google.com> wrote= :



Thank you both for the additional clarifications.

=C2=A0

I think this is getting out-of-scope for the PAWS st= andard, but there is no future-proofing guidance here either. =C2=A0If a de= vice built today knows what to do when=C2=A0etsiEnSimultaneousCh= annelOperationRestriction=3D"0" and when=C2=A0etsiEnSimultaneousChannelOperationRestriction=3D"1"= ;, what should it do when a database sends a value it doesn't recognize= =C2=A0in the future?

=C2=A0

The spec is clear about what to do when t= he parameter is not sent at all, but no fallback behavior is defined for wh= en the parameter takes on new values never seen before. =C2=A0This seems to be clearly out-of-scope of PAWS itself, and as Ben sug= gested, this should defer to the ETSI spec for details.

=C2=A0

However, this still leaves the question o= f what "must not ignore" means. =C2=A0Devices cannot process unkn= own future values, so how can they possibly "not ignore" a field = that is unrecognizable to them?

=C2=A0

At this point, I think all we can say is = that if a device encounters=C2=A0etsiEnSimultaneousChannelOperationRestrict= ion=3D"1", it=C2=A0must follow the ETSI power constraint rules. = =C2=A0Any other statements about defaulting to "0" and "must not igno= re" seem superfluous.


=C2=A0

Andy Lee=C2=A0|

=C2=A0Google Inc. |

=C2=A0tvfool@google.com=C2=A0|<= /span>

=C2=A0408-230-0522

=C2=A0

On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe &l= t;ben@blindcreek.co= m> wrote:

Thanks= Vincent.=C2=A0

I was attempting to capture what you just explained. I think= that is what I captured - reference the ETSI spec for what to do when the = value is not zero.
I had guessed that the intent of adding this param was to provide a way to = signal that an additional constraint is applied to the channels being used.=

On 3/5/2014 6:50 PM, Vincent Chen wrote:

Ben, Andy,

=C2=A0

From what I understood, the request is to add a para= meter to the protocol with

numeric string values, with a default value of "= ;0". It does not limit the valid values

to "0" or "1", and does not asso= ciate meaning to the values. The device behavior,=C2=A0

upon receipt of the value, is defined by the ETSI sp= ecs, not the protocol doc.

=C2=A0

The "MUST NOT ignore" is intended to indic= ate that the device must understand

the value, if present. The risk of not processing th= e value is that, if ETSI were to add

another value that is more restrictive, the hard-cod= ed device would be out of

compliance.

=C2=A0

I believe the intent is to prevent hard-coding in de= vices.

=C2=A0

-vince

=C2=A0

On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe &l= t;ben@blindcreek.co= m> wrote:

I too = was struggling with this wording.=C2=A0 "Must not" is often probl= ematic for me, and I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value tha= t produces no observable behavior, such as the case Andy sites or the case = where the value is zero. The logic should be:

If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0)
=C2=A0=C2=A0 Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1)
=C2=A0=C2=A0 Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore&= quot; (based on my experience as a parent :-).=C2=A0 Only the second condit= ion can produce an observable change in the devices behavior. So if I have = figured it out correctly the requirement being stated=C2=A0 is:

If the etsiEnSimultaneousChannelOperationRestriction=C2=A0 paramter is prov= ided and the value is 1,=C2=A0 the Device MUST comply with the additional p= ower restrictions when simultaneous transmission on multiple channel operat= ion defined in [reference].

Is that right?

-Ben

On 3/5/2014 4:17 PM, Andy Lee wrote:

I have a question about the new parameter etsiEnSimu= ltaneousChannelOperationRestriction and the phrase "If it=C2=A0is prov= ided, the Device MUST NOT ignore it."

=C2=A0

I can understand that if this parameter is provided = and is set to "1", that the device must honor it (reduce output p= ower when using multiple channels).

=C2=A0

But what if there is a device that "hard coded&= quot; to always apply the power restriction when using multiple channels? = =C2=A0This "conservative" approach would always remain below the = permitted emission limits regardless of whether this flag is set to "1" or "0".

=C2=A0

Are we saying that if this parameter is provided and= is set to "0" that the device must not apply the multi-channel p= ower restrictions? =C2=A0What does it mean to say "MUST NOT ignore it&= quot; in such a case.

=C2=A0

=C2=A0

=C2=A0


=C2=A0

Andy Lee=C2=A0|

=C2=A0Google Inc. |

=C2=A0tvfool@google.com=C2=A0|<= /span>

=C2=A0408-230-0522

=C2=A0

On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com>= wrote:

PAWS,

=C2=A0

Draft 11 contains the following changes:

=C2=A0- Separation of protocol and regulatory requir= ements. In essence, MAY, MUST , SHOULD has been replaced where the text des= cribes regulatory requirements and device behavior. They are replaced with = just explanatory text.

=C2=A0

=C2=A0- Added the new ETSI parameter for simultaneou= s channel-operation restrictions

=C2=A0

=C2=A0

-vince

=C2=A0

On Wed, Mar 5, 2014 at 7:09 AM, <internet-drafts@ietf.org&= gt; wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Protocol to Access WS database Worki= ng Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Prot= ocol to Access White-Space (PAWS) Databases
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Vincent C= hen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Subir Das
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Lei Zhu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Malyar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Peter J. McCann
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-iet= f-paws-protocol-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 108<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2014-03-05

Abstract:
=C2=A0 =C2=A0Portions of the radio spectrum that are allocated to licensees= are
=C2=A0 =C2=A0available for non-interfering use. =C2=A0This available spectr= um is called
=C2=A0 =C2=A0"White Space." =C2=A0Allowing secondary users access= to available spectrum
=C2=A0 =C2=A0"unlocks" existing spectrum to maximize its utilizat= ion and to
=C2=A0 =C2=A0provide opportunities for innovation, resulting in greater ove= rall
=C2=A0 =C2=A0spectrum utilization.

=C2=A0 =C2=A0One approach to manage spectrum sharing uses databases to repo= rt
=C2=A0 =C2=A0spectrum availability to devices. =C2=A0To achieve interoperab= ility among
=C2=A0 =C2=A0multiple devices and databases, a standardized protocol must b= e
=C2=A0 =C2=A0defined and implemented. =C2=A0This document defines such a pr= otocol, the
=C2=A0 =C2=A0"Protocol to Access White Space (PAWS) Databases".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-11


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

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

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



=C2=A0

--
-vince


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

=C2=A0

=C2=A0

_______________________________________________
paws mailing list
paws@ietf.org

https://www.ietf.org/mailman/listinfo/paws

=C2=A0


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



=C2=A0

--
-vince

=C2=A0


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

=C2=A0

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

=C2=A0


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



=C2=A0

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************

--001a11351cfc0a5f1104f46edc60-- From nobody Wed Mar 12 13:48:18 2014 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9631A0766 for ; Wed, 12 Mar 2014 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NslIdog3t68 for ; Wed, 12 Mar 2014 13:48:11 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 12A041A0709 for ; Wed, 12 Mar 2014 13:48:10 -0700 (PDT) Received: from stntexhc12.cis.neustar.com (unknown [10.31.58.71]) by stihiron2.va.neustar.com with smtp id 3aa4_06cf_ff8efed7_8771_43c3_a282_7afb6b7696c8; Wed, 12 Mar 2014 16:47:58 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.252]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Wed, 12 Mar 2014 16:47:58 -0400 From: "Rosen, Brian" To: Andy Lee , Cesar Gutierrez Thread-Topic: [paws] I-D Action: draft-ietf-paws-protocol-11.txt Thread-Index: AQHPPjRZQxmF/Cf2KkS7EjNTIiKvuw== Date: Wed, 12 Mar 2014 20:47: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.3.5.130515 x-originating-ip: [10.33.192.36] Content-Type: multipart/alternative; boundary="_000_CF463F1D50A85brianrosenneustarbiz_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/paws/YSByBGw8Xb0I26OXDFbHnKKDvb0 Cc: "paws@ietf.org" Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.15 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, 12 Mar 2014 20:48:16 -0000 --_000_CF463F1D50A85brianrosenneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve think you have it pretty well. The PROTOCOL need not mandate paying attention to the parameter. The regul= ations (and the ETSI standard) do that. The protocol merely transports the= parameter. So just delete the =93must not ignore=94 part. You might even look at the = doc and see if we have any other similar wording we could delete. We need = to make sure MUST, SHOULD, MAY are used appropriately to make sure the prot= ocol itself works. How the device uses the data transported by the protoco= l is specified by the regulator and standards like ETSI. You can use lower= case must/should/may language to illustrate what the parameters are and ho= w they might be used, but MUST/SHOULD/MAY 2119 language should be reserved = for protocol mechanisms. Brian From: Andy Lee > Date: Wednesday, March 12, 2014 at 8:41 PM To: Cesar Gutierrez > Cc: Vincent Chen >, Brian Rosen <= brian.rosen@neustar.biz>, "paws@ietf.org" > Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt I agree with everyone's comments. I think the "must not ignore" wording is what started this conversation bec= ause it hints at some kind of behavior that is not in the scope of the prot= ocol itself. It would be nice if we could remove or change just this bit o= f wording. I believe that all we are really trying to say is that: * etsiEnSimultaneousChannelOperationRestriction is an optional paramete= r * Its value can only be set to "0" or "1" * If the parameter is missing or malformed in any way (e.g., not "0" or= "1"), it defaults to etsiEnSimultaneousChannelOperationRestriction=3D"0" * For details about what to do when this parameter is "0" or "1", refer= to ETSI-xxx-yyy If or when the ETSI standard is updated to expand the meaning of this param= eter, the ETSI and PAWS specs need to updated to reflect those changes. At= that time, there should probably also be consideration given to legacy dev= ices that won't understand the extended meaning of this parameter, and what= the recommended handling of those cases should be. Since we don't know if= this scenario will ever happen, we don't need to do anything about it righ= t now. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 12, 2014 at 5:21 AM, Cesar Gutierrez > wrote: Vince and all, For completeness, this what the ETSI standard says: =93Simultaneous channel operation power restriction (see note 2): Can take = values of 0 or 1. A value of 1 indicates the device that the power restrict= ion in clause 4.2.3.2 applies, a value of 0 indicates that the power restri= ction does not apply. The default value is 0. NOTE 2:If the simultaneous channel operation power restriction parameter is= not provided, the device shall use the default value of 0.=94 I think the PAWS specification should be cover the following two cases: - The database does not provide the parameter. The device=92s behavio= ur should be =93No power restriction=94. This repeats Note 2 in ETSI standa= rd but it is in my view worth capturing in PAWS itself - The device receives a value different from 0 or 1. This is a commun= ications error or an error in the database=92s implementation of PAWS v11, = which should only allow for two values. I think PAWS should clarify that th= e device behaviour should be the same as above. Whether or not the device understands the parameter name looks an odd quest= ion to me. If a device claims to be PAWS v11 compliant, then I would assume= that it can decode all parameters that are defined in the spec. On the oth= er hand, I agree that whether or not the device understands what it must do= if it receives a 1 is beyond the scope of PAWS. Different countries may want to add new possible values to this parameter, = but this will require an update of the ETSI standard. Compliance with the c= urrent version of the ETSI standard requires support of these two values on= ly. It was asked in London whether we could know the version number of the ETSI= standard that will be published and cited in the Official Journal. The ans= wer is no. Andy mentioned a workaround that would allow to follow the usual= IETF approval process and change the ETSI version number at a later stage = =96 we will need to use this. Regards, Cesar From: Vincent Chen [mailto:vchen@google.com] Sent: 11 March 2014 14:04 To: Rosen, Brian Cc: Andy Lee; paws@ietf.org; Cesar Gutierrez Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt Andy, Brian, I've been stewing on this for a while. I guess at issue are really 2 things= : 1. Whether or not the Device understands the parameter name 2. Whether or not the Device understands the parameter value Currently, "must not ignore parameter" is focused on 1. Whether or not the = device understands the value and what it should do with unrecognized values is defined by the regulatory domain. Of course, we can back off and say both 1 and 2, as Brian suggests, are left up to the regulatory domain. But note that the language here is specifically in the ETSI section. - Will different countries that adopt the ETSI rules have different requir= ements? Thoughts? -vince On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian > wrote: Note that we could eliminate the text in this doc and rely on the relevant = regulations to force devices to use the parameter. As long as the protocol= can carry the value, then the regs can control what the device must do. I suspect the concern about not understanding a value is probably covered b= y the same solution. If the device is licensed for a particular regulatory= domain, then it will have to be able to handle all the values defined for = that domain. The protocol needs a statement to cover it however. The usua= l advice is =93ignore it=94. Brian On Mar 6, 2014, at 5:18 AM, Andy Lee > wrote: Thank you both for the additional clarifications. I think this is getting out-of-scope for the PAWS standard, but there is no= future-proofing guidance here either. If a device built today knows what = to do when etsiEnSimultaneousChannelOperationRestriction=3D"0" and when ets= iEnSimultaneousChannelOperationRestriction=3D"1", what should it do when a = database sends a value it doesn't recognize in the future? The spec is clear about what to do when the parameter is not sent at all, b= ut no fallback behavior is defined for when the parameter takes on new valu= es never seen before. This seems to be clearly out-of-scope of PAWS itself= , and as Ben suggested, this should defer to the ETSI spec for details. However, this still leaves the question of what "must not ignore" means. D= evices cannot process unknown future values, so how can they possibly "not = ignore" a field that is unrecognizable to them? At this point, I think all we can say is that if a device encounters etsiEn= SimultaneousChannelOperationRestriction=3D"1", it must follow the ETSI powe= r constraint rules. Any other statements about defaulting to "0" and "must= not ignore" seem superfluous. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe > wrote: Thanks Vincent. I was attempting to capture what you just explained. I think that is what I= captured - reference the ETSI spec for what to do when the value is not ze= ro. I had guessed that the intent of adding this param was to provide a way to = signal that an additional constraint is applied to the channels being used. On 3/5/2014 6:50 PM, Vincent Chen wrote: Ben, Andy, >From what I understood, the request is to add a parameter to the protocol w= ith numeric string values, with a default value of "0". It does not limit the v= alid values to "0" or "1", and does not associate meaning to the values. The device beh= avior, upon receipt of the value, is defined by the ETSI specs, not the protocol d= oc. The "MUST NOT ignore" is intended to indicate that the device must understa= nd the value, if present. The risk of not processing the value is that, if ETS= I were to add another value that is more restrictive, the hard-coded device would be out = of compliance. I believe the intent is to prevent hard-coding in devices. -vince On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe > wrote: I too was struggling with this wording. "Must not" is often problematic fo= r me, and I was struggling to figure out how we verify that device has not = ignored a parameter when the value of the paramter has a value that produce= s no observable behavior, such as the case Andy sites or the case where the= value is zero. The logic should be: If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0) Do what you were going to do anyway; else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1) Do not exceed the lower limit; The first condition looks to me pretty much the definition of "ignore" (bas= ed on my experience as a parent :-). Only the second condition can produce= an observable change in the devices behavior. So if I have figured it out = correctly the requirement being stated is: If the etsiEnSimultaneousChannelOperationRestriction paramter is provided = and the value is 1, the Device MUST comply with the additional power restr= ictions when simultaneous transmission on multiple channel operation define= d in [reference]. Is that right? -Ben On 3/5/2014 4:17 PM, Andy Lee wrote: I have a question about the new parameter etsiEnSimultaneousChannelOperatio= nRestriction and the phrase "If it is provided, the Device MUST NOT ignore = it." I can understand that if this parameter is provided and is set to "1", that= the device must honor it (reduce output power when using multiple channels= ). But what if there is a device that "hard coded" to always apply the power r= estriction when using multiple channels? This "conservative" approach woul= d always remain below the permitted emission limits regardless of whether t= his flag is set to "1" or "0". Are we saying that if this parameter is provided and is set to "0" that the= device must not apply the multi-channel power restrictions? What does it = mean to say "MUST NOT ignore it" in such a case. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen > wrote: PAWS, Draft 11 contains the following changes: - Separation of protocol and regulatory requirements. In essence, MAY, MUS= T , SHOULD has been replaced where the text describes regulatory requiremen= ts and device behavior. They are replaced with just explanatory text. - Added the new ETSI parameter for simultaneous channel-operation restrict= ions Diff: http://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-paws-protocol-10&diffty= pe=3D--html&submit=3DGo%21&url2=3Ddraft-ietf-paws-protocol-11 -vince On Wed, Mar 5, 2014 at 7:09 AM, > wrote: 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 Working Gr= oup of the IETF. Title : Protocol to Access White-Space (PAWS) Databases Authors : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-11.txt Pages : 108 Date : 2014-03-05 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space (PAWS) Databases". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-11 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ 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 -- -vince _______________________________________________ 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 -- -vince ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_CF463F1D50A85brianrosenneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0A897D26FE4AC04BBFF7037C69169D5E@neustar.biz> Content-Transfer-Encoding: quoted-printable
I=92ve think you have it pretty well.

The PROTOCOL need not mandate paying attention to the parameter.  = ;The regulations (and the ETSI standard) do that.  The protocol merely= transports the parameter.

So just delete the =93must not ignore=94 part.  You might even lo= ok at the doc and see if we have any other similar wording we could delete.=  We need to make sure MUST, SHOULD, MAY are used appropriately to mak= e sure the protocol itself works.  How the device uses the data transported by the protocol is specified by the regulator an= d standards like ETSI.  You can use lower case must/should/may languag= e to illustrate what the parameters are and how they might be used, but MUST/SHOULD/MAY 2119 language should be reserved = for protocol mechanisms.

Brian

From: Andy Lee <tvfool@google.com>
Date: Wednesday, March 12, 2014 at = 8:41 PM
To: Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> Cc: Vincent Chen <vchen@google.com>, Brian Rosen <brian.rosen@neustar.biz>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] I-D Action: dra= ft-ietf-paws-protocol-11.txt

I agree with everyone's comments.

I think the "must not ignore" wording is what started this c= onversation because it hints at some kind of behavior that is not in the sc= ope of the protocol itself.  It would be nice if we could remove or ch= ange just this bit of wording.

I believe that all we are really trying to say is that:
  • etsiEn= SimultaneousChannelOperationRestriction is an optional parameter
  • I= ts value can only be set to "0" or "1"
  • <= span style=3D"font-family: arial, sans-serif; font-size: 13px;">If the para= meter is missing or malformed in any way (e.g., not "0" or "= 1"), it defaults to etsiEnSimultaneousChannelOperationRestriction=3D&qu= ot;0"
  • For details about what to do when this parameter is "0= " or "1", refer to ETSI-xxx-yyy

If or when the ETSI standard is update= d to expand the meaning of this parameter, the ETSI and PAWS specs need to = updated to reflect those changes.  At that time, there should probably= also be consideration given to legacy devices that won't understand the extended meaning of this parameter, and = what the recommended handling of those cases should be.  Since we don'= t know if this scenario will ever happen, we don't need to do anything abou= t it right now.


Andy Lee |  Google Inc. |  tvfool@google.= com |  408-230-0522


On Wed, Mar 12, 2014 at 5:21 AM, Cesar Gutierrez= <Cesar= .Gutierrez@ofcom.org.uk> wrote:

Vince and all,

 

For completeness, this what the ETSI s= tandard says:

 

=93Simultaneous channel operation power restriction = (see note 2): Can take values of 0 or 1. A value of 1 indicates the device = that the power restriction in clause 4.2.3.2 applies, a value of 0 indicate= s that the power restriction does not apply. The default value is 0.

NOTE 2:If the simultaneous channel operation power r= estriction parameter is not provided, the device shall use the default valu= e of 0.=94

 

I think the PAWS specification should = be cover the following two cases:

-  &= nbsp;    The database does not provide the parame= ter. The device=92s behaviour should be =93No power restriction=94. This re= peats Note 2 in ETSI standard but it is in my view worth capturing in PAWS itself

-  &= nbsp;    The device receives a value different fr= om 0 or 1. This is a communications error or an error in the database=92s i= mplementation of PAWS v11, which should only allow for two values. I think PAWS should clarify that the device beh= aviour should be the same as above.

 

Whether or not the device understands = the parameter name looks an odd question to me. If a device claims to be PA= WS v11 compliant, then I would assume that it can decode all parameters that are defined in the spec. On the oth= er hand, I agree that whether or not the device understands what it must do= if it receives a 1 is beyond the scope of PAWS.

 

Different countries may want to add ne= w possible values to this parameter, but this will require an update of the= ETSI standard. Compliance with the current version of the ETSI standard requires support of these two values = only.

 

It was asked in London whether we coul= d know the version number of the ETSI standard that will be published and c= ited in the Official Journal. The answer is no. Andy mentioned a workaround that would allow to follow the usual IE= TF approval process and change the ETSI version number at a later stage =96= we will need to use this.

 

 

Regards,

Cesar

 

 

From: Vincent Chen [mailt= o:vchen@google.com]
Sent: 11 March 2014 14:04
To: Rosen, Brian
Cc: Andy Lee; paw= s@ietf.org; Cesar Gutierrez
Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-11.txt

 

Andy, Brian,

 

I've been stewing on this for a while. I guess at is= sue are really 2 things:

 

 1. Whether or not the Device understands the p= arameter name

 

 2. Whether or not the Device understands the p= arameter value

 

Currently, "must not ignore parameter" is = focused on 1. Whether or not the device

understands the value and what it should do with unr= ecognized values

is defined by the regulatory domain.

 

Of course, we can back off and say both 1 and 2, as = Brian suggests, are

left up to the regulatory domain. But note that the = language here is

specifically in the ETSI section.

 

 - Will different countries that adopt the ETSI= rules have different requirements?

 

Thoughts?

 

-vince

 

On Thu, Mar 6, 2014 at 2:11 AM, Rosen, Brian <Brian.Rosen@neust= ar.biz> wrote:

Note that we could eliminate the text in this doc an= d rely on the relevant regulations to force devices to use the parameter. &= nbsp;As long as the protocol can carry the value, then the regs can control= what the device must do.  

 

I suspect the concern about not understanding a valu= e is probably covered by the same solution.  If the device is licensed= for a particular regulatory domain, then it will have to be able to handle= all the values defined for that domain.  The protocol needs a statement to cover it however.  The usual = advice is =93ignore it=94.  

 

Brian

 

On Mar 6, 2014, at 5:18 AM, Andy Lee <tvfool@google.com> wrote= :



Thank you both for the additional clarifications.

 

I think this is getting out-of-scope for the PAWS st= andard, but there is no future-proofing guidance here either.  If a de= vice built today knows what to do when etsiEnSimultaneousChannelOperationRestric= tion=3D"0" and when etsiEnSimultaneousChannelOperationRestriction=3D"1"= ;, what should it do when a database sends a value it doesn't recognize&nbs= p;in the future?

 

The spec is clear about what to do when the parameter is not s= ent at all, but no fallback behavior is defined for when the parameter take= s on new values never seen before.  This seems to be clearly out-of-scope of PAWS itself, and as Ben suggested, thi= s should defer to the ETSI spec for details.

 

However, this still leaves the question of what "must not= ignore" means.  Devices cannot process unknown future values, so= how can they possibly "not ignore" a field that is unrecognizable to them?

 

At this point, I think all we can say is that if a device enco= unters etsiEnSimultaneousChannelOperationRestriction=3D"1", = it must follow the ETSI power constraint rules.  Any other statements about defaulting to "0" and "must not igno= re" seem superfluous.


 

Andy Lee |

 Google Inc. |

 tvfool@g= oogle.com |

 408-230-0522

 

On Wed, Mar 5, 2014 at 7:26 PM, Benjamin A. Rolfe &l= t;ben@blindcreek.co= m> wrote:

Thanks Vincent. 

I wa= s attempting to capture what you just explained. I think that is what I cap= tured - reference the ETSI spec for what to do when the value is not zero.
I had guessed that the intent of adding this param was to provide a way to = signal that an additional constraint is applied to the channels being used.=

On 3/5/2014 6:50 PM, Vincent Chen wrote:

Ben, Andy,

 

From what I understood, the request is to add a para= meter to the protocol with

numeric string values, with a default value of "= ;0". It does not limit the valid values

to "0" or "1", and does not asso= ciate meaning to the values. The device behavior, 

upon receipt of the value, is defined by the ETSI sp= ecs, not the protocol doc.

 

The "MUST NOT ignore" is intended to indic= ate that the device must understand

the value, if present. The risk of not processing th= e value is that, if ETSI were to add

another value that is more restrictive, the hard-cod= ed device would be out of

compliance.

 

I believe the intent is to prevent hard-coding in de= vices.

 

-vince

 

On Wed, Mar 5, 2014 at 6:34 PM, Benjamin A. Rolfe &l= t;ben@blindcreek.co= m> wrote:

I too was struggling with= this wording.  "Must not" is often problematic for me, and = I was struggling to figure out how we verify that device has not ignored a parameter when the value of the paramter has a value tha= t produces no observable behavior, such as the case Andy sites or the case = where the value is zero. The logic should be:

If (etsiEnSimultaneousChannelOperationRestriction =3D=3D 0)
   Do what you were going to do anyway;
else if (etsiEnSimultaneousChannelOperationRestriction =3D=3D 1)
   Do not exceed the lower limit;

The first condition looks to me pretty much the definition of "ignore&= quot; (based on my experience as a parent :-).  Only the second condit= ion can produce an observable change in the devices behavior. So if I have = figured it out correctly the requirement being stated  is:

If the etsiEnSimultaneousChannelOperationRestriction  paramter is prov= ided and the value is 1,  the Device MUST comply with the additional p= ower restrictions when simultaneous transmission on multiple channel operat= ion defined in [reference].

Is that right?

-Ben

On 3/5/2014 4:17 PM, Andy Lee wrote:

I have a question about the new parameter etsiEnSimu= ltaneousChannelOperationRestriction and the phrase "If it is prov= ided, the Device MUST NOT ignore it."

 

I can understand that if this parameter is provided = and is set to "1", that the device must honor it (reduce output p= ower when using multiple channels).

 

But what if there is a device that "hard coded&= quot; to always apply the power restriction when using multiple channels? &= nbsp;This "conservative" approach would always remain below the p= ermitted emission limits regardless of whether this flag is set to "1" or "0".

 

Are we saying that if this parameter is provided and= is set to "0" that the device must not apply the multi-channel p= ower restrictions?  What does it mean to say "MUST NOT ignore it&= quot; in such a case.

 

 

 


 

Andy Lee |

 Google Inc. |

 tvfool@g= oogle.com |

 408-230-0522

 

On Wed, Mar 5, 2014 at 7:17 AM, Vincent Chen <vchen@google.com>= wrote:

PAWS,

 

Draft 11 contains the following changes:

 - Separation of protocol and regulatory requir= ements. In essence, MAY, MUST , SHOULD has been replaced where the text des= cribes regulatory requirements and device behavior. They are replaced with = just explanatory text.

 

 - Added the new ETSI parameter for simultaneou= s channel-operation restrictions

 

 

-vince

 

On Wed, Mar 5, 2014 at 7:09 AM, <internet-drafts@ietf.org&= gt; wrote:


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 Worki= ng Group of the IETF.

        Title           : Prot= ocol to Access White-Space (PAWS) Databases
        Authors         : Vincent C= hen
                     = ;     Subir Das
                     = ;     Lei Zhu
                     = ;     John Malyar
                     = ;     Peter J. McCann
        Filename        : draft-iet= f-paws-protocol-11.txt
        Pages           : 108<= br>         Date            := 2014-03-05

Abstract:
   Portions of the radio spectrum that are allocated to licensees= are
   available for non-interfering use.  This available spectr= um is called
   "White Space."  Allowing secondary users access= to available spectrum
   "unlocks" existing spectrum to maximize its utilizat= ion and to
   provide opportunities for innovation, resulting in greater ove= rall
   spectrum utilization.

   One approach to manage spectrum sharing uses databases to repo= rt
   spectrum availability to devices.  To achieve interoperab= ility among
   multiple devices and databases, a standardized protocol must b= e
   defined and implemented.  This document defines such a pr= otocol, the
   "Protocol to Access White Space (PAWS) Databases".

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-11


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

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

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



 

--
-vince


_______________________________________________
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



 

--
-vince

 


_______________________________________________
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

 


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



 

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************

 --_000_CF463F1D50A85brianrosenneustarbiz_--