From Patrick.Tarpey@ofcom.org.uk Thu Aug 1 04:59:18 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EB821F9F4F for ; Thu, 1 Aug 2013 04:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaibiuUL8P9e for ; Thu, 1 Aug 2013 04:59:13 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) by ietfa.amsl.com (Postfix) with ESMTP id 69F1311E8111 for ; Thu, 1 Aug 2013 04:58:58 -0700 (PDT) Received: from [85.158.139.211:58521] by server-15.bemta-5.messagelabs.com id A4/98-01226-C7D4AF15; Thu, 01 Aug 2013 11:58:52 +0000 X-Env-Sender: Patrick.Tarpey@ofcom.org.uk X-Msg-Ref: server-6.tower-206.messagelabs.com!1375358332!613483!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18050 invoked from network); 1 Aug 2013 11:58:52 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-6.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 1 Aug 2013 11:58:52 -0000 Received: from WOK-INTRA-EXC02.intra.ofcom.local (10.130.130.68) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 1 Aug 2013 12:58:52 +0100 Received: from WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b]) by WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19%15]) with mapi id 14.01.0289.001; Thu, 1 Aug 2013 12:58:51 +0100 From: Patrick Tarpey To: "paws@ietf.org" Thread-Topic: Presentation slides from IETF 87 PAWS working group meeting Thread-Index: Ac6OrnybkmvmtvTCQ/uXOANhwSFlvw== Date: Thu, 1 Aug 2013 11:58:29 +0000 Message-ID: <2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1@WOK-INTRA-EXC01.intra.ofcom.local> 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_2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1WOKINTRAEXC01in_" MIME-Version: 1.0 Subject: [paws] Presentation slides from IETF 87 PAWS working group meeting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 11:59:18 -0000 --_000_2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1WOKINTRAEXC01in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Can someone point me towards the two presentations given at Monday's paws W= G meeting please? (I can't find them on the tools pages). Cheers, Pat :: Patrick Tarpey Technical Advisor 020 7981 3240 07834432016 patrick.tarpey@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk ________________________________ ***************************************************************************= *************************************** 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_2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1WOKINTRAEXC01in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Can someone point me towards the two presentations g= iven at Monday’s paws WG meeting please?

(I can’t find them on the tools pages).

 

Cheers,

 

Pat

 

:: Patrick Tarpey<= /b>
Technical Advisor
020 7981 3240
07834432016
patrick.tarpey@= ofcom.org.uk
 
 
:: Ofcom
Riverside House
2a Southwark Bridge Road
London SE1 9HA
020 7981 3000
www.ofcom.org.uk

 

 



***************************************************************************= ***************************************
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_2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1WOKINTRAEXC01in_-- From Gabor.Bajko@nokia.com Thu Aug 1 05:14:19 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BEE21E80D9 for ; Thu, 1 Aug 2013 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OO-a5PBj0Naj for ; Thu, 1 Aug 2013 05:14:14 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6021E80F0 for ; Thu, 1 Aug 2013 05:13:48 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r71CDfFF007834; Thu, 1 Aug 2013 15:13:42 +0300 Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Aug 2013 15:13:40 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Aug 2013 15:13:40 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.173]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.03.0136.001; Thu, 1 Aug 2013 12:13:40 +0000 From: To: , Thread-Topic: Presentation slides from IETF 87 PAWS working group meeting Thread-Index: Ac6OrnybkmvmtvTCQ/uXOANhwSFlvwAAgFzQ Date: Thu, 1 Aug 2013 12:13:39 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760230FE3D@008-AM1MPN1-006.mgdnok.nokia.com> References: <2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1@WOK-INTRA-EXC01.intra.ofcom.local> In-Reply-To: <2FD4C4C86AF9F24AB55FEEA59BCD435E99FAD8D1@WOK-INTRA-EXC01.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.18.157] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230FE3D008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Aug 2013 12:13:40.0777 (UTC) FILETIME=[8F2C8190:01CE8EB0] X-Nokia-AV: Clean Subject: Re: [paws] Presentation slides from IETF 87 PAWS working group meeting X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:14:19 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230FE3D008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/87/paws.html From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Patrick Tarpey Sent: Thursday, August 01, 2013 4:58 AM To: paws@ietf.org Subject: [paws] Presentation slides from IETF 87 PAWS working group meeting Hi all, Can someone point me towards the two presentations given at Monday's paws W= G meeting please? (I can't find them on the tools pages). Cheers, Pat :: Patrick Tarpey Technical Advisor 020 7981 3240 07834432016 patrick.tarpey@ofcom.org.uk :: Ofcom Riverside House 2a Southwark Bridge Road London SE1 9HA 020 7981 3000 www.ofcom.org.uk ________________________________ ***************************************************************************= *************************************** 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_1ECAFF543A2FED4EA2BEB6CACE08E4760230FE3D008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/87/paws.= html

 

 

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Patrick Tarpey
Sent: Thursday, August 01, 2013 4:58 AM
To: paws@ietf.org
Subject: [paws] Presentation slides from IETF 87 PAWS working group = meeting

 

Hi all,

 

Can someone point me towards th= e two presentations given at Monday’s paws WG meeting please?

(I can’t find them on the= tools pages).

 

Cheers,

 

Pat

 

:: Patrick T= arpey
Technical Advisor
020 7981 3240
07834432016
patrick.tarpey@ofcom.org.uk
 
 
:: Ofcom
Riverside House
2a Southwark Bridge Road
London SE1 9HA
020 7981 3000
www.ofcom.org.uk

 

 

 


***************************************************************************= ***************************************
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.
***************************************************************************= *************************************** List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:18:12 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230FE63008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/proceedings/87/minutes/minutes-87-paws Thanks Pete McCan for taking minutes. - gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230FE63008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/proceedings/87/minutes/minutes-87-pa= ws

 

Thanks Pete McCan for taking minutes.

 

-     &= nbsp;    gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230FE63008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Sat Aug 24 09:43:13 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCC821F8EFE for ; Sat, 24 Aug 2013 09:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP7IhqAEefAJ for ; Sat, 24 Aug 2013 09:43:07 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5981E21F89A6 for ; Sat, 24 Aug 2013 09:43:07 -0700 (PDT) Received: from smtp.mgd.nokia.com ([65.54.30.58]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r7OGh3Fc007739 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Sat, 24 Aug 2013 19:43:04 +0300 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.140]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.03.0136.001; Sat, 24 Aug 2013 16:42:51 +0000 From: To: Thread-Topic: Outcome of the discussions in the Berlin F2F Thread-Index: Ac6gVa/FD9Ql3XbEQXCjkRzaqgUMjQ== Date: Sat, 24 Aug 2013 16:42:50 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476052E5279@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.50.41] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476052E5279008AM1MPN1007mg_" MIME-Version: 1.0 X-Nokia-AV: Clean Subject: [paws] Outcome of the discussions in the Berlin F2F X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 16:43:13 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476052E5279008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Here's a summary of the discussions we had in the Berlin F2F regarding the = solution document: - No comments on the currently defined static database discovery. = Bootstrapping scenarios should however be kept out of the document and incl= uded into the discovery document instead. - No comments on the addition of requestType parameter to support = ETSI, jcard reference update and prefixing the method names with "spectrum.= paws.". If anyone has an issue with these, please send asap a note to the l= ist, otherwise these will go into the new draft version. - Slave device terminology: the current slave device terminology i= s different than the one in RFC6953. Use the terminology from the RFC. Read= ing through the RFC I noticed that the master device terminology is also di= fferent in the two documents, so please use the one from the RFC, and sync = all the other applicable terminologies. - No objection to the addition of -32700 parse error JSON RPC erro= r code - No objections to the name change of the Power spectral density No conclusion on the Spectrum profile encoding, more discussion on the list= is needed. Vince, could you initiate this discussion on the list, by listi= ng the possible encoding options and providing encoding examples. Try to ad= dress the questions recorded in the minutes too. - No objections to adding support for multiple rulesets in a singl= e response. If anyone has an issue with this, please send asap a note to t= he list, otherwise this will go into the new draft version. - Wrt the proposal of having the Spectrum_Use_notify be a pure not= ification, ie it would have an HTTP level response, but that response would= not include a body to be interpreted by the client, there was no objection= in the room. If anyone has an issue with this, please send asap a note to = the list, otherwise this will go into the new draft version. - I cannot recall any conclusion on the using of JSON-REST encodin= g, we need more discussion on the list. - Similarly, no conclusion on whether to use JSON Web Signature fo= r non-repudiation. I expects the proponents to continue the discussion on t= he list. Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476052E5279008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Here’s a summary of the discussions we had in = the Berlin F2F regarding the solution document:

-     &= nbsp;    No comments on the currently defined static databas= e discovery. Bootstrapping scenarios should however be kept out of the docu= ment and included into the discovery document instead.

-     &= nbsp;    No comments on the addition of requestType paramete= r to support ETSI, jcard reference update and prefixing the method names wi= th “spectrum.paws.”. If anyone has an issue with these, please = send asap a note to the list, otherwise these will go into the new draft version.

-     &= nbsp;    Slave device terminology: the current slave device = terminology is different than the one in RFC6953. Use the terminology from = the RFC. Reading through the RFC I noticed that the master device terminolo= gy is also different in the two documents, so please use the one from the RFC, and sync all the other appl= icable terminologies.

-     &= nbsp;    No objection to the addition of -32700 parse error = JSON RPC error code

-     &= nbsp;    No objections to the name change of the Power spect= ral density

 

No conclusion on the Spec= trum profile encoding, more discussion on the list is needed. Vince, could = you initiate this discussion on the list, by listing the possible encoding = options and providing encoding examples. Try to address the questions recorded in the minutes too.

 

-     &= nbsp;    No objections to adding support for multiple rulese= ts in a single response.  If anyone has an issue with this, please sen= d asap a note to the list, otherwise this will go into the new draft versio= n.

-     &= nbsp;    Wrt the proposal of having the Spectrum_Use_notify = be a pure notification, ie it would have an HTTP level response, but that r= esponse would not include a body to be interpreted by the client, there was= no objection in the room. If anyone has an issue with this, please send asap a note to the list, otherwise thi= s will go into the new draft version.

-     &= nbsp;    I cannot recall any conclusion on the using of JSON= -REST encoding, we need more discussion on the list.

-     &= nbsp;    Similarly, no conclusion on whether to use JSON Web= Signature for non-repudiation. I expects the proponents to continue the di= scussion on the list.

 

Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476052E5279008AM1MPN1007mg_-- From mrhead@google.com Sat Aug 24 16:19:49 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3AD11E819F for ; Sat, 24 Aug 2013 16:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFXaKIxt-7B2 for ; Sat, 24 Aug 2013 16:19:48 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E25FF11E819E for ; Sat, 24 Aug 2013 16:19:48 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so2042683pde.37 for ; Sat, 24 Aug 2013 16:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MZjNq7wBkJTQecXZC2l0ExaQ6rVgtK0wRcFUQap8ye8=; b=lyfHMVbaV3QwNUD6fEDmfMdWTbby8mOOpQeiPcr/Qts0j/uxJcQfN2SNm0hJgjhhY3 afd3PaNMWLUG3a0xC7VzSM5askK0cj19RyuE4p8Bf3aIFTW2lWhFQKZqZud268bKLqXI HJqyi0UjuHWcSpJOixOjHxHtck5EmvM6D3OfI2vTI5yyt/NfLBxM6unwnja+5aDtVHGP 9l+SnCFlT6f88jZj98jTmUYqDbogtbd9GVA5IeN/Vy6H+F51A4ZWa3dffOqUR5mPfcRb DhJqBhwDx1aWPIWXqqzuZC4ISWasgnyjOjAFrwEGToBIy66c+NU8tyFwfhxEW5ujZQhp 3QUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=MZjNq7wBkJTQecXZC2l0ExaQ6rVgtK0wRcFUQap8ye8=; b=Y51mehweDS5Gi1VdPBcKRQLLd1M/HNjhWlLLcd0lGgL8rHH/k4aaEy0UO8XCCxmlbG jpPqoFYXjroIupY18ZWr8kr+eslLdLn533pXVJ+AUBSoqjiaysoHrI0GOKqITB8k+Xj0 hQFctBvFNHbAu/8chdtxebK7yldLXYb6p/YcduLJtHQE+hpWX2zKUTXQ/WPEIdy4vdqM AB6dpgUO0a70VB8j9ARvB/Cnv+Kem3Or105gpdxZ4tB7mpei3np4KPGZdsSmXXl4Kvua wvKqcEBu2dI7DBVpmj+ufCuUwDjMOVCk+Btx0mhIUwmrmvrEDV0zwnEZAyLbxjsBwARy LlHQ== X-Gm-Message-State: ALoCoQn21v2+Rv3QnfOQQZMr5CxcIUUDj7TIblNYG83vMkktYBHWk6ka15Tderrdc0FkSm1gFvg1xvXwXASYQDpYWDxLQK3DAER4xf7jWQAVWO7N7+9F/nSVcDg/OlBRmAyNVzfKpaQH/pQM+FNseSG5lN5rTrJh6KBBwVIojfxFK5n8W9J/HlT0eTMoVm/NrYvO/KpWg+91 MIME-Version: 1.0 X-Received: by 10.68.110.98 with SMTP id hz2mr7183019pbb.94.1377386388640; Sat, 24 Aug 2013 16:19:48 -0700 (PDT) Received: by 10.70.69.101 with HTTP; Sat, 24 Aug 2013 16:19:48 -0700 (PDT) Date: Sat, 24 Aug 2013 16:19:48 -0700 Message-ID: From: Michael Head To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d99db69f8c104e4b9c284 Subject: [paws] Spectrum_use_notify as pure notification X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 23:19:49 -0000 --047d7b5d99db69f8c104e4b9c284 Content-Type: text/plain; charset=ISO-8859-1 If spectrum_use_notify is a pure JSON-RPC notification, this could be a problem for our implementation. We can't easily guarantee that the there would be no JSON-RPC response body for this method, but I believe JSON-RPC requires this for notification calls. If clients would ignore any body included in the response, then it would be fine for us, but I suppose the specification would need to make special note of that deviation from the JSON-RPC spec. Thanks, -- mike -- ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --047d7b5d99db69f8c104e4b9c284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If spectrum_use_noti= fy is a pure JSON-RPC notification, this could be a problem for our impleme= ntation.

We can't easily guarantee that the the= re would be no JSON-RPC response body for this method, but I believe JSON-R= PC requires this for notification calls.

If clients would ignore = any body included in the response, then it would be fine for us, but I supp= ose the specification would need to make special note of that deviation fro= m the JSON-RPC spec.

Thanks,
-- mike

--
----------------------------------
Michael R Head <mrhead@google.= com>
+1-201-BLISTER
--047d7b5d99db69f8c104e4b9c284-- From vchen@google.com Sun Aug 25 15:39:43 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7ABE11E8101 for ; Sun, 25 Aug 2013 15:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVUPq9Hrk9Aq for ; Sun, 25 Aug 2013 15:39:43 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA6D11E80FC for ; Sun, 25 Aug 2013 15:39:43 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id f4so3755100iea.23 for ; Sun, 25 Aug 2013 15:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YlVFr7gyMY/I/2iy+vu9OrV39UYas1Rq8xUlpiEtU7k=; b=NYaJpQkeU0UNUClXvYHcHOUMyPe4lGNjwQPPNNWuKyjcpY1DJBtjj9+RnLWSrJwl45 HY2NPax7IHhFRGmlzh/Y1OoDARRz1L4GZmlU0tdikuOr6ALutrfDQKE6RMlJLv8RlGdu nz1QoOtyd8i4VjJXilY5T2um3r/zd53HWmUSMyFzc/KiJ12vLKDm+n3PVKznTCaxz0I6 uRyCzGz05KhbW7BSFsoNJFoyuGv2JUo105FEuCgwtB0UsVBIdOnQpz7Wxda5kQ5Dm9G/ e/y1epAss43PLVO72LBPTs5FPaC4DPzoVnSLF7Ayh7Ru9+aPy7kRAQvYwdTyqU7FBDbl GTMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=YlVFr7gyMY/I/2iy+vu9OrV39UYas1Rq8xUlpiEtU7k=; b=g23BNCabtiH5lzWiCusWGump0Yss74a0nei31cYdloNPTwCurcIOx8wY3ZwUb9sPKV aQkog6S+nZx+9x4fq7a7KD3gTGyaV3pRmtye3g68FdmIMRtlhIfKG0n6Fd3d6Z3TVAgQ CLMwDXqJqUV4Hd4rPEIxIOjFqsSNMNUAleRsx2pol8jGikl0c8jVP8DST0/DVygp9ibk qwCPxYc5twXYJweMK06ce1RyEmIeYloDRUtJckANNT/mIjKP8eHDCxbChl2/XAW8OGyl sGER7cr75VBVr3S8Los1ILVRCttb1014NAxNl521PDNpSgfOIR+pclqYmUYfPm7Ov2tC oDFQ== X-Gm-Message-State: ALoCoQkyCqq7ipHfVkbrSDJJtL5Qu8NMiMMRNo8hFQKS6MqTYFzjUNoMkVlBAagNiwnCzV6a+55ULmKMJb3LY+aQUIyqiy7w1cJhiro7XJttQjMHoDW2oJkQzO/BJ8z/hISD13CVnb+pPbLBfJNV22n7nfIomMi1sYMcdAEQZdVigCw2LF2dHoq4PjDPeo+Mq8zQWfX8d78M MIME-Version: 1.0 X-Received: by 10.50.119.42 with SMTP id kr10mr4848732igb.20.1377470382781; Sun, 25 Aug 2013 15:39:42 -0700 (PDT) Received: by 10.231.113.202 with HTTP; Sun, 25 Aug 2013 15:39:42 -0700 (PDT) Date: Sun, 25 Aug 2013 15:39:42 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=089e013c64aadadc6f04e4cd502b Subject: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 22:39:43 -0000 --089e013c64aadadc6f04e4cd502b Content-Type: text/plain; charset=ISO-8859-1 All, As was brought up before (and at) the F2F, the current encoding for a spectrum profile has a "channelized" view: - List of (startHz, stopHz, power) - Has no ability to specify power level in "unavailable" ranges Example: { "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, } Question: Should we use a more flexible encoding? There were two proposals made on the list: - Option 1: List of (startHz, startPower, stopHz, stopPower) - Option 2: Ordered list of (freqHz, power) At the F2F, we agreed that Option 2 was the more general form. Example: { "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } } This example explicitly specifies the power levels in the unavailable frequency ranges. This example also shows that it's possible to encode "square edges" by having two points using the same frequency, but does allow for "slanted edges" for more gentle roll-offs. -- -vince --089e013c64aadadc6f04e4cd502b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

As was brought up befor= e (and at) the F2F, the current encoding for a spectrum profile
h= as a "channelized" view:
=A0- List of (startHz, stopHz,= power)
=A0- Has no ability to specify power level in "unavailable&= quot; ranges

Example:
=A0 {
= =A0 =A0 "point": { "startHz": 5.18e8, "stopHz"= ;: 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 "point": { "startHz": 5.24e8, "stopHz= ": 5.30e8, "maxPsdDbmPerBw": 36.0 },
=A0 }

Question: Should we use a more flexible encoding?

There were two proposals made on the list:
=A0 - O= ption 1: List of (startHz, startPower, stopHz, stopPower)
=A0= - Option 2: Ordered list of (freqHz, power)

A= t the F2F, we agreed that Option 2 was the more general form.

Example:
=A0 {
=A0 =A0 "po= int": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 = },
=A0 =A0 "point": { "freqHz": 5.18e8, &= quot;maxPsdDbmPerBw": -56.8 },
=A0 =A0 "point": { "freqHz": 5.18e8, "m= axPsdDbmPerBw": 30.0 },
=A0 =A0 "point": { "f= reqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 = "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw"= : 36.0 },
=A0 =A0 "point": { "freqHz": 5.30e8, "maxPsdD= bmPerBw": 36.0 },
=A0 =A0 "point": { "freqHz&= quot;: 5.30e8, "maxPsdDbmPerBw": -56.8 },
=A0 =A0 "= ;point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56= .8 }
=A0 }

This example explicitly spe= cifies the power levels in the unavailable frequency ranges.

=
This example also shows that it's possible to encode "s= quare edges" by having two
points using the same frequency, but does allow for "slanted edge= s" for more gentle roll-offs.

--
-vince
--089e013c64aadadc6f04e4cd502b-- From Ray.Bellis@nominet.org.uk Thu Aug 29 07:00:54 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1433A11E80FA for ; Thu, 29 Aug 2013 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGXZSqOCTl8u for ; Thu, 29 Aug 2013 07:00:49 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 313DA21F9EB0 for ; Thu, 29 Aug 2013 07:00:44 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=bEKzTIwviAiTsxAkgf//e3Xrbv1jp7tEVgdUO/rQR4VPEJ5FoP6vswbH ILthKdj4ucVPIISVG9cmd1UWxfXNQbCMlrw9lQxrWkPkCXVpffRakIZoR dFuSsuyia9kVGOo; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1377784846; x=1409320846; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C78ZSae1m7/N6dSmzlKCvlHRVHRZPZ45czf07scV4fk=; b=3zsEBzqiZIYolyXV9WCi4Aqz3rSTIdAK1lK2yaBCBraC1WpsyhLMFhLc tXW1Pt++r5oxD69h56JSVsJRrxiKyfgCYr2E1Q+0DZTtnBTTv2fXXjz2t 88q41x+fXeCQrYw; X-IronPort-AV: E=Sophos;i="4.89,983,1367967600"; d="scan'208";a="2980889" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 29 Aug 2013 15:00:41 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 15:00:41 +0100 From: Ray Bellis To: Vincent Chen Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msK74A Date: Thu, 29 Aug 2013 14:00:40 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE74F78@wds-exc1.okna.nominet.org.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5C9CD9CB987F7745BC3852FA801817CE@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:00:55 -0000 On 25 Aug 2013, at 23:39, Vincent Chen wrote: > All, >=20 > As was brought up before (and at) the F2F, the current encoding for a spe= ctrum profile > has a "channelized" view: > - List of (startHz, stopHz, power) > - Has no ability to specify power level in "unavailable" ranges >=20 > Example: > { > "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.= 0 }, > "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.= 0 }, > } >=20 > Question: Should we use a more flexible encoding? >=20 > There were two proposals made on the list: > - Option 1: List of (startHz, startPower, stopHz, stopPower) > - Option 2: Ordered list of (freqHz, power) >=20 > At the F2F, we agreed that Option 2 was the more general form. >=20 > Example: > { > "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, > "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, > "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, > "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, > "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, > "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } > } >=20 > This example explicitly specifies the power levels in the unavailable fre= quency ranges. >=20 > This example also shows that it's possible to encode "square edges" by ha= ving two > points using the same frequency, but does allow for "slanted edges" for m= ore gentle roll-offs. I recall discussion of whether interpolated ramps were a good idea, and cla= rification that having the same "stop" and "start" power would be effective= ly the same as having a "startHz" and "stopHz" with a single power level, a= nd thus could also generalise to represent the channelised model. However I recall no discussion of the latter encoding - I thought the propo= sal was to go with your #1 above. BTW, what value of "Bw" would be used to calculate the Psd when the interva= l between points is not constant? Given the OFCOM and ETSI requirement for= both a channel-wide in-block EIRP *and* a 100 kHz spectral density, how wo= uld these be encoded in either of these variations? Also, I don't understand the note about specifying power levels in "unavail= able" ranges. You appear to be suggesting that the "magic value" of -56.8 = dBm above indicates "unavailable", but I can't find the thread that gives t= he rationale for this. It only appears to be necessary because there's no = scope within a single array of "points" to omit a range of frequencies, whe= reas option #1 allows that by explicitly only listing "available" ranges. kind regards, Ray From ben@blindcreek.com Thu Aug 29 09:07:29 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4921F8438 for ; Thu, 29 Aug 2013 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+5BkuGkB3j0 for ; Thu, 29 Aug 2013 09:07:23 -0700 (PDT) Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by ietfa.amsl.com (Postfix) with ESMTP id 479FD11E8118 for ; Thu, 29 Aug 2013 09:04:22 -0700 (PDT) Received: from BLU0-SMTP147 ([65.55.116.72]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Aug 2013 09:04:05 -0700 X-TMN: [j44u3C6lqnn4aGcR1NOWu6FeGDHM1D1e] X-Originating-Email: [ben@blindcreek.com] Message-ID: Received: from [127.0.0.1] ([64.74.213.174]) by BLU0-SMTP147.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Aug 2013 09:04:05 -0700 Date: Thu, 29 Aug 2013 09:04:03 -0700 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: paws@ietf.org References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE74F78@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE74F78@wds-exc1.okna.nominet.org.uk> Content-Type: multipart/alternative; boundary="------------000102050405030501060408" X-Antivirus: avast! (VPS 130829-0, 08/29/2013), Outbound message X-Antivirus-Status: Not-Tested X-OriginalArrivalTime: 29 Aug 2013 16:04:05.0956 (UTC) FILETIME=[63306840:01CEA4D1] Sender: Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:07:29 -0000 --------------000102050405030501060408 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 8/29/2013 7:00 AM, Ray Bellis wrote: > On 25 Aug 2013, at 23:39, Vincent Chen wrote: > >> All, >> >> As was brought up before (and at) the F2F, the current encoding for a spectrum profile >> has a "channelized" view: >> - List of (startHz, stopHz, power) >> - Has no ability to specify power level in "unavailable" ranges >> >> Example: >> { >> "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, >> "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, >> } >> >> Question: Should we use a more flexible encoding? >> >> There were two proposals made on the list: >> - Option 1: List of (startHz, startPower, stopHz, stopPower) >> - Option 2: Ordered list of (freqHz, power) >> >> At the F2F, we agreed that Option 2 was the more general form. >> >> Example: >> { >> "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, >> "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, >> "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, >> "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, >> "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, >> "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, >> "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, >> "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } >> } >> >> This example explicitly specifies the power levels in the unavailable frequency ranges. >> >> This example also shows that it's possible to encode "square edges" by having two >> points using the same frequency, but does allow for "slanted edges" for more gentle roll-offs. > I recall discussion of whether interpolated ramps were a good idea, and clarification that having the same "stop" and "start" power would be effectively the same as having a "startHz" and "stopHz" with a single power level, and thus could also generalise to represent the channelised model. > > However I recall no discussion of the latter encoding - I thought the proposal was to go with your #1 above. > > BTW, what value of "Bw" would be used to calculate the Psd when the interval between points is not constant? Given the OFCOM and ETSI requirement for both a channel-wide in-block EIRP *and* a 100 kHz spectral density, how would these be encoded in either of these variations? > > Also, I don't understand the note about specifying power levels in "unavailable" ranges. You appear to be suggesting that the "magic value" of -56.8 dBm above indicates "unavailable", but I can't find the thread that gives the rationale for this. It only appears to be necessary because there's no scope within a single array of "points" to omit a range of frequencies, whereas option #1 allows that by explicitly only listing "available" ranges. I too was confused by this, and *think* I have figured it out (perhaps incorrectly): "Unavailable" means the channel is not indicated as available at the specific location and time of the query. Thus intentional radiation by a whitespace device is not allowed. In real RF systems, a device transmitting in an available channel near the unavailable channel will have some energy "spill" outside the boundaries of the channel. The white space issued and proposed regulations I have reviewed have different definitions of what is allowed to "spill". I assume (dangerous word alert) that the intention is to allow communication of these different regulatory requirements. FCC regulations do not define "unavailable" but do specify limits on emissions by TVWS devices outside of the TV channel being used, whether it is indicated as "available" or not. This is specified as a level relative to transmit signal level, not absolute dBm (" 72.8 dB below the highest average power in the TV channel in which the device is operating."). For frequencies beyond the TV channel adjacent to channel being used, maximum emissions are defined as field strength (15.209). Representing the later is in dBm requires defining the parameters for conversion; Note FCC received multiple comments suggesting changing the adjacent channel requirement to an absolute level and not relative to an actual level. I don't see how the FCC requirements as issued can be expressed in this format. I might be misinterpreting the intention. Ben > > kind regards, > > Ray > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --------------000102050405030501060408 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 8/29/2013 7:00 AM, Ray Bellis wrote:
On 25 Aug 2013, at 23:39, Vincent Chen <vchen@google.com> wrote:


All,

As was brought up before (and at) the F2F, the current encoding for a spectrum profile
has a "channelized" view:
 - List of (startHz, stopHz, power)
 - Has no ability to specify power level in "unavailable" ranges

Example:
  {
    "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
    "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
  }

Question: Should we use a more flexible encoding?

There were two proposals made on the list:
  - Option 1: List of (startHz, startPower, stopHz, stopPower)
  - Option 2: Ordered list of (freqHz, power)

At the F2F, we agreed that Option 2 was the more general form.

Example:
  {
    "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },
    "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },
    "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },
    "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },
    "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },
    "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },
    "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },
    "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }
  }

This example explicitly specifies the power levels in the unavailable frequency ranges.

This example also shows that it's possible to encode "square edges" by having two
points using the same frequency, but does allow for "slanted edges" for more gentle roll-offs.

I recall discussion of whether interpolated ramps were a good idea, and clarification that having the same "stop" and "start" power would be effectively the same as having a "startHz" and "stopHz" with a single power level, and thus could also generalise to represent the channelised model.

However I recall no discussion of the latter encoding - I thought the proposal was to go with your #1 above.

BTW, what value of "Bw" would be used to calculate the Psd when the interval between points is not constant?  Given the OFCOM and ETSI requirement for both a channel-wide in-block EIRP *and* a 100 kHz spectral density, how would these be encoded in either of these variations?

Also, I don't understand the note about specifying power levels in "unavailable" ranges.  You appear to be suggesting that the "magic value" of -56.8 dBm above indicates "unavailable", but I can't find the thread that gives the rationale for this.  It only appears to be necessary because there's no scope within a single array of "points" to omit a range of frequencies, whereas option #1 allows that by explicitly only listing "available" ranges.
I too was confused by this, and *think* I have figured it out (perhaps incorrectly):
"Unavailable" means the channel is not indicated as available at the specific location and time of the query.  Thus intentional radiation by a whitespace device is not allowed. In real RF systems, a device transmitting in an available channel near the unavailable channel will have some energy "spill" outside the boundaries of the channel.  The white space issued and proposed regulations I have reviewed have different definitions of what is allowed to "spill".  I assume (dangerous word alert) that the intention is to allow communication of these different regulatory requirements. 

FCC regulations do not define "unavailable" but do specify limits on emissions by TVWS devices outside of the TV channel being used, whether it is indicated as "available" or not. This is specified as a level relative to transmit signal level, not absolute dBm (" 72.8 dB below the highest average power in the TV channel in which the device is operating.").  For frequencies beyond the TV channel adjacent to channel being used, maximum emissions are defined as field strength (15.209).    Representing the later is in dBm requires defining the parameters for conversion; Note FCC received multiple comments suggesting changing the adjacent channel requirement to an absolute level and not relative to an actual level.   I don't see how the FCC requirements as issued can be expressed in this format.

I might be misinterpreting the intention.

Ben






kind regards,

Ray

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

--------------000102050405030501060408-- From mrhead@google.com Thu Aug 29 10:46:05 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A4F11E813A for ; Thu, 29 Aug 2013 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INmF88GXyOVl for ; Thu, 29 Aug 2013 10:45:53 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6D62F21F91BF for ; Thu, 29 Aug 2013 10:45:18 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so767426pbb.27 for ; Thu, 29 Aug 2013 10:45:18 -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=dhyCrDq5UlZN8i6s9t28xKsPdR7zBEtVHBr4dzEC6Xc=; b=ZwH6TWGM3V5TKvciEc7uuz5TgDzjWxT1GZCkQ3UBQAb/vXOuKLmn1ZxURaucf8HXXn H/ZejKbBEq8k9Q65gwsoxrgpX3Osg+xpmIvlRU+oTCaSFq1GQ26nWV4Ez8tg3OpGrLRd mYxNtxRVKT5jCAlJmYERinuUNE1TyGjKyyv1sYKc+0NBPIbWa2+EQndz7sEBYDNh0rfa PChx5/5Ou7nimjMcRE4T4nCEZrwJqrxxDyo36KmpGUwPTvLaDprjr7nI8UFMVKM+pcHL 3HRcfRyBu6N+BOn/S5DSG/0ONNWbBOtdx5vbdao1dSgMeL3u3s7+9zBBsZc5XQ9yp8y5 RRGg== 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=dhyCrDq5UlZN8i6s9t28xKsPdR7zBEtVHBr4dzEC6Xc=; b=IrzHIumT8dqbZBXcfgtkP/LMAL69GGIpdi5OvzxqAyIbDV9MYPJUemj0F/kebM0G6t fTss3wWGzbnYsJD4TJUViqj23KQJSt0gWc7tCxW7UR5fXB2M6SnTnu/lkPdKEJAnvAqu NgvoL5TUSfqXinNcChRskSXFTfUltne2/Bepl9VH3FbZC6Cg+2CF6NRPdHHiYEc0ts8Z ahqSUvowb/bXMYZP/KOAzG2WenAXLedn2ZhwFWfzGEtXevsOQg9ddLlYL4wJaGoY4U6R owm7yV9252SX2lDBCieKJZg1iBj2JYPsPFRnNn6pDBx1Mri2tf/gA5rCPJRS1gzvHD0J P8ug== X-Gm-Message-State: ALoCoQnHniY4mwVFx74fhKnJ9Tz65ajTTXp2j9guNWphow4gByYlxziFfv+L9LaWYnZkP5KtKM1hKlge3hSCvdhyvGJquF6SHN2ncIwvhmOyQ0ORmyXXoL39QHEvU+2IGCP9u2xo/nkR9eRDE39wxgNBgNKe1aS+N8wXI/2Q7v23v10M/q98cHqj5kqWNiSFqlYdvVEI5VBJ MIME-Version: 1.0 X-Received: by 10.68.244.200 with SMTP id xi8mr4938535pbc.156.1377798317830; Thu, 29 Aug 2013 10:45:17 -0700 (PDT) Received: by 10.70.69.101 with HTTP; Thu, 29 Aug 2013 10:45:17 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Aug 2013 10:45:17 -0700 Message-ID: From: Michael Head To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=047d7b2e40c84e939104e519ab5e Cc: "paws@ietf.org" Subject: Re: [paws] JSON-RPC vs. JSON-REST X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 17:46:05 -0000 --047d7b2e40c84e939104e519ab5e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the detailed response Dan, I still believe the idea of separating metadata from data in the protocol and defining version and capability negotiation in as would be enabled by a RESTful architecture would yield significant benefits down the road. However, given that nobody has voiced any support for my proposal, and in the interest of moving the draft forward, I'll be happy to retract it. Perhaps we may revisit it when we draft future versions of PAWS. -- mike On Mon, Jul 22, 2013 at 9:49 AM, Harasty, Daniel J wrote: > In considering Michaels input, these are my thoughts:**** > > ** ** > > **=B7 **I agree that the current draft=92s ruleset concept and t= he > number of optional messages (especially *server optional* message) does > not lead to a particularly clean =93negotiation=94. In fact, while it lo= oks > workable, I=92m trying to implement it now, and it =93feels=94 rather clu= msy.*** > * > > **o **To remedy this, I was on the verge of proposing a required set > of =93feature negotiations=94 in the INIT_REQ/RESP messages.**** > > **o **This would also be a good place for servers to initialize any > authentication schemes (if required by the server, and until a standard > certificate-based scheme is specified and adopted). **** > > ** ** > > **=B7 **Moving this negotiation to the HTTP headers (as Michael > proposes) is =96 I suspect =96 workable.**** > > **o **However, it is my personal opinion that that ties the protocol > MORE TIGHTLY to HTTP. **** > > **=A7 **Keeping it =93in band=94 =96 inside the JSON-RPC message itself = =96 allows > for alternate transports: say directly over UDP, or some future > wireless-packet scheme, for example.**** > > **o **And, as and implementer, I=92d rather just deal with the options = of > the protocol =93in band=94, in the protocol itself. **** > > **=A7 **As a server process implementing this protocol, what is the > benefit to me to have to =93go looking=94 for =93how to handle this messa= ge=94 by > looking a bit in the message, and a bit in the HTTP headers?**** > > ** ** > > **=B7 **Yes, interworking of new protocols (or a new version of t= he > =93same=94 protocol) with old ones is always a bit tricky; it is difficul= t to > know NOW everything we=92ll need in the future to make interworking work > smoothly.**** > > **o **However, we already have a perfectly good =93escape hatch=94 in o= ur > current JSON-RPC-oriented approach: at anytime in the future, and new PAW= S > version can define a new method outside of the scope of PAWS 1.0. **** > > **=A7 **To my reading, the old PAWS server would reply with a JSON-RCP > =93method not implemented=94=85 and thus interworking was handled smoothl= y. (It > would be the client=92s prerogative to =93step back=94 through older prot= ocols > that it does implement.)**** > > **o **Also, in some cases, new features/extensions could be =93added=94= to > PAWS (and safely interwork old and new versions) due to the fact that > =93ignoring unexpected fields=94 is REQUIRED.**** > > **o **While I think Michael=92s proposal would offer a different way to > handle version negotiation, I don=92t see that it is =93better=94=85 just= =93a > different way=94. **** > > ** ** > > **=B7 **I agree that the ability to be =93transparently redirecte= d=94 > to a peer (=93federated=94) server is a good idea=85**** > > **o **=85 but, to my reading, that is already accommodated by the Secti= on > 7 text regarding the handling of HTTP Redirects.**** > > ** ** > > **=B7 **As for additional =93mappings=94 from browsers: nothing i= n our > current spec precludes a Database from replying one way to PAWS messages > (in HTTP POST encoded as JSON-RPC), and to HTTP GETs another way.**** > > **o **In fact, we=92re already implementing that, too.**** > > ** ** > > I have other minor comments (maybe even quibbles) with some of Michaels > statements=85 but there is no particular need to go in to all of that now= .** > ** > > ** ** > > I propose the bigger questions is one of general direction. At this poin= t > in time:**** > > **1. **If the rest of the group finds the current =93feature/rulese= t > negotiation=94 scheme is just fine, then perhaps no action is needed.**** > > **2. **If others feel that it is somewhat clunky, do we attempt to > address it by:**** > > **o **=93Fixing it=94 in the current =93style=94: introduce a more clea= r =96 > possibly REQUIRED =96 =93negotiation=94 to the existing JSON-RPC.**** > > **o **Changing direction now to Michaels proposed use of HTTP headers.*= * > ** > > **o **Pursuing BOTH to a sufficient degree of clarity until we can then > pick between them.**** > > ** ** > > Thoughts?**** > > ** ** > > Dan Harasty**** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Michael Head > *Sent:* Monday, July 22, 2013 11:07 AM > *To:* paws@ietf.org > *Subject:* [paws] JSON-RPC vs. JSON-REST**** > > ** ** > > I suppose this will be controversial, but I=92m finding that relying on > JSON-RPC is driving unnecessary coupling among the device, database and > regulatory authority. What I mean by this is that each device/client has = to > know (or detect) something about the database/server it's talking to as > well as the ruleset under which the server will operate.**** > > ** ** > > For example, it is allowed for a device to be implemented so that it only > makes the spectrum.paws.GetSpectrum RPC. However, in order for this to > work, the database it is configured to communicate with must be built to > allow for this: it won=92t work with a database that requires > spectrum.paws.Init and spectrum.paws.Register to be called. The device ca= n > only detect that the database requires these calls by inspecting the erro= r > returned from the GetSpectrum RPC. Furthermore, registration rules > (including which fields are required for proper registration) may be > governed by the regulatory authority. The device needs to know these > details a priori (or possibly detect them by attempting a request and > inspecting error results in an underspecified manner). Much of those > details are determined by the governing ruleset ID, and its precise meani= ng > must be baked into both the database and the device, and they must assume > that their respective semantics will agree.**** > > ** ** > > Some of these issues could be solved by reducing the amount of optionalit= y > (and perhaps some of the optional calls) and requiring a standard sequenc= e > of operations. This may work, but I feel the coupling would still be high= . > Protocol version upgrades (and version negotiation) won=92t be particular= ly > graceful: the client might send a version 1.1 message to the database, an= d > even though the client might also support 1.0, it would get an error > response if the database didn=92t support 1.0.**** > > ** ** > > As a secondary issue, it=92s less natural to expose the service via the w= eb. > JSON-RPC is really only built to allow for programmatic clients.**** > > ** ** > > So.... I=92d rather see a RESTful API that develops application state > through the use of hyperlinked, content-typed message bodies. I suppose > REST-vs-RPC has been discussed quite a bit in general, but I haven=92t se= en > it brought here.**** > > ** ** > > A sketch of the protocol might look like this (I=92m not a RESTful API > expert, so I=92m sure it could be better):**** > > ** ** > > Database publishes a single URL entry point: http://example.com/paws**** > > ** ** > > Device POSTs an application/vnd.paws.init.request-v1+json message to > http://example.com/paws with header**** > > Accept: > application/vnd.paws.init.response-v2+json;application/vnd.paws.init.resp= onse-v1+json > **** > > ** ** > > Database (let=92s say it only supports v1) responds with a > application/paws.init.response-v1+json message which includes the details > in 4.2.2 of the draft -- with, say a cache-control: max-age=3D86400 heade= r -- > but contain an additional field: spectrumResource: > {acceptable-content-type: application/paws.getspectrum.request-v1+json; > required-fields: device/fccId; uri: > http://example.com/paws/available-spectrum}**** > > ** ** > > Device POSTs application/paws.getspectrum.request-v1+json a message with > the FCC id to http://example.com/paws/available-spectrum and header **** > > Accept: application/vnd.paws.notifyuse-v1+json**** > > ** ** > > Database response with an application/paws.getspectrum.response-v1+json > response containing the details specified in 4.4.2 with an additional fie= ld > (if it is required for spectrum use to be notified by the device): > notifyUseToResource {acceptable-content-type: > application/vnd.paws.notifyuse-v1+json, uri: > http://example.com/paws/used-spectrum}.**** > > ** ** > > Device POSTs the selected frequency ranges to the URL and is done.**** > > ** ** > > In this way, the device only needs to know how to negotiate and handle th= e > content types and be configured with the initial URL of the service. Some > interesting benefits:**** > > ** ** > > * The device can connect to the database to ask about any location and -- > if the original database doesn=92t support a given country -- be > transparently directed in the response to another database to file the ge= t > spectrum request. It=92s feasible for any database to federate with other > databases and provide seamless database discovery anywhere whitespace > databases are in use (though this doesn=92t speak to the protocol by whic= h > the databases would discover each other)**** > > * At each POST, the device declares the response version it can handle > which indicates to the server that it can safely use that version and > assume it will be handled by the client according to that particular > version of the spec. Further, it allows the client and server to easily > agree on an upgraded version using the HTTP headers alone without needing > to design such a feature into the protocol itself.**** > > * There=92s a very natural mapping to a web-browser accessible site for > viewing/querying the database contents: visit http://example.com/paws in > a browser, and it sends back a page with a map allowing the user to pick = a > location. URLs like > http://example.com/paws/available-spectrum/latitude=3D45N/longitude=3D75W= might be bookmarked for repeated viewings for a particular location. > **** > > * The initialization response could be augmented with ruleset definitions > that could be cachable, GETtable resources that (perhaps in a future > version of the spec when the breadth of rulesets is better known) allow > devices to seamlessly upgrade their rulesets from the database.**** > > ** ** > > ** ** > > -- **** > > ----------------------------------**** > > Michael R Head **** > > http://www.cs.binghamton.edu/~mike**** > > +1-201-BLISTER**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --047d7b2e40c84e939104e519ab5e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks for the detailed response Dan,

I= still believe the idea of separating metadata from data in the protocol an= d defining version and capability negotiation in as would be enabled by a R= ESTful architecture would yield significant benefits down the road.=A0

However, given that nobody has voiced any support for m= y proposal, and in the interest of moving the draft forward, I'll be ha= ppy to retract it.

Perhaps we may revisit it w= hen we draft future versions of PAWS.

-- mike


<= div class=3D"gmail_quote">On Mon, Jul 22, 2013 at 9:49 AM, Harasty, Daniel = J <dharasty@appcomsci.com> wrote:

In considerin= g Michaels input, these are my thoughts:

=A0<= /p>

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 I= =A0agree that the current draft=92s ruleset concept and the number of opti= onal messages (especially server optional message) does not lead to = a particularly clean =93negotiation=94.=A0 In fact, while it looks workable= , I=92m trying to implement it now, and it =93feels=94 rather clumsy.

o=A0=A0 To remedy this, I was=A0 on the verge of proposing a re= quired set of =93feature negotiations=94 in the INIT_REQ/RESP messages.<= /u>

o=A0=A0 This would also be a good place for servers to initiali= ze any authentication schemes (if required by the server, and until a stand= ard certificate-based scheme is specified and adopted).

=A0<= /p>

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 M= oving this negotiation to the HTTP headers (as Michael proposes) is =96 I s= uspect =96 workable.

o=A0=A0 However, it is my personal opinion that that ties the p= rotocol MORE TIGHTLY to HTTP.=A0

=A7=A0 Keeping it =93in band=94 =96 inside the JSON-RPC message itself =96 al= lows for alternate transports: say directly over UDP, or some future wirele= ss-packet scheme, for example.

o=A0=A0 And, as and implementer, I=92d rather just deal with th= e options of the protocol =93in band=94, in the protocol itself. =

=A7=A0 As a server process implementing this protocol, what is the benefit to= me to have to =93go looking=94 for =93how to handle this message=94 by loo= king a bit in the message, and a bit in the HTTP headers?

=A0<= /p>

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 Y= es, interworking of new protocols (or a new version of the =93same=94 proto= col) with old ones is always a bit tricky; it is difficult to know NOW ever= ything we=92ll need in the future to make interworking work smoothly.

o=A0=A0 However, we already have a perfectly good =93escape hat= ch=94 in our current JSON-RPC-oriented approach: at anytime in the future, = and new PAWS version can define a new method outside of the scope of PAWS 1= .0.

=A7=A0 To my reading, the old PAWS server would reply with a JSON-RCP =93meth= od not implemented=94=85 and thus interworking was handled smoothly.=A0 (It= would be the client=92s prerogative to =93step back=94 through older proto= cols that it does implement.)

o=A0=A0 Also, in some cases, new features/extensions could be = =93added=94 to PAWS (and safely interwork old and new versions) due to the = fact that =93ignoring unexpected fields=94 is REQUIRED.

o=A0=A0 While I think Michael=92s proposal would offer a differ= ent way to handle version negotiation, I don=92t see that it is =93better= =94=85 just =93a different way=94.

=A0<= /p>

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 I= agree that the ability to be =93transparently redirected=94 to a peer (=93= federated=94) server is a good idea=85

o=A0=A0 =85 but, to my reading, that is already accommodated by= the Section 7 text regarding the handling of HTTP Redirects.=

=A0<= /p>

=B7=A0=A0= =A0=A0=A0=A0=A0=A0 A= s for additional =93mappings=94 from browsers: nothing in our current spec = precludes a Database from replying one way to PAWS messages (in HTTP POST e= ncoded as JSON-RPC), and to HTTP GETs another way.

o=A0=A0 In fact, we=92re already implementing that, too.=

=A0<= /p>

I have other minor com= ments (maybe even quibbles) with some of Michaels statements=85 but there i= s no particular need to go in to all of that now.

=A0<= /p>

I propose the bigger q= uestions is one of general direction.=A0 At this point in time:

1.=A0=A0=A0=A0=A0=A0 If the rest of the group finds the current =93featu= re/ruleset negotiation=94 scheme is just fine, then perhaps no action is ne= eded.

2.=A0=A0=A0=A0=A0=A0 If others feel that it is somewhat clunky, do we at= tempt to address it by:

o=A0=A0 =93Fixing it=94 in the current =93style=94: introduce a= more clear =96 possibly REQUIRED =96 =A0=93negotiation=94 to the existing = JSON-RPC.

o=A0=A0 Changing direction now to Michaels proposed use of HTTP= headers.

o=A0=A0 Pursuing BOTH to a sufficient degree of clarity until w= e can then pick between them.

=A0<= /p>

Thoughts?

=A0<= /p>

Dan Harasty<= /u>

=A0<= /p>

=A0

From: paws-bounces@i= etf.org [mailto:paws-bounces@ietf.org] On Behalf Of Michael Head
Sent: Monday, July 22, 2013 11:07 AM
To: paws@ietf.org
Subject: [paw= s] JSON-RPC vs. JSON-REST

=A0

I suppose this will be controversial, but I= =92m finding that relying on JSON-RPC is driving unnecessary coupling among= the device, database and regulatory authority. What I mean by this is that= each device/client has to know (or detect) something about the database/se= rver it's talking to as well as the ruleset under which the server will= operate.

=A0

For example, it is allowed for a device to be imp= lemented so that it only makes the spectrum.paws.GetSpectrum RPC. However, = in order for this to work, the database it is configured to communicate wit= h must be built to allow for this: it won=92t work with a database that req= uires spectrum.paws.Init and spectrum.paws.Register to be called. The devic= e can only detect that the database requires these calls by inspecting the = error returned from the GetSpectrum RPC. Furthermore, registration rules (i= ncluding which fields are required for proper registration) may be governed= by the regulatory authority. The device needs to know these details a prio= ri (or possibly detect them by attempting a request and inspecting error re= sults in an underspecified manner). Much of those details are determined by= the governing ruleset ID, and its precise meaning must be baked into both = the database and the device, and they must assume that their respective sem= antics will agree.

=A0

Some of these issues could be solved by reducing = the amount of optionality (and perhaps some of the optional calls) and requ= iring a standard sequence of operations. This may work, but I feel the coup= ling would still be high. Protocol version upgrades (and version negotiatio= n) won=92t be particularly graceful: the client might send a version 1.1 me= ssage to the database, and even though the client might also support 1.0, i= t would get an error response if the database didn=92t support 1.0.<= u>

=A0

As a secondary issue, it=92s less natural to expo= se the service via the web. JSON-RPC is really only built to allow for prog= rammatic clients.

=A0

So.... I=92d rather see a RESTful API that develo= ps application state through the use of hyperlinked, content-typed message = bodies. I suppose REST-vs-RPC has been discussed quite a bit in general, bu= t I haven=92t seen it brought here.

=A0

A sketch of the protocol might look like this (I= =92m not a RESTful API expert, so I=92m sure it could be better):=

=A0

Database publishes a single URL entry point: http://= example.com/paws

=A0

Device POSTs an application/vnd.paws.init.request= -v1+json message to http://example.com/paws with header<= /span>

Accept: applicatio= n/vnd.paws.init.response-v2+json;application/vnd.paws.init.response-v1+json=

=A0

Database (let=92s say it only supports v1) respon= ds with a application/paws.init.response-v1+json message which includes the= details in 4.2.2 of the draft -- with, say a cache-control: max-age=3D8640= 0 header -- but contain an additional field: spectrumResource: {acceptable-= content-type: application/paws.getspectrum.request-v1+json; required-fields= : device/fccId; uri: http://example.com/paws/available-spec= trum}

=A0

Device POSTs application/paws.getspectrum.request= -v1+json a message with the FCC id to http://example.com/pa= ws/available-spectrum and header

Accept: applicatio= n/vnd.paws.notifyuse-v1+json

=A0

Database response = with an application/paws.getspectrum.response-v1+json response containing t= he details specified in 4.4.2 with an additional field (if it is required f= or spectrum use to be notified by the device): notifyUseToResource {accepta= ble-content-type: application/vnd.paws.notifyuse-v1+json, uri: = http://example.com/paws/used-spectrum}.=

=A0

Device POSTs the selected frequency ranges to the= URL and is done.

=A0

In this way, the device only needs to know how to= negotiate and handle the content types and be configured with the initial = URL of the service. Some interesting benefits:

=A0

* The device can connect to the database to ask a= bout any location and -- if the original database doesn=92t support a given= country -- be transparently directed in the response to another database t= o file the get spectrum request. It=92s feasible for any database to federa= te with other databases and provide seamless database discovery anywhere wh= itespace databases are in use (though this doesn=92t speak to the protocol = by which the databases would discover each other)

* At each POST, th= e device declares the response version it can handle which indicates to the= server that it can safely use that version and assume it will be handled b= y the client according to that particular version of the spec. Further, it = allows the client and server to easily agree on an upgraded version using t= he HTTP headers alone without needing to design such a feature into the pro= tocol itself.

* There=92s a very= natural mapping to a web-browser accessible site for viewing/querying the = database contents: visit http://example.com/paws in a b= rowser, and it sends back a page with a map allowing the user to pick a loc= ation. URLs like http://exam= ple.com/paws/available-spectrum/latitude=3D45N/longitude=3D75W might be bookmarked for repeated viewings for a particular locati= on.

* The initializati= on response could be augmented with ruleset definitions that could be cacha= ble, GETtable resources that (perhaps in a future version of the spec when = the breadth of rulesets is better known) allow devices to seamlessly upgrad= e their rulesets from the database.

=A0

=A0

-- =

----------------------------------<= /u>

Michael R Head <mrhead@google.com>

<= div>

http://www.cs.binghamton.edu/~mike

+1-201-BL= ISTER

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




--
= ----------------------------------
Michael R Head <mrhead@google.com>
+1-201-BLISTER
--047d7b2e40c84e939104e519ab5e-- From jstine@mitre.org Thu Aug 29 11:33:06 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147AA21E80B1 for ; Thu, 29 Aug 2013 11:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptSgUyuU2WF8 for ; Thu, 29 Aug 2013 11:32:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 57E8A21E80AA for ; Thu, 29 Aug 2013 11:32:58 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D31351F072F; Thu, 29 Aug 2013 14:32:57 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C00F11F0308; Thu, 29 Aug 2013 14:32:57 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.104]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Thu, 29 Aug 2013 14:32:57 -0400 From: "Stine, John A." To: Michael Head , "Harasty, Daniel J" Thread-Topic: [paws] JSON-RPC vs. JSON-REST Thread-Index: AQHOpN+lRS9ytaM9+kavkpcVWBtgc5mseA0A Date: Thu, 29 Aug 2013 18:32:56 +0000 Message-ID: <2782C93FD2244441893673F3F912819226CF5601@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_2782C93FD2244441893673F3F912819226CF5601IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] JSON-RPC vs. JSON-REST X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 18:33:06 -0000 --_000_2782C93FD2244441893673F3F912819226CF5601IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike, I very much agree with your goal. Back when we were puttin= g together the use cases and requirements document, I had recommended separ= ating the business process data from the modeling of spectrum use. The fol= lowing lines did make the document as a guideline but not as a requirement. The data model SHOULD provide a modular design separating messaging-specific, administrative-specific, and spectrum- specific parts into distinct modules. My vision was that any one of these parts may need to evolve and if the IET= F PAWS were designed to support this modularity that it would very useful b= eyond the TV Whitespace. The less specific the protocol was to the TV Whit= espace problem the better. It would be better if data modules were designe= d to be specific for the particular spectrum and regulatory domain in which= it is applicable as opposed to confounding the requirements of multiple do= mains into a single data model. and then making it integral to the exchange= s of the protocol. I am involved with another standardization effort through the IEEE DySPAN S= C called Spectrum Consumption Modeling. We are developing an approach tha= t can be used to model and use of spectrum and then to arbitrate compatibil= ity. It is very relevant to PAWS since it could open up the concepts of da= tabase managed sharing as envisioned by the PCAST report in the US. Owners= of spectrum can use these models to specify the contours that allow other = users to share. Models can be used for the trading of spectrum. Models ca= n enable database administrators to manage coexistence. It would be nice i= f the design of the IETF PAWS would seek to support the data modularity and= separation from the communications. John From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Mic= hael Head Sent: Thursday, August 29, 2013 1:45 PM To: Harasty, Daniel J Cc: paws@ietf.org Subject: Re: [paws] JSON-RPC vs. JSON-REST Thanks for the detailed response Dan, I still believe the idea of separating metadata from data in the protocol a= nd defining version and capability negotiation in as would be enabled by a = RESTful architecture would yield significant benefits down the road. However, given that nobody has voiced any support for my proposal, and in t= he interest of moving the draft forward, I'll be happy to retract it. Perhaps we may revisit it when we draft future versions of PAWS. -- mike On Mon, Jul 22, 2013 at 9:49 AM, Harasty, Daniel J > wrote: In considering Michaels input, these are my thoughts: * I agree that the current draft's ruleset concept and the number = of optional messages (especially server optional message) does not lead to = a particularly clean "negotiation". In fact, while it looks workable, I'm = trying to implement it now, and it "feels" rather clumsy. o To remedy this, I was on the verge of proposing a required set of "fea= ture negotiations" in the INIT_REQ/RESP messages. o This would also be a good place for servers to initialize any authentic= ation schemes (if required by the server, and until a standard certificate-= based scheme is specified and adopted). * Moving this negotiation to the HTTP headers (as Michael proposes)= is - I suspect - workable. o However, it is my personal opinion that that ties the protocol MORE TIG= HTLY to HTTP. * Keeping it "in band" - inside the JSON-RPC message itself - allows for a= lternate transports: say directly over UDP, or some future wireless-packet = scheme, for example. o And, as and implementer, I'd rather just deal with the options of the p= rotocol "in band", in the protocol itself. * As a server process implementing this protocol, what is the benefit to m= e to have to "go looking" for "how to handle this message" by looking a bit= in the message, and a bit in the HTTP headers? * Yes, interworking of new protocols (or a new version of the "same= " protocol) with old ones is always a bit tricky; it is difficult to know N= OW everything we'll need in the future to make interworking work smoothly. o However, we already have a perfectly good "escape hatch" in our current= JSON-RPC-oriented approach: at anytime in the future, and new PAWS version= can define a new method outside of the scope of PAWS 1.0. * To my reading, the old PAWS server would reply with a JSON-RCP "method n= ot implemented"... and thus interworking was handled smoothly. (It would b= e the client's prerogative to "step back" through older protocols that it d= oes implement.) o Also, in some cases, new features/extensions could be "added" to PAWS (= and safely interwork old and new versions) due to the fact that "ignoring u= nexpected fields" is REQUIRED. o While I think Michael's proposal would offer a different way to handle = version negotiation, I don't see that it is "better"... just "a different w= ay". * I agree that the ability to be "transparently redirected" to a pe= er ("federated") server is a good idea... o ... but, to my reading, that is already accommodated by the Section 7 t= ext regarding the handling of HTTP Redirects. * As for additional "mappings" from browsers: nothing in our curren= t spec precludes a Database from replying one way to PAWS messages (in HTTP= POST encoded as JSON-RPC), and to HTTP GETs another way. o In fact, we're already implementing that, too. I have other minor comments (maybe even quibbles) with some of Michaels sta= tements... but there is no particular need to go in to all of that now. I propose the bigger questions is one of general direction. At this point = in time: 1. If the rest of the group finds the current "feature/ruleset negoti= ation" scheme is just fine, then perhaps no action is needed. 2. If others feel that it is somewhat clunky, do we attempt to addres= s it by: o "Fixing it" in the current "style": introduce a more clear - possibly R= EQUIRED - "negotiation" to the existing JSON-RPC. o Changing direction now to Michaels proposed use of HTTP headers. o Pursuing BOTH to a sufficient degree of clarity until we can then pick = between them. Thoughts? Dan Harasty From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Michael Head Sent: Monday, July 22, 2013 11:07 AM To: paws@ietf.org Subject: [paws] JSON-RPC vs. JSON-REST I suppose this will be controversial, but I'm finding that relying on JSON-= RPC is driving unnecessary coupling among the device, database and regulato= ry authority. What I mean by this is that each device/client has to know (o= r detect) something about the database/server it's talking to as well as th= e ruleset under which the server will operate. For example, it is allowed for a device to be implemented so that it only m= akes the spectrum.paws.GetSpectrum RPC. However, in order for this to work,= the database it is configured to communicate with must be built to allow f= or this: it won't work with a database that requires spectrum.paws.Init and= spectrum.paws.Register to be called. The device can only detect that the d= atabase requires these calls by inspecting the error returned from the GetS= pectrum RPC. Furthermore, registration rules (including which fields are re= quired for proper registration) may be governed by the regulatory authority= . The device needs to know these details a priori (or possibly detect them = by attempting a request and inspecting error results in an underspecified m= anner). Much of those details are determined by the governing ruleset ID, a= nd its precise meaning must be baked into both the database and the device,= and they must assume that their respective semantics will agree. Some of these issues could be solved by reducing the amount of optionality = (and perhaps some of the optional calls) and requiring a standard sequence = of operations. This may work, but I feel the coupling would still be high. = Protocol version upgrades (and version negotiation) won't be particularly g= raceful: the client might send a version 1.1 message to the database, and e= ven though the client might also support 1.0, it would get an error respons= e if the database didn't support 1.0. As a secondary issue, it's less natural to expose the service via the web. = JSON-RPC is really only built to allow for programmatic clients. So.... I'd rather see a RESTful API that develops application state through= the use of hyperlinked, content-typed message bodies. I suppose REST-vs-RP= C has been discussed quite a bit in general, but I haven't seen it brought = here. A sketch of the protocol might look like this (I'm not a RESTful API expert= , so I'm sure it could be better): Database publishes a single URL entry point: http://example.com/paws Device POSTs an application/vnd.paws.init.request-v1+json message to http:/= /example.com/paws with header Accept: application/vnd.paws.init.response-v2+json;application/vnd.paws.ini= t.response-v1+json Database (let's say it only supports v1) responds with a application/paws.i= nit.response-v1+json message which includes the details in 4.2.2 of the dra= ft -- with, say a cache-control: max-age=3D86400 header -- but contain an a= dditional field: spectrumResource: {acceptable-content-type: application/pa= ws.getspectrum.request-v1+json; required-fields: device/fccId; uri: http://= example.com/paws/available-spectrum} Device POSTs application/paws.getspectrum.request-v1+json a message with th= e FCC id to http://example.com/paws/available-spectrum and header Accept: application/vnd.paws.notifyuse-v1+json Database response with an application/paws.getspectrum.response-v1+json res= ponse containing the details specified in 4.4.2 with an additional field (i= f it is required for spectrum use to be notified by the device): notifyUseT= oResource {acceptable-content-type: application/vnd.paws.notifyuse-v1+json,= uri: http://example.com/paws/used-spectrum}. Device POSTs the selected frequency ranges to the URL and is done. In this way, the device only needs to know how to negotiate and handle the = content types and be configured with the initial URL of the service. Some i= nteresting benefits: * The device can connect to the database to ask about any location and -- i= f the original database doesn't support a given country -- be transparently= directed in the response to another database to file the get spectrum requ= est. It's feasible for any database to federate with other databases and pr= ovide seamless database discovery anywhere whitespace databases are in use = (though this doesn't speak to the protocol by which the databases would dis= cover each other) * At each POST, the device declares the response version it can handle whic= h indicates to the server that it can safely use that version and assume it= will be handled by the client according to that particular version of the = spec. Further, it allows the client and server to easily agree on an upgrad= ed version using the HTTP headers alone without needing to design such a fe= ature into the protocol itself. * There's a very natural mapping to a web-browser accessible site for viewi= ng/querying the database contents: visit http://example.com/paws in a brows= er, and it sends back a page with a map allowing the user to pick a locatio= n. URLs like http://example.com/paws/available-spectrum/latitude=3D45N/long= itude=3D75W might be bookmarked for repeated viewings for a particular loca= tion. * The initialization response could be augmented with ruleset definitions t= hat could be cachable, GETtable resources that (perhaps in a future version= of the spec when the breadth of rulesets is better known) allow devices to= seamlessly upgrade their rulesets from the database. -- ---------------------------------- Michael R Head > http://www.cs.binghamton.edu/~mike +1-201-BLISTER _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- ---------------------------------- Michael R Head > http://www.cs.binghamton.edu/~mike +1-201-BLISTER --_000_2782C93FD2244441893673F3F912819226CF5601IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mike,

 <= /p>

    &= nbsp;           I very mu= ch agree with your goal.  Back when we were putting together the use c= ases and requirements document, I had recommended separating the business process data from the modeling of spectrum use.  The fol= lowing lines did make the document as a guideline but not as a requirement.=

 <= /p>

The data model SHOULD provide a modular design separating<= o:p>

messaging-specific, administrative-specific, and spectrum-=

specific parts into distinct modules.

 <= /p>

My vision was that any on= e of these parts may need to evolve and if the IETF PAWS were designed to s= upport this modularity that it would very useful beyond the TV Whitespace.  The less specific the protocol was to the TV Whit= espace problem the better.  It would be better if data modules were de= signed to be specific for the particular spectrum and regulatory domain in = which it is applicable as opposed to confounding the requirements of multiple domains into a single data model. and then ma= king it integral to the exchanges of the protocol.

 <= /p>

I am involved with anothe= r standardization effort through the IEEE DySPAN SC called Spectrum Consump= tion Modeling.   We are developing an approach that can be used to model and use of spectrum and then to arbitrate compatibility.&= nbsp; It is very relevant to PAWS since it could open up the concepts of da= tabase managed sharing as envisioned by the PCAST report in the US.  O= wners of spectrum can use these models to specify the contours that allow other users to share.  Models can be = used for the trading of spectrum.  Models can enable database administ= rators to manage coexistence.  It would be nice if the design of the I= ETF PAWS would seek to support the data modularity and separation from the communications.

 <= /p>

John

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Michael Head
Sent: Thursday, August 29, 2013 1:45 PM
To: Harasty, Daniel J
Cc: paws@ietf.org
Subject: Re: [paws] JSON-RPC vs. JSON-REST

 

Thanks for the detailed r= esponse Dan,

 

I still believe the idea = of separating metadata from data in the protocol and defining version and c= apability negotiation in as would be enabled by a RESTful architecture woul= d yield significant benefits down the road. 

 

However, given that nobod= y has voiced any support for my proposal, and in the interest of moving the= draft forward, I'll be happy to retract it.

 

Perhaps we may revisit it= when we draft future versions of PAWS.

 

-- mike

 

On Mon, Jul 22, 2013 at 9= :49 AM, Harasty, Daniel J <dharasty@appcomsci.com> wrote:

In considering Michaels input, these are my thou= ghts:

 

=B7         I  agree that the current draft̵= 7;s ruleset concept and the number of optional messages (especially server optional message) does not lead to a particularly clean ̶= 0;negotiation”.  In fact, while it looks workable, I’m try= ing to implement it now, and it “feels” rather clumsy.

o   To remedy this, I was  on the verge = of proposing a required set of “feature negotiations” in the IN= IT_REQ/RESP messages.

o   This would also be a good place for serve= rs to initialize any authentication schemes (if required by the server, and= until a standard certificate-based scheme is specified and adopted).

 

=B7         Moving this negotiation to the HTTP heade= rs (as Michael proposes) is – I suspect – workable.=

o   However, it is my personal opinion that t= hat ties the protocol MORE TIGHTLY to HTTP. 

=A7  Keeping it “in band” – = inside the JSON-RPC message itself – allows for alternate transports:= say directly over UDP, or some future wireless-packet scheme, for example.=

o   And, as and implementer, I’d rather= just deal with the options of the protocol “in band”, in the p= rotocol itself.

=A7  As a server process implementing this pro= tocol, what is the benefit to me to have to “go looking” for &#= 8220;how to handle this message” by looking a bit in the message, and= a bit in the HTTP headers?

 

=B7         Yes, interworking of new protocols (or a = new version of the “same” protocol) with old ones is always a b= it tricky; it is difficult to know NOW everything we’ll need in the future to make interworking work smoothly.

o   However, we already have a perfectly good= “escape hatch” in our current JSON-RPC-oriented approach: at a= nytime in the future, and new PAWS version can define a new method outside of the scope of PAWS 1.0.

=A7  To my reading, the old PAWS server would = reply with a JSON-RCP “method not implemented”… and thus = interworking was handled smoothly.  (It would be the client’s pr= erogative to “step back” through older protocols that it does implement.= )

o   Also, in some cases, new features/extensi= ons could be “added” to PAWS (and safely interwork old and new = versions) due to the fact that “ignoring unexpected fields” is = REQUIRED.

o   While I think Michael’s proposal wo= uld offer a different way to handle version negotiation, I don’t see = that it is “better”… just “a different way”.

 

=B7         I agree that the ability to be “tra= nsparently redirected” to a peer (“federated”) server is = a good idea…

o   … but, to my reading, that is alrea= dy accommodated by the Section 7 text regarding the handling of HTTP Redire= cts.

 

=B7         As for additional “mappings” = from browsers: nothing in our current spec precludes a Database from replyi= ng one way to PAWS messages (in HTTP POST encoded as JSON-RPC), and to HTTP GETs another way.

o   In fact, we’re already implementing= that, too.

 

I have other minor comments (maybe even quibbles= ) with some of Michaels statements… but there is no particular need t= o go in to all of that now.

 

I propose the bigger questions is one of general= direction.  At this point in time:

1.       If the rest of the group finds the curren= t “feature/ruleset negotiation” scheme is just fine, then perha= ps no action is needed.

2.       If others feel that it is somewhat clunky= , do we attempt to address it by:

o   “Fixing it” in the current &#= 8220;style”: introduce a more clear – possibly REQUIRED –=  “negotiation” to the existing JSON-RPC.

o   Changing direction now to Michaels propos= ed use of HTTP headers.

o   Pursuing BOTH to a sufficient degree of c= larity until we can then pick between them.

 

Thoughts?

 

Dan Harasty

 

 

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Michael Head
Sent: Monday, July 22, 2013 11:07 AM
To: paws@ietf.org=
Subject: [paws] JSON-RPC vs. JSON-REST

 

I suppose this will be controversial, but I’m finding that= relying on JSON-RPC is driving unnecessary coupling among the device, data= base and regulatory authority. What I mean by this is that each device/client has to know (or detect) something about the database/server = it's talking to as well as the ruleset under which the server will operate.=

 

For example, it is allowed for a device to be implemented so tha= t it only makes the spectrum.paws.GetSpectrum RPC. However, in order for th= is to work, the database it is configured to communicate with must be built to allow for this: it won’t work with a database = that requires spectrum.paws.Init and spectrum.paws.Register to be called. T= he device can only detect that the database requires these calls by inspect= ing the error returned from the GetSpectrum RPC. Furthermore, registration rules (including which fields are required = for proper registration) may be governed by the regulatory authority. The d= evice needs to know these details a priori (or possibly detect them by atte= mpting a request and inspecting error results in an underspecified manner). Much of those details are dete= rmined by the governing ruleset ID, and its precise meaning must be baked i= nto both the database and the device, and they must assume that their respe= ctive semantics will agree.

 

Some of these issues could be solved by reducing the amount of o= ptionality (and perhaps some of the optional calls) and requiring a standar= d sequence of operations. This may work, but I feel the coupling would still be high. Protocol version upgrades (and version negot= iation) won’t be particularly graceful: the client might send a versi= on 1.1 message to the database, and even though the client might also suppo= rt 1.0, it would get an error response if the database didn’t support 1.0.

 

As a secondary issue, it’s less natural to expose the serv= ice via the web. JSON-RPC is really only built to allow for programmatic cl= ients.

 

So.... I’d rather see a RESTful API that develops applicat= ion state through the use of hyperlinked, content-typed message bodies. I s= uppose REST-vs-RPC has been discussed quite a bit in general, but I haven’t seen it brought here.

 

A sketch of the protocol might look like this (I’m not a R= ESTful API expert, so I’m sure it could be better):=

 

Database publishes a single URL entry point: htt= p://example.com/paws

 

Device POSTs an application/vnd.paws.init.request-v1+json me= ssage to htt= p://example.com/paws with header

Accept: application/vnd.paws.init.response-v2+json;applicati= on/vnd.paws.init.response-v1+json

 

Database (let’s say it only supports v1) responds with a a= pplication/paws.init.response-v1+json message which includes the detail= s in 4.2.2 of the draft -- with, say a cache-control: max-age=3D86400 header -- but contain an additional field: spectrumResource: {acceptable-c= ontent-type: application/paws.getspectrum.request-v1+json; required-fie= lds: device/fccId; uri: http://example.com/paws/available-spectrum}

 

Device POSTs application/paws.getspectrum.request-v1+json a = message with the FCC id to http://example.com/paws/available-spectrum and header

Accept: application/vnd.paws.notifyuse-v1+json

 

Database response with an application/paws.getspectrum.response-= v1+json response containing the details specified in 4.4.2 with an addi= tional field (if it is required for spectrum use to be notified by the device): notifyUseToResource {acceptable-content-type: application/= vnd.paws.notifyuse-v1+json, uri: = http://example.com/paws/used-spectrum}.

 

Device POSTs the selected frequency ranges to the URL and is don= e.

 

In this way, the device only needs to know how to negotiate and = handle the content types and be configured with the initial URL of the serv= ice. Some interesting benefits:

 

* The device can connect to the database to ask about any locati= on and -- if the original database doesn’t support a given country --= be transparently directed in the response to another database to file the get spectrum request. It’s feasible for any database to = federate with other databases and provide seamless database discovery anywh= ere whitespace databases are in use (though this doesn’t speak to the= protocol by which the databases would discover each other)

* At each POST, the device declares the response version it can = handle which indicates to the server that it can safely use that version an= d assume it will be handled by the client according to that particular version of the spec. Further, it allows the client and ser= ver to easily agree on an upgraded version using the HTTP headers alone wit= hout needing to design such a feature into the protocol itself.=

* There’s a very natural mapping to a web-browser accessib= le site for viewing/querying the database contents: visit htt= p://example.com/paws in a browser, and it sends back = a page with a map allowing the user to pick a location. URLs like http://example.com/paws/available-spectrum= /latitude=3D45N/longitude=3D75W might be bookmarked for repeated viewings for a particular location.

* The initialization response could be augmented with ruleset de= finitions that could be cachable, GETtable resources that (perhaps in a fut= ure version of the spec when the breadth of rulesets is better known) allow devices to seamlessly upgrade their rulesets from the = database.

 

 

--

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

Michael R= Head <mrhead@goo= gle.com>

+1-20= 1-BLISTER


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



 

--

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

Michael R Head <mrhead@google.com>

+1-201-BLISTER

--_000_2782C93FD2244441893673F3F912819226CF5601IMCMBX01MITREOR_-- From dharasty@appcomsci.com Thu Aug 29 13:33:51 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163AB21E80BB for ; Thu, 29 Aug 2013 13:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5Z6E+9DlPdZ for ; Thu, 29 Aug 2013 13:33:40 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4F321E80B9 for ; Thu, 29 Aug 2013 13:33:40 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r7TKXbYZ007671 for ; Thu, 29 Aug 2013 16:33:39 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r7TKXbSM003405 for ; Thu, 29 Aug 2013 16:33:37 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Thu, 29 Aug 2013 16:33:36 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQIX1El7GNnWkeMJWYlOxECypmspRHA Date: Thu, 29 Aug 2013 20:33:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CF12425rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 20:33:51 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CF12425rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I rather prefer option 2, but I realize this is more a point of personal ta= ste; I think either are workable. Regarding option 2, I have the following comments. (Some may apply to opti= on 1, also.) Ordering Matters I think the spec should require that the "points" be in frequency-increasin= g order of "freqHz" value. (The need is obvious, so let's state it as a re= quirement.) Two "points" may have the same "freqHz" value; their order is significant, = too. (For example, the first four points in Vince's example constitute a "= step function". However, if points #2 and #3 were swapped, it would indica= te a "sawtooth" spectral mask.) Three (or more) "points" may NOT share a "freqHz" value. Should be an Array I think the term "point" is rather vague, an repeatedly re-using it in a si= ngle object can't be kosher. Thus, I propose this structure be an array of objects: [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, . . . ] How to Indicate "Unavailable" There are a few options to indicate that a subband is "unavailable". 1) The spec could state a value that means "unavailable", such as -100= , -1000.0, or -56.8. 2) The spec could not state that value, and the Database could choose = an arbitrary small number at its discretion. 3) The spec could state that the JSON value null means "unavailable", = or a reserved string such as "-Inf" I rather prefer option 3. If we use a reserved string, I prefer "-Inf" in = particular as it is an IEEE standard for negative infinity, and many progra= mming languages support interpreting "-Inf" as a parsable string resulting = in a valid IEEE float. [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": null}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": null }, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ] or [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ] From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Sunday, August 25, 2013 6:40 PM To: paws@ietf.org Subject: [paws] Encoding of spectrum profile All, As was brought up before (and at) the F2F, the current encoding for a spect= rum profile has a "channelized" view: - List of (startHz, stopHz, power) - Has no ability to specify power level in "unavailable" ranges Example: { "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 = }, "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 = }, } Question: Should we use a more flexible encoding? There were two proposals made on the list: - Option 1: List of (startHz, startPower, stopHz, stopPower) - Option 2: Ordered list of (freqHz, power) At the F2F, we agreed that Option 2 was the more general form. Example: { "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 }, "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 }, "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 }, "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 } } This example explicitly specifies the power levels in the unavailable frequ= ency ranges. This example also shows that it's possible to encode "square edges" by havi= ng two points using the same frequency, but does allow for "slanted edges" for mor= e gentle roll-offs. -- -vince --_000_EC510C021D06A34C92F5A5A488B5290B0CF12425rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

I rather prefer option 2, bu= t I realize this is more a point of personal taste; I think either are work= able.

 

Regarding option 2, I have the followin= g comments.  (Some may apply to option 1, also.)

=

 

Ordering Matters

=

I think the spec = should require that the “points” be in frequency-increasing ord= er of “freqHz” value.  (The need is obvious, so let’= s state it as a requirement.)

 

Two “poin= ts” may have the same “freqHz” value; their order is sign= ificant, too.  (For example, the first four points in Vince’s ex= ample constitute a “step function”.  However, if points #2= and #3 were swapped, it would indicate a “sawtooth” spectral m= ask.)

 

Three (or more) “points” ma= y NOT share a “freqHz” value.

 

= Should be an Array

 

I think the term ̶= 0;point” is rather vague, an repeatedly re-using it in a single objec= t can’t be kosher. 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Thus, I propo= se this structure be an array of objects:

 

[

    { "= freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },

    { "freqHz": 5= .18e8, "maxPsdDbmPerBw": -56.8 },

    { "freqHz": 5.18e8, "= maxPsdDbmPerBw": 30.0 },

    { "freqHz": 5.24e8, "maxPsdDbmPerBw&q= uot;: 30.0 },

  = .

   .

   .

]

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

How to Ind= icate “Unavailable”

 

There are= a few options to indicate that a subband is “unavailable”.

1)   &= nbsp;  The spec could state a va= lue that means “unavailable”, such as -100, -1000.0, or -56.8.<= o:p>

2)  &nbs= p;   The spec could not sta= te that value, and the Database could choose an arbitrary small number at i= ts discretion.

3)=       The = spec could state that the JSON value null means &= #8220;unavailable”, or a reserved string such as “-Inf”

 

I rather prefer option 3.  If we use a re= served string, I prefer “-Inf” in particular as it is an IEEE s= tandard for negative infinity, and many programming languages support inter= preting “-Inf” as a parsable string resulting in a valid IEEE f= loat.

 

[

    { "freqHz": 4.70e8, "maxPsdDb= mPerBw":  null},

    { "freqHz": 5.18e8, "maxPsdDbmPerBw"= ;: null },

  &nb= sp; { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },<= /o:p>

    { "freq= Hz": 5.24e8, "maxPsdDbmPerBw": 30.0 },

=

]

 

or

 

[

&nbs= p;   { "freqHz": 4.70e8, "maxPsdDbmPerBw": &#= 8220;-Inf”},

 &= nbsp;  { "freqHz": 5.18e8, "maxPsdDbmPerBw": ̶= 0;-Inf”},

 &nbs= p;  { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },<= o:p>

    { "= ;freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },

]

 

 = ;

From: paws-bounces@ietf.org [= mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent:<= /b> Sunday, August 25, 2013 6:40 PM
To: paws@ietf.org
Subje= ct: [paws] Encoding of spectrum profile

 

All,

 

As was brought up before (and at) the F2F, the curre= nt encoding for a spectrum profile

has a "channelized" view:

 - List of (startHz, stopHz, power)

<= div>

 - Has no ability to specify power level in &= quot;unavailable" ranges

 

Example:

  {

    "point": { "startHz": 5.18e= 8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },

    "point": { &q= uot;startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw= ": 36.0 },

  }=

 

<= p class=3DMsoNormal>Question: Should we use a more flexible encoding?<= /o:p>

 

There were two proposals made on the list:

  - Option 1: List of (startHz, start= Power, stopHz, stopPower)

&nb= sp; - Option 2: Ordered list of (freqHz, power)

 

At = the F2F, we agreed that Option 2 was the more general form.

<= /div>

 

Example:

  {

    "point"= : { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },

    "point": { = "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },=

    "point": { &quo= t;freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },

<= /div>

    "point": { "fre= qHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },

=

    "point": { "freqHz&q= uot;: 5.24e8, "maxPsdDbmPerBw": 36.0 },

=

    "point": { "freqHz":= 5.30e8, "maxPsdDbmPerBw": 36.0 },

    "point": { "freqHz": 5.30= e8, "maxPsdDbmPerBw": -56.8 },

    "point": { "freqHz": 6.98e8,= "maxPsdDbmPerBw": -56.8 }

  }


This example explicitly specif= ies the power levels in the unavailable frequency ranges.

 

This example also shows that it's possible to encode "square ed= ges" by having two

point= s using the same frequency, but does allow for "slanted edges" fo= r more gentle roll-offs.

 

--
-vince

= --_000_EC510C021D06A34C92F5A5A488B5290B0CF12425rrcatsexmb2atsa_-- From kalle.kuismanen@fairspectrum.com Thu Aug 29 15:30:39 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2448111E818B for ; Thu, 29 Aug 2013 15:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDBuAzFogPHA for ; Thu, 29 Aug 2013 15:30:34 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 21DD021F9EDF for ; Thu, 29 Aug 2013 15:30:31 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i4so1423949oah.23 for ; Thu, 29 Aug 2013 15:30:31 -0700 (PDT) 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=j0Hwe33YYeHrm9Bflc/Jt658+EBud6LWmwxtTrpmavE=; b=F+P4iqhSOxebPruzGwx18g8w31ks5HdpweYRkiSQRHLXWPPEfC37vFcyncx2ZAn63U p9gAKlImNd2cA9KiZcLK32jcAoMMzczgioVysuDK6HSCVJTB5KScuJ643Q5S9pWOkffg c2A9jTcj8ah/us5BUXxZn04wpGgrJ5ABRPqcr4iY6HT80UwChTLOJJpCwYoUNvnD0e6H +lX6NaG1HLmD8qeu6oEsjWkNu/fcUloSsz4Y3SgdepyR7DYjf1l61/nhnR7f+dqsBRlM TdZ5kNnZYo+ZyB4ZB5GznaRyqSs2GBVd76/v4iMVrBxnh0LM2kVyAmAu8NZbypAKuoOb DwTw== X-Gm-Message-State: ALoCoQkAJUm3B53sYkAzruxRQ84EfgOz3P+3WQBWegRvVS8riieAigv7Fqe05t2f6u7j9AeLaMl0 MIME-Version: 1.0 X-Received: by 10.182.220.199 with SMTP id py7mr4296886obc.92.1377815431405; Thu, 29 Aug 2013 15:30:31 -0700 (PDT) Received: by 10.60.92.170 with HTTP; Thu, 29 Aug 2013 15:30:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Aug 2013 01:30:31 +0300 Message-ID: From: Kalle Kuismanen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=001a11c334aa5af24504e51da79b Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 22:30:39 -0000 --001a11c334aa5af24504e51da79b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All, I haven't participated in the discussion much, but I just had to solve this very issue about a week ago so here a my two cents: on the issue of "-Inf" or null. We've also used in our paws and other protocol implementation "-Inf" as indication of channel being unavailable, but problem is that it's somewhat misleading. For example if a channel is "usable" only above 20 dBm and we calculate maximum transmission to be 19 dBm it is bit silly to send -Inf. Null value is even more misleading, because it usually indicates that we don't know what the value is, which in this case probably would mean an implementation error in the calculation code. Then of course considering the implementation. I tried to use in our paws implementation "-Inf", but of course Javascript doesn't recognize that string as a number, so it causes a type casting problem i.e. sometimes the value is a number and sometimes a string. Which of course led to first our server not validating the JSON against the PAWS schema and then when I by passed that (bad thing, but I was in a rush) our test client side validation failed also. See below how I decided it should be solved, but in the end, because didn't want to burden the device side implementers I just dropped the channels that couldn't be used from the array. On the client side or device side the JSON needs to be checked for the special value or a simple field will suffice. Mutable nature of JSON makes it easy. On client side the code would check in Javascript in node.js: var a =3D [ { "freqHz": 4.70e8, "unavailable": true}, { "freqHz": 5.18e8, "unavailable": true}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ]; var b =3D ""; for(var f in a) { if(a[f]["unavailable"]!=3D=3Dtrue) b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; } process.stdout.write( b ); This is not so different from using "-Inf" or "null" implementation. var a =3D [ { "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"}, { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, ]; var b =3D ""; for(var f in a) { if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf") b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; } process.stdout.write( b ); Both cases usually just do one comparison. But as I said first version preserves type of maxPsdDbmPerBw other does not. Both cost about the same on the wire. But of course this is just a suggestion. JSON is very malleable. Cheers, Kalle Kuismanen FairSpectrum On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J wrote: > ** ** > > I rather prefer option 2, but I realize this is more a point of personal > taste; I think either are workable.**** > > ** ** > > Regarding option 2, I have the following comments. (Some may apply to > option 1, also.)**** > > ** ** > > *Ordering Matters* > > **** > > I think the spec should require that the =93points=94 be in > frequency-increasing order of =93freqHz=94 value. (The need is obvious, = so > let=92s state it as a requirement.)**** > > ** ** > > Two =93points=94 may have the same =93freqHz=94 value; their order is sig= nificant, > too. (For example, the first four points in Vince=92s example constitute= a > =93step function=94. However, if points #2 and #3 were swapped, it would > indicate a =93sawtooth=94 spectral mask.)**** > > ** ** > > Three (or more) =93points=94 may NOT share a =93freqHz=94 value.**** > > ** ** > > *Should be an Array* > > ** ** > > I think the term =93point=94 is rather vague, an repeatedly re-using it i= n a > single object can=92t be kosher. **** > > ** ** > > Thus, I propose this structure be an array of objects:**** > > ** ** > > [**** > > { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },**** > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },**** > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** > > .**** > > .**** > > .**** > > ]**** > > ** ** > > *How to Indicate =93Unavailable=94* > > ** ** > > There are a few options to indicate that a subband is =93unavailable=94.*= *** > > **1) **The spec could state a value that means =93unavailable=94, su= ch > as -100, -1000.0, or -56.8.**** > > **2) **The spec could not state that value, and the Database could > choose an arbitrary small number at its discretion.**** > > **3) **The spec could state that the JSON value *null* means > =93unavailable=94, or a reserved string such as =93-Inf=94**** > > ** ** > > I rather prefer option 3. If we use a reserved string, I prefer =93-Inf= =94 in > particular as it is an IEEE standard for negative infinity, and many > programming languages support interpreting =93-Inf=94 as a parsable strin= g > resulting in a valid IEEE float.**** > > ** ** > > [**** > > { "freqHz": 4.70e8, "maxPsdDbmPerBw": null},**** > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": null },**** > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** > > ]**** > > ** ** > > or**** > > ** ** > > [**** > > { "freqHz": 4.70e8, "maxPsdDbmPerBw": =93-Inf=94},**** > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": =93-Inf=94},**** > > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** > > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** > > ]**** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Vincent Chen > *Sent:* Sunday, August 25, 2013 6:40 PM > *To:* paws@ietf.org > *Subject:* [paws] Encoding of spectrum profile**** > > ** ** > > All,**** > > ** ** > > As was brought up before (and at) the F2F, the current encoding for a > spectrum profile**** > > has a "channelized" view:**** > > - List of (startHz, stopHz, power)**** > > - Has no ability to specify power level in "unavailable" ranges**** > > ** ** > > Example:**** > > {**** > > "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": 30.= 0 > },**** > > "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36.= 0 > },**** > > }**** > > ** ** > > Question: Should we use a more flexible encoding?**** > > ** ** > > There were two proposals made on the list:**** > > - Option 1: List of (startHz, startPower, stopHz, stopPower)**** > > - Option 2: Ordered list of (freqHz, power)**** > > ** ** > > At the F2F, we agreed that Option 2 was the more general form.**** > > ** ** > > Example:**** > > {**** > > "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },**** > > "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },**** > > "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** > > "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** > > "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },**** > > "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },**** > > "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },**** > > "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }**** > > }**** > > > **** > > This example explicitly specifies the power levels in the unavailable > frequency ranges.**** > > ** ** > > This example also shows that it's possible to encode "square edges" by > having two**** > > points using the same frequency, but does allow for "slanted edges" for > more gentle roll-offs.**** > > ** ** > > -- > -vince **** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --001a11c334aa5af24504e51da79b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi All,

I haven't participated in t= he discussion much, but I just had to solve this very issue about a week ag= o so here a my two cents:

on the issue of "-I= nf" or null. We've also used in our paws and other protocol implem= entation "-Inf" as indication of channel being unavailable, but p= roblem is that it's somewhat misleading. For example if a channel is &q= uot;usable" only above 20 dBm and we calculate maximum transmission to= be 19 dBm it is bit silly to send -Inf. Null value is even more misleading= , because it usually indicates that we don't know what the value is, wh= ich in this case probably would mean an implementation error in the calcula= tion code.

Then of course considering the implementation. I tried = to use in our paws implementation "-Inf", but of course Javascrip= t doesn't recognize that string =A0as a number, so it causes a type cas= ting problem i.e. sometimes the value is a number and sometimes a string. W= hich of course led to first our server not validating the JSON against the = PAWS schema and then when I by passed that (bad thing, but I was in a rush)= our test client side validation failed also.

See below how I decided it should be solved, but in the= end, because didn't want to burden the device side implementers I just= dropped the channels that couldn't be used from the array.

On the client side or device side the JSON needs to be check= ed for the special value or a simple field will suffice. Mutable nature of = JSON makes it easy.

On client side the code would = check in Javascript in node.js:

var a =3D [=
=A0 =A0 { "fre= qHz": 4.70e8, "unavailable": true},=A0
=A0 =A0 { "freqHz": 5.18e8, &qu= ot;unavailable": true},
=A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz": 5.24e8, "maxPsdDbm= PerBw": 30.0 },
];
var b =3D "";

for(var f in a)
=A0 =A0 {
=A0 =A0 if(a[f]["unavailable"]!= =3D=3Dtrue)=A0
=A0 = =A0 =A0 =A0 b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n&q= uot;;
=A0 =A0 }

process.stdout.write( b );

This is not so different from using "-Inf" or "null" = implementation.

var a = =3D [
=A0 =A0 { &quo= t;freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"},=A0
=A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": "-Inf"},
=A0 =A0 { "freqHz": 5.18e8, &quo= t;maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 30.0 },
];
var b =3D "";

for(var f in a)
=A0 =A0 {
=A0 =A0 if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf&= quot;)
=A0 =A0 =A0 =A0 b +=3D a[f].freq= Hz+":"+a[f].maxPsdDbmPerBw+"\n";
=A0 =A0 }
process.stdout.write( b );
maxPsdDbmPerBw other does not. Both cost ab= out the same on the wire.=A0

But of course this is just a suggestion. JSON is very m= alleable.

Cheers,
Kalle Kuismanen
FairSpectrum


On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J <<= a href=3D"mailto:dharasty@appcomsci.com" target=3D"_blank">dharasty@appcoms= ci.com> wrote:

=A0

I rather prefer option 2, but I realize t= his is more a point of personal taste; I think either are workable.<= u>

=A0<= /p>

Regarding option 2, I = have the following comments.=A0 (Some may apply to option 1, also.)<= u>

=A0<= /p>

Ordering Matters=

I think the spec should = require that the =93points=94 be in frequency-increasing order of =93freqHz= =94 value.=A0 (The need is obvious, so let=92s state it as a requirement.)<= u>

=A0<= /p>

Two =93points=94 may h= ave the same =93freqHz=94 value; their order is significant, too.=A0 (For e= xample, the first four points in Vince=92s example constitute a =93step fun= ction=94.=A0 However, if points #2 and #3 were swapped, it would indicate a= =93sawtooth=94 spectral mask.)

=A0<= /p>

Three (or more) =93poi= nts=94 may NOT share a =93freqHz=94 value.

=A0<= /p>

Should be an Array<= u>

=A0<= /p>

I think the term =93po= int=94 is rather vague, an repeatedly re-using it in a single object can=92= t be kosher.=A0

=A0<= /p>

Thus, I propose this s= tructure be an array of objects:

=A0<= /p>

[=

=A0=A0 = =A0{ "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },

=A0=A0=A0 { "f= reqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },

=A0=A0=A0 { "freqHz&= quot;: 5.18e8, "maxPsdDbmPerBw": 30.0 },

=

=A0=A0=A0 { "freqHz": 5.24e8, "ma= xPsdDbmPerBw": 30.0 },

= =A0=A0 .

=A0=A0 .

=A0=A0 .

]

=A0=

How to Indicate =93Una= vailable=94

=A0

There are a few options t= o indicate that a subband is =93unavailable=94.

= 1)=A0=A0=A0=A0=A0 The spec could state a value that means =93unavailable=94= , such as -100, -1000.0, or -56.8.

2)=A0=A0=A0=A0=A0 The spec could not state that value, and the Database = could choose an arbitrary small number at its discretion.

3)=A0=A0=A0=A0=A0 The spec could state that the JSON value null means =93unavailable=94, or= a reserved string such as =93-Inf=94

=A0<= /p>

I rather prefer option= 3.=A0 If we use a reserved string, I prefer =93-Inf=94 in particular as it= is an IEEE standard for negative infinity, and many programming languages = support interpreting =93-Inf=94 as a parsable string resulting in a valid I= EEE float.

=A0<= /p>

[=

=A0=A0 =A0{ "freqHz&= quot;: 4.70e8, "maxPsdDbmPerBw": =A0null},

=A0=A0=A0 { "freqHz": 5.18e8, "ma= xPsdDbmPerBw": null },

=A0=A0=A0 { "freqHz": 5.18e8, "ma= xPsdDbmPerBw": 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "ma= xPsdDbmPerBw": 30.0 },

= ]

=A0<= /p>

or

=A0<= /p>

[=

=A0=A0 =A0{ "freqHz&= quot;: 4.70e8, "maxPsdDbmPerBw": =93-Inf=94},

=A0=A0=A0 { "freqHz": 5.18e8, "ma= xPsdDbmPerBw": =93-Inf=94},

=

=A0=A0=A0 { "freqHz": 5.18e8, "ma= xPsdDbmPerBw": 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "ma= xPsdDbmPerBw": 30.0 },

= ]

=A0<= /p>

=A0

From: paws-bounces@i= etf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: paws@ietf.org
Subject: [pa= ws] Encoding of spectrum profile

=A0

All,

=A0=

As was brought up before (and at) the= F2F, the current encoding for a spectrum profile

has a "channelized" view:

=A0- List of (startHz, stopHz= , power)

=A0- Has no abi= lity to specify power level in "unavailable" ranges=

=A0

Example:

= =A0 {

=A0 =A0 "poin= t": { "startHz": 5.18e8, "stopHz": 5.24e8, "m= axPsdDbmPerBw": 30.0 },

=A0 =A0 "point": { "startH= z": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": 36= .0 },

=A0 }

=A0

Question: Should we use a more flexible encoding?

=

=A0

There were two proposals made on the list:

=A0 - Option 1: List of (startHz, startPower, stopHz, st= opPower)

=A0 - Option 2:= Ordered list of (freqHz, power)

=A0

At the F2F, we agreed that Option 2 was the more general for= m.

=A0

=

Example:

=A0 {

=A0 =A0 &q= uot;point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": = -56.8 },

=A0 =A0 "point": { "freqHz= ": 5.18e8, "maxPsdDbmPerBw": -56.8 },

=A0 =A0 "point": { "freqHz"= ;: 5.18e8, "maxPsdDbmPerBw": 30.0 },

=A0 =A0 "point": { "freqHz= ": 5.24e8, "maxPsdDbmPerBw": 30.0 },

=

=A0 =A0 "point": { "freqHz"= : 5.24e8, "maxPsdDbmPerBw": 36.0 },

=A0 =A0 "point": { "freqHz= ": 5.30e8, "maxPsdDbmPerBw": 36.0 },

=

=A0 =A0 "point": { "freqHz"= : 5.30e8, "maxPsdDbmPerBw": -56.8 },

=A0 =A0 "point": { "freqHz= ": 6.98e8, "maxPsdDbmPerBw": -56.8 }

=

=A0 }


This exampl= e explicitly specifies the power levels in the unavailable frequency ranges= .

=A0

<= /div>

This example also shows that it's possible = to encode "square edges" by having two

points using the same frequency, but does allow fo= r "slanted edges" for more gentle roll-offs.

=A0

--
-vince


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


--001a11c334aa5af24504e51da79b-- From Ray.Bellis@nominet.org.uk Fri Aug 30 01:35:25 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD2321F9AF8 for ; Fri, 30 Aug 2013 01:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXmc0Qde1SsJ for ; Fri, 30 Aug 2013 01:35:20 -0700 (PDT) Received: from mx1.nominet.org.uk (mail.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13F11E80EA for ; Fri, 30 Aug 2013 01:35:15 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:MIME-Version; b=qMv4i8QQQEc+UwTmtpNzHOvOxFYiIJvTbk2mZP0jVf18MQvrWGaJd93O G7ZtxcyK99QpAt8Dj2T82/rm+e829uHCra9KvXfLIIqnoAT1+CK406QKp 0wWunqwO+iB/zBr; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1377851716; x=1409387716; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t5+DeaRl411/3QRwZRfw8Z9VPgCGOMgZdgJGaAjTYLo=; b=dwuemrRyi3Oow68zL39N7mcqsf5qdFSNf3o/4RrClEtJ1IUO5Pk4lVH4 cBXGgfZalur8z+DwNAUuH0C7HUL3Xcw0jN3fWSfiCAI3PhX3LcAZsmAdv bmfZH5zI+OxIKiR; X-IronPort-AV: E=Sophos;i="4.89,989,1367967600"; d="scan'208,217";a="2994518" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 30 Aug 2013 09:35:13 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Fri, 30 Aug 2013 09:35:13 +0100 From: Ray Bellis To: "Benjamin A. Rolfe" Thread-Topic: [paws] Encoding of spectrum profile Thread-Index: AQHOoeQCmU+qkDwvDUSLePEjGLDDY5msK74AgAAieYCAARTsAA== Date: Fri, 30 Aug 2013 08:35:12 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE74F78@wds-exc1.okna.nominet.org.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 08:35:25 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2wdsexc1oknanomi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 29 Aug 2013, at 17:04, Benjamin A. Rolfe > wrote: I too was confused by this, and *think* I have figured it out (perhaps inco= rrectly): "Unavailable" means the channel is not indicated as available at the specif= ic location and time of the query. Thus intentional radiation by a whitesp= ace device is not allowed. In real RF systems, a device transmitting in an = available channel near the unavailable channel will have some energy "spill= " outside the boundaries of the channel. The white space issued and propos= ed regulations I have reviewed have different definitions of what is allowe= d to "spill". I assume (dangerous word alert) that the intention is to all= ow communication of these different regulatory requirements. Hmm, ok... FCC regulations do not define "unavailable" but do specify limits on emissi= ons by TVWS devices outside of the TV channel being used, whether it is ind= icated as "available" or not. This is specified as a level relative to tran= smit signal level, not absolute dBm (" 72.8 dB below the highest average po= wer in the TV channel in which the device is operating."). For frequencies= beyond the TV channel adjacent to channel being used, maximum emissions ar= e defined as field strength (15.209). Representing the later is in dBm r= equires defining the parameters for conversion; Note FCC received multiple = comments suggesting changing the adjacent channel requirement to an absolut= e level and not relative to an actual level. I don't see how the FCC requ= irements as issued can be expressed in this format. The draft ETSI spec has a table (=A74.2.4.2.2, Table 3) giving permitted ad= jacent frequency leakage ratios. They also appear to be relative to the in= -block power rather than absolute values. In any event, how would this data model support the perfectly feasible scen= ario where a device is offered two adjacent channels, and therefore has "fu= ll power" available in either, but only choses to use one, and therefore mu= st limit its OOB transmissions in the other? If what you've described above is the real rationale (and other messages I'= ve seen suggest it is) then it seems to me that mixing together in-block po= wer levels and out-of-block power limits in the same frequency table is a b= ig mistake. There appears to be no way to encode the frequency parameters = to say "you may use 30 dBm in this channel if you're using it, but only lea= k -30 dBm into it if you use the adjacent channel instead". kind regards, Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2wdsexc1oknanomi_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On 29 Aug 2013, at 17:04, Benjamin A. Rolfe <ben@blindcreek.com> wrote:

I too was confused by this, and *think* I ha= ve figured it out (perhaps incorrectly):
"Unavailable" means the channel is not indicated as available at = the specific location and time of the query.  Thus intentional radiati= on by a whitespace device is not allowed. In real RF systems, a device tran= smitting in an available channel near the unavailable channel will have some energy "spill" outside the boundaries of = the channel.  The white space issued and proposed regulations I have r= eviewed have different definitions of what is allowed to "spill".=   I assume (dangerous word alert) that the intention is to allow communication of these different regulatory requirements. 

Hmm, ok...

FCC regulations do not define &qu= ot;unavailable" but do specify limits on emissions by TVWS devices out= side of the TV channel being used, whether it is indicated as "availab= le" or not. This is specified as a level relative to transmit signal level, not absolute dBm (" 72.8 dB below the highest average power in the TV channel in which the device i= s operating.").  For frequencies beyond the TV channel adjacent t= o channel being used, maximum emissions are defined as field strength (15.2= 09).    Representing the later is in dBm requires defining the parameters for conversion; Note FCC received multiple comment= s suggesting changing the adjacent channel requirement to an absolute level= and not relative to an actual level.   I don't see how the FCC r= equirements as issued can be expressed in this format.

The draft ETSI spec has a table (=A74.2.4.2.2, Table 3) giving permitt= ed adjacent frequency leakage ratios.  They also appear to be relative= to the in-block power rather than absolute values.

In any event, how would this data model support the perfectly feasible= scenario where a device is offered two adjacent channels, and therefore ha= s "full power" available in either, but only choses to use one, a= nd therefore must limit its OOB transmissions in the other?

If what you've described above is the real rationale (and other messag= es I've seen suggest it is) then it seems to me that mixing together in-blo= ck power levels and out-of-block power limits in the same frequency table i= s a big mistake.  There appears to be no way to encode the frequency parameters to say "you may use 3= 0 dBm in this channel if you're using it, but only leak -30 dBm into it if = you use the adjacent channel instead".

kind regards,

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2wdsexc1oknanomi_-- From tvfool@google.com Fri Aug 30 11:49:58 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25E921E805F for ; Fri, 30 Aug 2013 11:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+zjR8SbBnn0 for ; Fri, 30 Aug 2013 11:49:58 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B44BD21F9FF9 for ; Fri, 30 Aug 2013 11:49:57 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so3759423qae.5 for ; Fri, 30 Aug 2013 11:49:57 -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=G4dP8NkiKaHuRBUSE0WX0NonDLTA8GODT7dwNCAt8IY=; b=LLDeMOKxJ2Y1diQq/Wj8CGx5fgH3/jdCBnSByl1ADfvbeoeiwevieYcVm9npgrf1D6 MKr6Sa0E1Abst+IkQVBMHxSuYR07LIKsE5h5E5qKhc0vssQeb8R2xGsTgjfgXabN7+jC q0thTzcUjLftvkZzUQQAfBOrP7yBohgbqMBz7Xh0WaQCtbn5aVkeXNV5p+2ofRV9FchK Lb2b+Cy0avqhbjubW3gPIzkD3Ub6/CkcjcR5DtURQrJZjHu9HuYiITSZfHlW8R7Fi2DK zKzxqBHc4PAFrW6LyL/PfH7CzPgDSCNxWObgWiee9/v/6ZF+vMP6R3Y7AzV+xWWwGIOO KMVQ== 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=G4dP8NkiKaHuRBUSE0WX0NonDLTA8GODT7dwNCAt8IY=; b=eLCbGvmp/wuk02NyeKJIbviXQFV/yDmCy0trhaCzCOyQuYezNYSH1HpiXb0biIyLvh 6FDs2154wtSsRuTClMP6eolKvF56FjuN9meUxJY+75WRI3FLgXIZMDKqm1atg49OplTU vswLSCPAae8ev8gPFarmOACdBbqSdpRQh1REbw2WveTJIPuoyRkJ5qw0rYiPqGdZJhow BoXU8owZaV9hSNNhRHcKsSA/+gFVaoOrdpri3EcpC2wy+Hs6a9Pky+wXFpapT5IBg5NZ P1g/PMnBE6RAPExSq+5gND5zsAUPgc0LSbMdfMle8Cb0pkrk5pDgbV7Mska4wtWH266W SAuA== X-Gm-Message-State: ALoCoQlB++0SqQ7DneJrHNPt7SDAmxHn4lE4QUz3yd821GEMSfy2MuJRHHv1fjin54HDM/zE8VkgL3G5LVZwBczxXBjPZnXJegHWtkD4x7YprHeDpuDiiZhV9m1ckrX+Rzg3ppneFEMy3Z5m9ki9mfEjvqW5Tq6XWj5HkVTjqLcLn+SuVWhd9YIK4Oaud7NDbprOItad5Ynr MIME-Version: 1.0 X-Received: by 10.224.24.134 with SMTP id v6mr13892336qab.58.1377888597059; Fri, 30 Aug 2013 11:49:57 -0700 (PDT) Received: by 10.229.149.212 with HTTP; Fri, 30 Aug 2013 11:49:56 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE74F78@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE762C2@wds-exc1.okna.nominet.org.uk> Date: Fri, 30 Aug 2013 11:49:56 -0700 Message-ID: From: Andy Lee To: Ray Bellis Content-Type: multipart/alternative; boundary=001a11c252c65e410d04e52eb023 Cc: "" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:49:59 -0000 --001a11c252c65e410d04e52eb023 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis wrote: > If what you've described above is the real rationale (and other messages > I've seen suggest it is) then it seems to me that mixing together in-bloc= k > power levels and out-of-block power limits in the same frequency table is= a > big mistake. There appears to be no way to encode the frequency paramete= rs > to say "you may use 30 dBm in this channel if you're using it, but only > leak -30 dBm into it if you use the adjacent channel instead". My interpretation is that the PAWS spectrum profile is expressing what is permissible under the local white space rules and is completely separate from the hardware OOB emission limits. In the case of the FCC, the permissible white space power is specified as absolute in-band power limits (36 dBm/6MHz EIRP fixed, 20 dBm/6MHz mode 2, and 16 dBm/6MHz mode 1), and specific absolute out-of-band power limits (-36.8 dBm/6MHz EIRP fixed, -56.8 dBm/6MHz any portable device on an adjacent channel, and -52.8 dBm/6MHz any other portable device), as specified in CFR Title 47, section 15.709. The FCC has additional special requirements around channel 37 as specified by the field strength table in section 15.709(c)(4). In the case of Ofcom, the permissible white space power is calculated individually per-channel for DTT and PMSE, resulting in a different power level for every 8 MHz and 100 kHz channel. There isn't really a distinction between "in-band" and "out-of-band" emissions when a continuum of power levels are possible. The spectrum database simply provides this list of permitted frequencies and power levels over the PAWS protocol. The profile of permitted spectrum could include adjacent channels in some places. It is then the device's responsibility to select which subset of frequencies it will actually use, in accordance with local regulation. At the time the device is built (and presumably as part of the device certification process), it must comply with several in-band and out-of-band emissions requirements (whether they are specified as relative values or absolute), but this has nothing to do with the spectrum availability offerings being communicated over PAWS. For example, Ofcom has specific adjacent channel leakage ratio (ACLR) requirements for devices to qualify as a Class 1, 2, 3, or 4 white space device. Once hardware is built, the ACLR performance of a device is essentially fixed, and there's nothing in the PAWS spectrum message that would change that. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis wrot= e: > > On 29 Aug 2013, at 17:04, Benjamin A. Rolfe wrote: > > I too was confused by this, and *think* I have figured it out (perhaps > incorrectly): > "Unavailable" means the channel is not indicated as available at the > specific location and time of the query. Thus intentional radiation by a > whitespace device is not allowed. In real RF systems, a device transmitti= ng > in an available channel near the unavailable channel will have some energ= y > "spill" outside the boundaries of the channel. The white space issued an= d > proposed regulations I have reviewed have different definitions of what i= s > allowed to "spill". I assume (dangerous word alert) that the intention i= s > to allow communication of these different regulatory requirements. > > > Hmm, ok... > > FCC regulations do not define "unavailable" but do specify limits on > emissions by TVWS devices outside of the TV channel being used, whether i= t > is indicated as "available" or not. This is specified as a level relative > to transmit signal level, not absolute dBm (" 72.8 dB below the highest > average power in the TV channel in which the device is operating."). For > frequencies beyond the TV channel adjacent to channel being used, maximum > emissions are defined as field strength (15.209). Representing the lat= er > is in dBm requires defining the parameters for conversion; Note FCC > received multiple comments suggesting changing the adjacent channel > requirement to an absolute level and not relative to an actual level. I > don't see how the FCC requirements as issued can be expressed in this > format. > > > The draft ETSI spec has a table (=A74.2.4.2.2, Table 3) giving permitted > adjacent frequency leakage ratios. They also appear to be relative to th= e > in-block power rather than absolute values. > > In any event, how would this data model support the perfectly feasible > scenario where a device is offered two adjacent channels, and therefore h= as > "full power" available in either, but only choses to use one, and therefo= re > must limit its OOB transmissions in the other? > > If what you've described above is the real rationale (and other messages > I've seen suggest it is) then it seems to me that mixing together in-bloc= k > power levels and out-of-block power limits in the same frequency table is= a > big mistake. There appears to be no way to encode the frequency paramete= rs > to say "you may use 30 dBm in this channel if you're using it, but only > leak -30 dBm into it if you use the adjacent channel instead". > > kind regards, > > Ray > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --001a11c252c65e410d04e52eb023 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 30, 2013 at 1:35 AM, Ray Bellis=A0<Ra= y.Bellis@nominet.org.uk>=A0wrote:
If what you've described above is the rea= l rationale (and other messages I've seen suggest it is) then it seems = to me that mixing together in-block power levels and out-of-block power lim= its in the same frequency table is a big mistake. =A0There appears to be no= way to encode the frequency parameters to say "you may use 30 dBm in = this channel if you're using it, but only leak -30 dBm into it if you u= se the adjacent channel instead".

My interpretation is that the PAWS spectrum profile is = expressing what is permissible under the local white space rules and is com= pletely separate from the hardware OOB emission limits.

In the case of the FCC, the permissible white space power is specified= as absolute in-band power limits (36 dBm/6MHz EIRP fixed, 20 dBm/6MHz mode= 2, and 16 dBm/6MHz mode 1), and specific absolute out-of-band power limits= (-36.8 dBm/6MHz EIRP fixed, -56.8 dBm/6MHz any portable device on an adjac= ent channel, and -52.8 dBm/6MHz any other portable device), as specified in= CFR Title 47, section 15.709. =A0The FCC has additional special requiremen= ts around channel 37 as specified by the field strength table in section 15= .709(c)(4).

In the case of Ofcom, the permissible white space power= is calculated individually per-channel for DTT and PMSE, resulting in a di= fferent power level for every 8 MHz and 100 kHz channel. =A0There isn't= really a distinction between "in-band" and "out-of-band&quo= t; emissions when a continuum of power levels are possible.

The spectrum database simply provides this list of perm= itted frequencies and power levels over the PAWS protocol. =A0The profile o= f permitted spectrum could include adjacent channels in some places. =A0It = is then the device's responsibility to select which subset of frequenci= es it will actually use, in accordance with local regulation.

At the time the device is built (and presumably as part= of the device certification process), it must comply with several in-band = and out-of-band emissions requirements (whether they are specified as relat= ive values or absolute), but this has nothing to do with the spectrum avail= ability offerings being communicated over PAWS. =A0For example, Ofcom has s= pecific adjacent channel leakage ratio (ACLR) requirements for devices to q= ualify as a Class 1, 2, 3, or 4 white space device. =A0Once hardware is bui= lt, the ACLR performance of a device is essentially fixed, and there's = nothing in the PAWS spectrum message that would change that.




On Fri, Aug 30, 2013 at 1:35 AM, Ray Bel= lis <Ray.Bellis@nominet.org.uk> wrote:

On 29 Aug 2013, at 17:04, Benjamin A. Rolfe <ben@blindcreek.com> wrote:

I too was confused by this, and *think* I have figured it out (perhaps= incorrectly):
"Unavailable" means the channel is not indicated as available at = the specific location and time of the query.=A0 Thus intentional radiation = by a whitespace device is not allowed. In real RF systems, a device transmi= tting in an available channel near the unavailable channel will have some energy "spill" outside the boundaries of = the channel.=A0 The white space issued and proposed regulations I have revi= ewed have different definitions of what is allowed to "spill".=A0= I assume (dangerous word alert) that the intention is to allow communication of these different regulatory requirements.=A0

Hmm, ok...

FCC regulations do not define &qu= ot;unavailable" but do specify limits on emissions by TVWS devices out= side of the TV channel being used, whether it is indicated as "availab= le" or not. This is specified as a level relative to transmit signal level, not absolute dBm (" =20 72.8 dB below the highest average power in the TV channel in which the device i= s operating.").=A0 For frequencies beyond the TV channel adjacent to c= hannel being used, maximum emissions are defined as field strength (15.209)= . =A0=A0 Representing the later is in dBm requires defining the parameters for conversion; Note FCC received multiple comment= s suggesting changing the adjacent channel requirement to an absolute level= and not relative to an actual level.=A0=A0 I don't see how the FCC req= uirements as issued can be expressed in this format.

The draft ETSI spec has a table (=A74.2.4.2.2, Table 3) giving p= ermitted adjacent frequency leakage ratios. =A0They also appear to be relat= ive to the in-block power rather than absolute values.

In any event, how would this data model support the perfectly feasible= scenario where a device is offered two adjacent channels, and therefore ha= s "full power" available in either, but only choses to use one, a= nd therefore must limit its OOB transmissions in the other?

If what you've described above is the real rationale (and other me= ssages I've seen suggest it is) then it seems to me that mixing togethe= r in-block power levels and out-of-block power limits in the same frequency= table is a big mistake. =A0There appears to be no way to encode the frequency parameters to say "you may use 3= 0 dBm in this channel if you're using it, but only leak -30 dBm into it= if you use the adjacent channel instead".

kind regards,

Ray


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


--001a11c252c65e410d04e52eb023-- From tvfool@google.com Fri Aug 30 12:43:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803711E8113 for ; Fri, 30 Aug 2013 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MErFMo7BT34J for ; Fri, 30 Aug 2013 12:43:43 -0700 (PDT) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AE3B021F9F13 for ; Fri, 30 Aug 2013 12:43:40 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id b4so1189782qen.20 for ; Fri, 30 Aug 2013 12:43:40 -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=yJ/lhOSLam7eDtQF5TRLJxOKff0A2LMJOM/0n+ccLZc=; b=gHtt2PLF5DGse67of0Q6ZXoFTFOT+NW4YWacyXVig0rzDx1UlItQ3XvOYPX7cn48mM gpb4Q7MmoV8iLjK9SvpR9tK0lQqsel0vUyFV1iZASaXkE9IL016VOGKRFKjUUZD7Xb+4 NXVm9wyFKh2J/jM/Wey1l2lSQIzVt29iV0rjfLAVt6F+eNzK9cTgbRhmeXCGuLcp054Q eageMfvDqiBN8rg/001wmR9rPmQVOvDor8oREHdBnv9xCngvuDneqvXqEOqr2E4RNUXC AhuXC4sfKrRLmGKv8fkxMVUCXOgQ/jwk9i5UTxDkOTEAzmFNZDTmTz1tOXGJX5VgWmDr 5V1w== 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=yJ/lhOSLam7eDtQF5TRLJxOKff0A2LMJOM/0n+ccLZc=; b=J1/Atz3weuwXoItX2/NqmfBnnaV827JgqZ+aEhwIJqsj4wz7IfpDZpCC3Jrejbsf6z 93DmeR+sgZYKBCMDwTP+v9++IEgm6EVvjmT22Gk17kgH2WUS9XDjeGPAoqEEHKbwvj92 GmqXrg8SV8qeZbJG6ykyJqz7XHjOnORJfvUBAWwUdevByrTOnt4bu6624t6z49LseiWh XswWj71sQ/VK5aEOhY5M0EeCs/3+Nx3urup9A6qAVU5lDKYPZ+Lif1RY/sYxaJZmk29l V0tGMP3EJnS+wX2SDyxfXzMFgvj66s27oSRTGiMTLOt5fbrqTsP8fBK1C3544l1nQHVQ hIbg== X-Gm-Message-State: ALoCoQlF5ErvLUL/zoy+tsnkZfeW2fm+Pc8WYL8UcUgWr8FaMuju/3LKFC5OzdADzGXeDvxwMo51I0PYzBEIXH5SGHQd/u1watYRzMjNuDeUSm5CmjmaMfuY9ECIDBvGFcX3e1f+AmuBObYGXuWEaweLbZkMUBA6qtE16JxfSBlZAdrnZgAYAfZVZ0iiQ8J58iP6x1OdJboq MIME-Version: 1.0 X-Received: by 10.49.96.200 with SMTP id du8mr4558521qeb.89.1377891820048; Fri, 30 Aug 2013 12:43:40 -0700 (PDT) Received: by 10.229.149.212 with HTTP; Fri, 30 Aug 2013 12:43:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 30 Aug 2013 12:43:39 -0700 Message-ID: From: Andy Lee To: Kalle Kuismanen Content-Type: multipart/alternative; boundary=047d7bb048a279365304e52f7027 Cc: "paws@ietf.org" Subject: Re: [paws] Encoding of spectrum profile X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:43:44 -0000 --047d7bb048a279365304e52f7027 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J wrote: > *How to Indicate =93Unavailable=94 > * > There are a few options to indicate that a subband is =93unavailable=94. > 1) **The spec could state a value that means =93unavailable=94, such= as > -100, -1000.0, or -56.8. > ****2) **The spec could not state that value, and the Database could > choose an arbitrary small number at its discretion. > ****3) **The spec could state that the JSON value *null* means > =93unavailable=94, or a reserved string such as =93-Inf=94 ** ** ** In the case of Ofcom white space rules, I believe that a power level will be computed for every channel, albeit very low on some channels. In the case of the FCC, there are also specific levels specified for OOB white space emissions. For Industry Canada, the FCC, and probably everywhere, there are also generalized limits on unintended EM emissions (e.g., IC "RSS-Gen" and FCC "Part 15" rules). This should make it possible to specify a theoretical power "floor" without having to resort to weirdness like "-Inf" or "null" values. It would be much better to fill in real values based on actual rules from the regulator. Andy Lee | Google Inc. | tvfool@google.com | 408-230-0522 On Thu, Aug 29, 2013 at 3:30 PM, Kalle Kuismanen < kalle.kuismanen@fairspectrum.com> wrote: > Hi All, > > I haven't participated in the discussion much, but I just had to solve > this very issue about a week ago so here a my two cents: > > on the issue of "-Inf" or null. We've also used in our paws and other > protocol implementation "-Inf" as indication of channel being unavailable= , > but problem is that it's somewhat misleading. For example if a channel is > "usable" only above 20 dBm and we calculate maximum transmission to be 19 > dBm it is bit silly to send -Inf. Null value is even more misleading, > because it usually indicates that we don't know what the value is, which = in > this case probably would mean an implementation error in the calculation > code. > > Then of course considering the implementation. I tried to use in our paws > implementation "-Inf", but of course Javascript doesn't recognize that > string as a number, so it causes a type casting problem i.e. sometimes t= he > value is a number and sometimes a string. Which of course led to first ou= r > server not validating the JSON against the PAWS schema and then when I by > passed that (bad thing, but I was in a rush) our test client side > validation failed also. > > See below how I decided it should be solved, but in the end, because > didn't want to burden the device side implementers I just dropped the > channels that couldn't be used from the array. > > On the client side or device side the JSON needs to be checked for the > special value or a simple field will suffice. Mutable nature of JSON make= s > it easy. > > On client side the code would check in Javascript in node.js: > > var a =3D [ > { "freqHz": 4.70e8, "unavailable": true}, > { "freqHz": 5.18e8, "unavailable": true}, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > ]; > var b =3D ""; > > for(var f in a) > { > if(a[f]["unavailable"]!=3D=3Dtrue) > b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; > } > > process.stdout.write( b ); > > This is not so different from using "-Inf" or "null" implementation. > > var a =3D [ > { "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"}, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": "-Inf"}, > { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 }, > { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 }, > ]; > var b =3D ""; > > for(var f in a) > { > if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf") > b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n"; > } > process.stdout.write( b ); > > Both cases usually just do one comparison. But as I said first version > preserves type of maxPsdDbmPerBw other does not. Both cost about the same > on the wire. > > But of course this is just a suggestion. JSON is very malleable. > > Cheers, > Kalle Kuismanen > FairSpectrum > > > On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J < > dharasty@appcomsci.com> wrote: > >> ** ** >> >> I rather prefer option 2, but I realize this is more a point of personal >> taste; I think either are workable.**** >> >> ** ** >> >> Regarding option 2, I have the following comments. (Some may apply to >> option 1, also.)**** >> >> ** ** >> >> *Ordering Matters* >> >> **** >> >> I think the spec should require that the =93points=94 be in >> frequency-increasing order of =93freqHz=94 value. (The need is obvious,= so >> let=92s state it as a requirement.)**** >> >> ** ** >> >> Two =93points=94 may have the same =93freqHz=94 value; their order is >> significant, too. (For example, the first four points in Vince=92s exam= ple >> constitute a =93step function=94. However, if points #2 and #3 were swa= pped, >> it would indicate a =93sawtooth=94 spectral mask.)**** >> >> ** ** >> >> Three (or more) =93points=94 may NOT share a =93freqHz=94 value.**** >> >> ** ** >> >> *Should be an Array* >> >> ** ** >> >> I think the term =93point=94 is rather vague, an repeatedly re-using it = in a >> single object can=92t be kosher. **** >> >> ** ** >> >> Thus, I propose this structure be an array of objects:**** >> >> ** ** >> >> [**** >> >> { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },**** >> >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },**** >> >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >> >> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >> >> .**** >> >> .**** >> >> .**** >> >> ]**** >> >> ** ** >> >> *How to Indicate =93Unavailable=94* >> >> ** ** >> >> There are a few options to indicate that a subband is =93unavailable=94.= **** >> >> **1) **The spec could state a value that means =93unavailable=94, s= uch >> as -100, -1000.0, or -56.8.**** >> >> **2) **The spec could not state that value, and the Database could >> choose an arbitrary small number at its discretion.**** >> >> **3) **The spec could state that the JSON value *null* means >> =93unavailable=94, or a reserved string such as =93-Inf=94**** >> >> ** ** >> >> I rather prefer option 3. If we use a reserved string, I prefer =93-Inf= =94 >> in particular as it is an IEEE standard for negative infinity, and many >> programming languages support interpreting =93-Inf=94 as a parsable stri= ng >> resulting in a valid IEEE float.**** >> >> ** ** >> >> [**** >> >> { "freqHz": 4.70e8, "maxPsdDbmPerBw": null},**** >> >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": null },**** >> >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >> >> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >> >> ]**** >> >> ** ** >> >> or**** >> >> ** ** >> >> [**** >> >> { "freqHz": 4.70e8, "maxPsdDbmPerBw": =93-Inf=94},**** >> >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": =93-Inf=94},**** >> >> { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >> >> { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >> >> ]**** >> >> ** ** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *Vincent Chen >> *Sent:* Sunday, August 25, 2013 6:40 PM >> *To:* paws@ietf.org >> *Subject:* [paws] Encoding of spectrum profile**** >> >> ** ** >> >> All,**** >> >> ** ** >> >> As was brought up before (and at) the F2F, the current encoding for a >> spectrum profile**** >> >> has a "channelized" view:**** >> >> - List of (startHz, stopHz, power)**** >> >> - Has no ability to specify power level in "unavailable" ranges**** >> >> ** ** >> >> Example:**** >> >> {**** >> >> "point": { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdDbmPerBw": >> 30.0 },**** >> >> "point": { "startHz": 5.24e8, "stopHz": 5.30e8, "maxPsdDbmPerBw": >> 36.0 },**** >> >> }**** >> >> ** ** >> >> Question: Should we use a more flexible encoding?**** >> >> ** ** >> >> There were two proposals made on the list:**** >> >> - Option 1: List of (startHz, startPower, stopHz, stopPower)**** >> >> - Option 2: Ordered list of (freqHz, power)**** >> >> ** ** >> >> At the F2F, we agreed that Option 2 was the more general form.**** >> >> ** ** >> >> Example:**** >> >> {**** >> >> "point": { "freqHz": 4.70e8, "maxPsdDbmPerBw": -56.8 },**** >> >> "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": -56.8 },**** >> >> "point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 30.0 },**** >> >> "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 30.0 },**** >> >> "point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36.0 },**** >> >> "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },**** >> >> "point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -56.8 },**** >> >> "point": { "freqHz": 6.98e8, "maxPsdDbmPerBw": -56.8 }**** >> >> }**** >> >> >> **** >> >> This example explicitly specifies the power levels in the unavailable >> frequency ranges.**** >> >> ** ** >> >> This example also shows that it's possible to encode "square edges" by >> having two**** >> >> points using the same frequency, but does allow for "slanted edges" for >> more gentle roll-offs.**** >> >> ** ** >> >> -- >> -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 > > --047d7bb048a279365304e52f7027 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 29, 2013 at 1:33 PM, Harasty, Daniel J=A0<dharasty@appcomsci.com>=A0wrote:

How to Indicate =93Unavailable=94
=A0
There are a few options to indicat= e that a subband is =93unavailable=94.
1)=A0=A0=A0=A0=A0=A0The spec could sta= te a value that means =93unavailable=94, such as -100, -1000.0, or -56.8. 2)=A0=A0=A0=A0=A0=A0The= spec could not state that value, and the Database could choose an arbitrar= y small number at its discretion.
3)=A0=A0=A0=A0=A0=A0The= spec could state that the JSON value=A0null=A0means =93unavailable=94, or a reserved string such as =93-Inf= =94

In the case of Ofcom white space rules, I believe that a power level will b= e computed for every channel, albeit very low on some channels.

In the case of th= e FCC, there are also specific levels specified for OOB white space emissio= ns.

For Industr= y Canada, the FCC, and probably everywhere, there are also generalized limi= ts on unintended EM emissions (e.g., IC "RSS-Gen" and FCC "P= art 15" rules). =A0This should make it possible to specify a theoretic= al power "floor" without having to resort to weirdness like "= ;-Inf" or "null" values. =A0It would be much better to fill = in real values based on actual rules from the regulator.


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


On Thu, Aug 29, 2013 at 3:30 PM, Kalle K= uismanen <kalle.kuismanen@fairspectrum.com> w= rote:
Hi All,

I haven't = participated in the discussion much, but I just had to solve this very issu= e about a week ago so here a my two cents:

on the issue of "-Inf" or null. We've als= o used in our paws and other protocol implementation "-Inf" as in= dication of channel being unavailable, but problem is that it's somewha= t misleading. For example if a channel is "usable" only above 20 = dBm and we calculate maximum transmission to be 19 dBm it is bit silly to s= end -Inf. Null value is even more misleading, because it usually indicates = that we don't know what the value is, which in this case probably would= mean an implementation error in the calculation code.

Then of course considering the implementation. I tried = to use in our paws implementation "-Inf", but of course Javascrip= t doesn't recognize that string =A0as a number, so it causes a type cas= ting problem i.e. sometimes the value is a number and sometimes a string. W= hich of course led to first our server not validating the JSON against the = PAWS schema and then when I by passed that (bad thing, but I was in a rush)= our test client side validation failed also.

See below how I decided it should be solved, but in the= end, because didn't want to burden the device side implementers I just= dropped the channels that couldn't be used from the array.

On the client side or device side the JSON needs to be check= ed for the special value or a simple field will suffice. Mutable nature of = JSON makes it easy.

On client side the code would = check in Javascript in node.js:

var a =3D [=
=A0 =A0 { "fre= qHz": 4.70e8, "unavailable": true},=A0
=A0 =A0 { "freqHz": 5.18e8, &qu= ot;unavailable": true},
=A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz": 5.24e8, "maxPsdDbm= PerBw": 30.0 },
];
var b =3D "";

for(var f in a)
=A0 =A0 {
=A0 =A0 if(a[f]["unavailable"]!= =3D=3Dtrue)=A0
=A0 = =A0 =A0 =A0 b +=3D a[f].freqHz+":"+a[f].maxPsdDbmPerBw+"\n&q= uot;;
=A0 =A0 }

process.stdout.write( b );

This is not so different from using "-Inf" or "null" = implementation.

var a = =3D [
=A0 =A0 {= "freqHz": 4.70e8, "maxPsdDbmPerBw": "-Inf"},= =A0
=A0 =A0 { "freqHz": 5.= 18e8, "maxPsdDbmPerBw": "-Inf"},
=A0 =A0 { "freqHz": 5.18e8, &quo= t;maxPsdDbmPerBw": 30.0 },
=A0 =A0 { "freqHz": 5.= 24e8, "maxPsdDbmPerBw": 30.0 },
];
var b =3D "";

for(var f in a)
=A0 =A0 {
=A0 =A0 if(a[f]["maxPsdDbmPerBw"]!=3D=3D"-Inf&= quot;)
=A0 =A0 =A0 =A0 b +=3D a[f].freq= Hz+":"+a[f].maxPsdDbmPerBw+"\n";
=A0 =A0 }
process.stdout.write( b );
maxPsdDbmPerBw other does not. Both cost ab= out the same on the wire.=A0

But of course this is just a suggestion. JSON is very m= alleable.

Cheers,
Kalle Kuismanen
FairSpectrum


On Thu, Aug 29, 2013 at 11:33 PM, Harasty, Daniel J <<= a href=3D"mailto:dharasty@appcomsci.com" target=3D"_blank">dharasty@appcoms= ci.com> wrote:

= =A0

I rather prefer option 2, but I realize thi= s is more a point of personal taste; I think either are workable.=

=A0

Regarding option 2, I hav= e the following comments.=A0 (Some may apply to option 1, also.)<= /u>

=A0

Ordering Matters

I think the spec should req= uire that the =93points=94 be in frequency-increasing order of =93freqHz=94= value.=A0 (The need is obvious, so let=92s state it as a requirement.)<= /u>

=A0

Two =93points=94 may have= the same =93freqHz=94 value; their order is significant, too.=A0 (For exam= ple, the first four points in Vince=92s example constitute a =93step functi= on=94.=A0 However, if points #2 and #3 were swapped, it would indicate a = =93sawtooth=94 spectral mask.)

=A0

Three (or more) =93points= =94 may NOT share a =93freqHz=94 value.

=A0

Should be an Array<= /u>

=A0

I think the term =93point= =94 is rather vague, an repeatedly re-using it in a single object can=92t b= e kosher.=A0

=A0

Thus, I propose this stru= cture be an array of objects:

=A0

[

=A0=A0 =A0{ "freqHz": 4.70e8, "maxPsdDbmPerB= w": -56.8 },

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPer= Bw": -56.8 },

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw&quo= t;: 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw":= 30.0 },

=A0=A0 .

=A0=A0 .

=A0=A0 .

]

=A0

How to Indicate =93Unavailable=94

=A0

There are a few options to indicate that a subband is =93unavail= able=94.

1)=A0=A0=A0=A0=A0 The spec could state a value that means =93un= available=94, such as -100, -1000.0, or -56.8.

2)=A0=A0=A0=A0=A0 The= spec could not state that value, and the Database could choose an arbitrar= y small number at its discretion.

3)=A0=A0=A0=A0=A0 The= spec could state that the JSON value null<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)"> means =93unavailable=94, or a reserved string such as =93-Inf=94=

=A0

I rather prefer option 3.= =A0 If we use a reserved string, I prefer =93-Inf=94 in particular as it is= an IEEE standard for negative infinity, and many programming languages sup= port interpreting =93-Inf=94 as a parsable string resulting in a valid IEEE= float.

=A0

[

=A0=A0 =A0{ "freqHz": 4.70e8, "maxPsdDbmPerBw&quo= t;: =A0null},

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= null },

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw":= 30.0 },

]

=A0

or

=A0

[

=A0=A0 =A0{ "freqHz": 4.70e8, "maxPsdDbmPerBw&quo= t;: =93-Inf=94},

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= =93-Inf=94},

=A0=A0=A0 { "freqHz": 5.18e8, "maxPsdDbmPerBw":= 30.0 },

=A0=A0=A0 { "freqHz": 5.24e8, "maxPsdDbmPerBw":= 30.0 },

]

=A0

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On B= ehalf Of Vincent Chen
Sent: Sunday, August 25, 2013 6:40 PM
To: paws@ietf.org
Subject: [pa= ws] Encoding of spectrum profile

=A0

All,

=A0

As was brought up before (and at) the F2F,= the current encoding for a spectrum profile

has a "channelized" view:

=A0- List of (startHz, stopHz, power)

= =A0- Has no ability to specify power level in "unavailable" range= s

=A0

Example:

=

=A0 {

=A0 =A0 "point"= ;: { "startHz": 5.18e8, "stopHz": 5.24e8, "maxPsdD= bmPerBw": 30.0 },

=A0 =A0 "point": { "startHz": 5.24e8, &qu= ot;stopHz": 5.30e8, "maxPsdDbmPerBw": 36.0 },<= /p>

=A0 }

=A0

Question: Should we use a more f= lexible encoding?

=A0

There were two proposals made on the list:

= =A0 - Option 1: List of (startHz, startPower, stopHz, stopPower)<= /u>

=A0 - Option 2: Ordered list of (freqHz, power)=

=A0

At the F2F, we agreed that= Option 2 was the more general form.

= =A0

Example:

=A0 {

=A0 =A0 "point": { "freqHz": 4.70e8, "maxPsdD= bmPerBw": -56.8 },

=A0 =A0 "point": { "freqHz": 5.18e8, &quo= t;maxPsdDbmPerBw": -56.8 },

=A0 =A0 &qu= ot;point": { "freqHz": 5.18e8, "maxPsdDbmPerBw": 3= 0.0 },

=A0 =A0 "point": { "freqHz": 5.24e8, &quo= t;maxPsdDbmPerBw": 30.0 },

=A0 =A0 &quo= t;point": { "freqHz": 5.24e8, "maxPsdDbmPerBw": 36= .0 },

=A0 =A0 "point": { "freqHz": 5.30e8, &quo= t;maxPsdDbmPerBw": 36.0 },

=A0 =A0 &quo= t;point": { "freqHz": 5.30e8, "maxPsdDbmPerBw": -5= 6.8 },

=A0 =A0 "point": { "freqHz": 6.98e8, &quo= t;maxPsdDbmPerBw": -56.8 }

=A0 }=


This example explicitly specifi= es the power levels in the unavailable frequency ranges.

<= /div>

=A0

This example also shows that it's possible to encode "squa= re edges" by having two

points using th= e same frequency, but does allow for "slanted edges" for more gen= tle roll-offs.

=A0

--
-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


--047d7bb048a279365304e52f7027--