From Cesar.Gutierrez@ofcom.org.uk Tue Jul 9 09:01:53 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 E66A921F8EDF for ; Tue, 9 Jul 2013 09:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.738 X-Spam-Level: X-Spam-Status: No, score=-0.738 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 BY2U2QoCvHtn for ; Tue, 9 Jul 2013 09:01:49 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.139]) by ietfa.amsl.com (Postfix) with ESMTP id 93C9A21F8793 for ; Tue, 9 Jul 2013 09:01:43 -0700 (PDT) Received: from [85.158.139.211:59353] by server-3.bemta-5.messagelabs.com id 99/76-09186-5E33CD15; Tue, 09 Jul 2013 16:01:41 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-9.tower-206.messagelabs.com!1373385701!19375058!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.9; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13207 invoked from network); 9 Jul 2013 16:01:41 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-9.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 9 Jul 2013 16:01:41 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 9 Jul 2013 17:01:40 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Tue, 9 Jul 2013 17:01:41 +0100 From: Cesar Gutierrez To: "paws@ietf.org" Thread-Topic: [paws] Update on ETSI Harmonised Standard and UK trial Thread-Index: Ac58vZjiANg8r8ZPQjeznrS86GkKhQ== Date: Tue, 9 Jul 2013 16:01:39 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE996A49@WOK-INTRA-EXC02.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_5D3E853BEE49C848BB63047C794C8655AE996A49WOKINTRAEXC02in_" MIME-Version: 1.0 Subject: [paws] Update on ETSI Harmonised Standard and UK trial X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:01:54 -0000 --_000_5D3E853BEE49C848BB63047C794C8655AE996A49WOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We discussed a while ago the requirements for operation in Europe and how t= hese requirements are captured in the Harmonised Standard being developed b= y ETSI. Please note that this Harmonised Standard (EN 301 598) is now publ= icly available for download and subject to a public enquiry phase (http://= www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.00_20/en_301598v010= 000a.pdf) We will be conducting a White Spaces trial in the UK in the last quarter of= this year. We will trial an end to end system, with most of the functional= ity that we expect in the full solution including communications between da= tabases and devices. Several organisations have confirmed participation in = this trial and Ofcom is currently engaging with them to fine-tune the techn= ical and regulatory details. You can learn more about this trial at: http://stakeholders.ofcom.org.uk/spectrum/tv-white-spaces/white-spaces-pilo= t/ Don't hesitate to contact me if you are interested in participating. Regards, Cesar ________________________________ ***************************************************************************= *************************************** 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_5D3E853BEE49C848BB63047C794C8655AE996A49WOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We discussed a while ago the requirements for operat= ion in Europe and how these requirements are captured in the Harmonised Sta= ndard being developed by ETSI.  Please note that this Harmonised Stand= ard (EN 301 598) is now publicly available for download  and subject to a public enquiry phase (http://www.etsi.org/deliver/etsi_en/301500_301599/301598/01.00.= 00_20/en_301598v010000a.pdf)

 

We will be conducting a White Spaces trial in the UK= in the last quarter of this year. We will trial an end to end system, with= most of the functionality that we expect in the full solution including co= mmunications between databases and devices. Several organisations have confirmed participation in this trial = and Ofcom is currently engaging with them to fine-tune the technical and re= gulatory details. You can learn more about this trial at:

http://stakeholders.ofcom.org.uk/spec= trum/tv-white-spaces/white-spaces-pilot/

Don’t hesitate to contact me if you are intere= sted in participating.

 

Regards,

Cesar



***************************************************************************= ***************************************
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_5D3E853BEE49C848BB63047C794C8655AE996A49WOKINTRAEXC02in_-- From vchen@google.com Mon Jul 15 14:56: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 9991321F9FFC for ; Mon, 15 Jul 2013 14:56:57 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 b3v938XAgvT5 for ; Mon, 15 Jul 2013 14:56:56 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6199E21E813A for ; Mon, 15 Jul 2013 14:56:34 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so16428039oah.11 for ; Mon, 15 Jul 2013 14:56:28 -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=mkzW/ybDbsIuGuIOAHQys4sIBvL4pC0uNCV22nMoFKI=; b=kJVuhQERfHnGozw5v87CnneRC9JLDZFLuD3j03oGVRSIDMtdrVsBgRzgEGH6UNNAY4 SCtMjHtz7ruJ0hH/hsiWWlWLl6FjWpeBWOpzawV6nx4GhCXYJt6nujSgpVDcGgx0H3R0 9gBObeyioBUu2Hje5trJ/68UJx0lzv9Kl+L6VrCFVAnrejxKi7xxXGm8jcwlJan0YKbx i7DchwRh47qVVArAh/B/YAnmIFv5nqZsyccK4fd9PvujK/pDX+ZsWEigMM7zUh6Kb6Q2 AneEilULDDT/0Zth/iMJcj9Wc1K24/wg3flbMIqwOnQOWV8rVDjEEYq73ON7cIVUFV57 a22Q== X-Google-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:x-gm-message-state; bh=mkzW/ybDbsIuGuIOAHQys4sIBvL4pC0uNCV22nMoFKI=; b=GwzSw15Z+Xnx2KV9ZK+bX2RZmWNADSwzA0tZ01FyVwca/e4uYJS3zkm30ozkFjHk8g M2NAtw1+r6J34lDjIux56sHiPIp5F0Prk0RmXGdCtf/4v88hcZVbgBrn8ilVwtawUOZk fyE2299VnCJ2r0T+18OBsOtv9SRM6DeFFY3guabyuvqN0wHGFiTTZykjH/2wFjsajU0f qzzbfe8FMXS07pNgRTQMD+RO2mtlp2LnhrpCN2mdJRw3stP1OGzpfO4ql25TNCvQm/I0 2PVi/2ev/z0hRLhUf2zjquen69hXxrNtPWcLSNWW1ROnkUi6XvYdVifNsiiUmyG3WJTK bcpA== MIME-Version: 1.0 X-Received: by 10.60.98.41 with SMTP id ef9mr44570993oeb.68.1373925388013; Mon, 15 Jul 2013 14:56:28 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Mon, 15 Jul 2013 14:56:27 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 15 Jul 2013 14:56:27 -0700 Message-ID: From: Vincent Chen To: =?UTF-8?B?7Jyg7ISx7KeE?= Content-Type: multipart/alternative; boundary=089e013a100ab36b2c04e193ee6b X-Gm-Message-State: ALoCoQmURGMUwDiD5Wynvb/Iq7EMF6Hr3iCf/r/2A+yyUvRZEFlvy1CmyKk1+zRzLWyRdbKzUO83J0iG+xSZRj9BK6zusfNnq+Ny/fVLMkJCFilI6t7aKo12j6AFX28Ki3WIzAv0jU0qViWT66yAHl7csrRiHV/cfexSmRpkVh0D9/TV4i6cT5n4d33gbvfWddTMidD+F0vd Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:56:58 -0000 --089e013a100ab36b2c04e193ee6b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sungjin, Sorry for the long delay (vacation). Answers inline. On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 wrote: > Hi All, > > I have found two typos. > > At example "getSpectrum" JSON-RPC in 6.4.1. : > "id": "xxxxxx", --> Comma should be deleted. > At example "getSpectrumBatch" JSON-RPC in 6.5.1. : > "id": "xxxxxx", --> Comma should be deleted. > Thanks! > > > I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 > and 6.5.2. > There are two spectrum information parameters for the same frequency > range. > One is for bandwidth 6e6, and the other is for bandwidth 1e5. > But spectral density of 6e6 is different from that of 1e5 in the same > frequency range. > It will be more nice if the spectral density of the same frequency range > is same. > Or it will be also nice if frequency ranges are modified to be different > from each other. > This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band" operations are permitted. The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power. Does that make sense? -vince > Thank you. > > BR, > Sungjin > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Gabor.Bajko@nokia.com > Sent: Thursday, June 20, 2013 2:18 AM > To: paws@ietf.org > Subject: [paws] WGLC on > http://tools.ietf.org/html/draft-ietf-paws-protocol-06 > > > All, > > The Editor of the document posted a new version and indicated that all > open issues raised on the list were resolved, and that there are no more > open issues he is aware of. > Therefore, I'd like to issue a wg last call on the document. We need > reviews and feedback in order to be able to progress the document. > > Please read through the draft and send any comments you may have to the > list in the next 2-3 weeks. > If you review the draft and have no comments, send a note to the list tha= t > the draft is good as it is, we need these notes as much as we need the > actual comments. > > Thanks, Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --=20 -vince --089e013a100ab36b2c04e193ee6b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sungjin,

Sorry for the long delay (vaca= tion). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7= =84 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC in 6.4.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id": "xxxxxx", =C2=A0 =C2= =A0 --> Comma should be deleted.
At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id": "xxxxxx", =C2=A0 =C2= =A0 --> Comma should be deleted.

Tha= nks!
=C2=A0


I have a comment about example "getSpectrum" JSON-RPC response in= 6.4.2 and 6.5.2.
There are two spectrum information parameters =C2=A0for the same frequency = range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequ= ency range.
It will be more nice if the spectral density of the same frequency range is= same.
Or it will be also nice if frequency ranges are modified to be different fr= om each other.

This is intended to repr= esent the permissible maximum power in which "wide-band" and &quo= t;narrow-band" operations are permitted.
The available frequencies do not change (hence, the same start/stop fr= equencies), just the permissible power.

Does that = make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [m= ailto:paws-bounces@ietf.org] O= n Behalf Of Gabor.Bajko@nokia.com<= /a>
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paw= s-protocol-06


All,

The Editor of the document posted a new version and indicated that all open= issues raised on the list were resolved, and that there are no more open i= ssues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need re= views and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the lis= t in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments.

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



--
= -vince
--089e013a100ab36b2c04e193ee6b-- From sjyou@etri.re.kr Mon Jul 15 18:02:41 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 05BF421F9CE8 for ; Mon, 15 Jul 2013 18:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.972 X-Spam-Level: X-Spam-Status: No, score=-99.972 tagged_above=-999 required=5 tests=[AWL=2.626, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7Zjrb7l206X for ; Mon, 15 Jul 2013 18:02:35 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A811E80F2 for ; Mon, 15 Jul 2013 18:02:35 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 16 Jul 2013 10:02:24 +0900 Received: from [129.254.65.147] (129.254.65.147) by SMTP4.etri.info (129.254.28.74) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 16 Jul 2013 10:02:22 +0900 Message-ID: <51E49B9E.7090900@etri.re.kr> Date: Tue, 16 Jul 2013 10:02:22 +0900 From: Sungjin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Vincent Chen References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090707060301010002070506" X-Originating-IP: [129.254.65.147] Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 01:02:41 -0000 --------------090707060301010002070506 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Vince, I understand "bandwidth" parameter is just for defining permissible power or spectral density and it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description) If I misunderstand, please correct me. And I found another typos. "jsonrpc": "2.0", should be added to all examples. Regards, Sungjin On 07/16/2013 06:56 AM, Vincent Chen wrote: > Sungjin, > > Sorry for the long delay (vacation). Answers inline. > > > On Sun, Jun 30, 2013 at 10:30 PM, 유성진 > wrote: > > Hi All, > > I have found two typos. > > At example "getSpectrum" JSON-RPC in 6.4.1. : > "id": "xxxxxx", --> Comma should be deleted. > At example "getSpectrumBatch" JSON-RPC in 6.5.1. : > "id": "xxxxxx", --> Comma should be deleted. > > > Thanks! > > > > I have a comment about example "getSpectrum" JSON-RPC response in > 6.4.2 and 6.5.2. > There are two spectrum information parameters for the same > frequency range. > One is for bandwidth 6e6, and the other is for bandwidth 1e5. > But spectral density of 6e6 is different from that of 1e5 in the > same frequency range. > It will be more nice if the spectral density of the same frequency > range is same. > Or it will be also nice if frequency ranges are modified to be > different from each other. > > > This is intended to represent the permissible maximum power in which > "wide-band" and "narrow-band" operations are permitted. > The available frequencies do not change (hence, the same start/stop > frequencies), just the permissible power. > > Does that make sense? > > -vince > > > > Thank you. > > BR, > Sungjin > > > -----Original Message----- > From: paws-bounces@ietf.org > [mailto:paws-bounces@ietf.org ] On > Behalf Of Gabor.Bajko@nokia.com > Sent: Thursday, June 20, 2013 2:18 AM > To: paws@ietf.org > Subject: [paws] WGLC on > http://tools.ietf.org/html/draft-ietf-paws-protocol-06 > > > All, > > The Editor of the document posted a new version and indicated that > all open issues raised on the list were resolved, and that there > are no more open issues he is aware of. > Therefore, I'd like to issue a wg last call on the document. We > need reviews and feedback in order to be able to progress the > document. > > Please read through the draft and send any comments you may have > to the list in the next 2-3 weeks. > If you review the draft and have no comments, send a note to the > list that the draft is good as it is, we need these notes as much > as we need the actual comments. > > Thanks, Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > -- > -vince --------------090707060301010002070506 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
Vince,

I understand "bandwidth" parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

And I found another typos.
"jsonrpc": "2.0", should be added to all examples.

Regards,
Sungjin

On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC in 6.4.1. :
        "id": "xxxxxx",     --> Comma should be deleted.
At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
        "id": "xxxxxx",     --> Comma should be deleted.

Thanks!
 


I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters  for the same frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band" operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

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



--
-vince

--------------090707060301010002070506-- From Gabor.Bajko@nokia.com Mon Jul 15 19:30:41 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 E1A3D11E81B5 for ; Mon, 15 Jul 2013 19:30:41 -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 r4AoPCmuEFda for ; Mon, 15 Jul 2013 19:30:36 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA221E80CB for ; Mon, 15 Jul 2013 19:30:34 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6G2UVsr012084 for ; Tue, 16 Jul 2013 05:30:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Jul 2013 05:30:31 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.213]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0328.011; Tue, 16 Jul 2013 02:30:30 +0000 From: To: Thread-Topic: PAWS meeting in Berlin, request for agenda time Thread-Index: Ac6By/UoPBVrBj8PRHOQWQ2sXWfaUA== Date: Tue, 16 Jul 2013 02:32:45 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476022D8302@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.94.180] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476022D8302008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2013 02:30:31.0277 (UTC) FILETIME=[713281D0:01CE81CC] X-Nokia-AV: Clean Subject: [paws] PAWS meeting in Berlin, request for agenda time X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:30:42 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476022D8302008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, PAWS will meet in Berlin on Monday, July 29th, 15:10pm for 2 hours, see htt= ps://datatracker.ietf.org/meeting/87/agenda.html. Remote participation is possible, please send me a note if you plan to atte= nd remotely. If you would like to present, send a timeslot request to the chairs. - gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476022D8302008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

PAWS will meet in Berlin on Monday, July 29th, 15:10pm for 2 hours, see https://dat= atracker.ietf.org/meeting/87/agenda.html.

 

Remote participation is possible, please send me a n= ote if you plan to attend remotely.

 

If you would like to present, send a timeslot reques= t to the chairs.

 

-     &= nbsp;    gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476022D8302008AM1MPN1006mg_-- From vchen@google.com Mon Jul 15 19:34: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 CCE8211E818E for ; Mon, 15 Jul 2013 19:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 f4pgcxOGEKR4 for ; Mon, 15 Jul 2013 19:34:18 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5D76911E817B for ; Mon, 15 Jul 2013 19:34:18 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so170986obc.31 for ; Mon, 15 Jul 2013 19:34:17 -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=UCV3gcfR+UmzkGv0IqL9cgdHVMSJGA/sTw3rnItaXMI=; b=ZkHbUQedDm/GL3yFvo3YGf19ISAVTgHAVbSf9R7fDxxcF0pD0dA4FbH6cbFEmGkTY2 f9WLNmQEqSxbrTER5nMFQS1slhtEnWGWYR8pFAgMn2b0dcRooA2q1b19EES4rm7284w/ R1Lha2fBfwuVn9Js+YoSH9644Ft1gLdnzaCyLyquZzQ75LwvLHqwCjkLCaklurUu8Exr VX7RQ5sY26PI74vr+HHAkDADQnxGNUIs1h792pOwqSHRH9bzad52KLZhdM/4/QQS3EXL LlnBDq4IyD8Y87GgK+x9HfGFYLizdQl2nXFjmr5C2j2r8oXNWGjSaZaVSwQhIZTL5cGq 6GBA== X-Google-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:x-gm-message-state; bh=UCV3gcfR+UmzkGv0IqL9cgdHVMSJGA/sTw3rnItaXMI=; b=SyoY5ebAbVUE8bP0HhCmz3Vk9CUR1m7FiGiw6hNFt/lYkx3G6Jhk335axMWOfCSt7/ RCpOjrTXvEIxsLNLkb9sf/mKHFg42UHZLN+ezxEzdzQm8ifIV95gK2CSFqG7aS80jdZN Xjm7Fx8hQOhECV8olv4T3+XXWISlh/CckGAmAM7ps531fAsJmxA1txgA16ONHzz1ANtW RjLK71k5HDkraRFScE7Z6aANVWYHq46M8ONIvxs+GArgcCIPJfW7QRmJEpg77QgKkpga yF0ABJwxX1kbscE4n87j/zj/feFbqOmjr9CP4X5KWZxKOBuRo6icEJCPx0Jxs+XHXXNs wxsg== MIME-Version: 1.0 X-Received: by 10.182.79.106 with SMTP id i10mr44805177obx.59.1373942057700; Mon, 15 Jul 2013 19:34:17 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Mon, 15 Jul 2013 19:34:17 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476022D8302@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022D8302@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 15 Jul 2013 19:34:17 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=047d7b2e3e104aacb604e197d0f9 X-Gm-Message-State: ALoCoQnjA0cidUectaZjuOFm/RZDHPi717wU18XNU/GjUgvruc8Zt9afW8N0GVySZntAz8EqBey1Bde8tP3cCEJsE5GApj5MSUZPHavENYyp8GABBeo/+TFzMvJTso8GysGGv8iAYSrBBFRE1b5qRWaJmDjxa7EtkgloOe1hEdnggMeQIFsLzRYNMPobBO/2UfCyr+KYOjge Cc: "paws@ietf.org" Subject: Re: [paws] PAWS meeting in Berlin, request for agenda time X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 02:34:18 -0000 --047d7b2e3e104aacb604e197d0f9 Content-Type: text/plain; charset=ISO-8859-1 Gabor, I currently plan on attending remotely. -vince On Mon, Jul 15, 2013 at 7:32 PM, wrote: > Hi all,**** > > ** ** > > PAWS will meet in Berlin on Monday, July 29th, 15:10pm for 2 hours, see > https://datatracker.ietf.org/meeting/87/agenda.html.**** > > ** ** > > Remote participation is possible, please send me a note if you plan to > attend remotely.**** > > ** ** > > If you would like to present, send a timeslot request to the chairs.**** > > ** ** > > **- **gabor**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --047d7b2e3e104aacb604e197d0f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gabor,

I currently plan on attending re= motely.

-vince


On Mon, Jul 15, 2013 at 7:32 PM= , <Gabor.Bajko@nokia.com> wrote:

Hi all,

=A0

PAWS will meet in Berlin on Monday, July 29th, 15:10pm for 2 hours, see https://datatracker.ietf.org/meeting/87/agenda.html.

=A0

Remote participation is possible, please send me a n= ote if you plan to attend remotely.

=A0

If you would like to present, send a timeslot reques= t to the chairs.

=A0

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 gabor


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




--
-vince
--047d7b2e3e104aacb604e197d0f9-- From amancuso@google.com Mon Jul 15 21:39:59 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 DD08221E8186 for ; Mon, 15 Jul 2013 21:39: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 TJT+-7u0eJHN for ; Mon, 15 Jul 2013 21:39:58 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 91ADD21E819D for ; Mon, 15 Jul 2013 21:39:48 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so598165ief.40 for ; Mon, 15 Jul 2013 21:39:48 -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=OA8yJLHRb/tyT9XFgt6yP/B9uhIXhohJSdfG8KiAawU=; b=OWITr4lsnM7jNhfqVI8PFVwIutE9UrBS+BcfjtrRMyJJzSt28JIs3HGPqwjL6+rG75 8qnqxPYCndgTKeh6Gi1Vlsg2pSEAHTVLjPt+AeXbUZJb+tqnSHdQ5Uw1NNYOLwezhjv/ teKy0MuKQOA3rQtcRy7vW5pgphsFIhsI9NY6dnL/f1vHtr2dOa3skv3fGkk2Nv02iNId 6Z5ZUVdFyrsOIyBTwmZ2VNWQyHmWYXb2IOfVShaXQCTG79AzJBueMtDpkZ4/4QwqOGun GYgB7RpYG6pSokuJkO10P3eRfZAGXJgJNatm0AiHfTcnKjtNOkFY4BaqJgdWDFJaRDcK 8RUg== X-Google-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:x-gm-message-state; bh=OA8yJLHRb/tyT9XFgt6yP/B9uhIXhohJSdfG8KiAawU=; b=S7nkDOCW9KJPsy8J5Kq0IPHuDgFbkuICdqMaPUicmDLu+nxm0qsh+3I97FZT5egDPT 8YOSU+dWD2NVzbwKYAOV7eqavwWFamZ1ROgmbXu1N7oBh/g+Fr0AkGvD7q+D8hzfgiqQ gahky8+IeZkCyBjl0qII74kCXjdqU9y8ij+AuiEZKAiSiG2qqrr1eJ7GFGrlVv252KXW UZc056UqNvkMK2/aIwYXk08IAuAPPKOKa2jPfBdfd7yi8oIfsgR2nDPXTmH0IwWK3Vay vleH/P0tNMN99oYdDjK2f7G5BaB2g3E3pYnYGpQnaAe5N2cqIDT/wZm9YYEiE5M1MCnI mG8w== MIME-Version: 1.0 X-Received: by 10.43.0.67 with SMTP id nl3mr1249526icb.2.1373949587995; Mon, 15 Jul 2013 21:39:47 -0700 (PDT) Received: by 10.64.62.67 with HTTP; Mon, 15 Jul 2013 21:39:47 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022D8302@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 15 Jul 2013 21:39:47 -0700 Message-ID: From: Anthony Mancuso To: Vincent Chen Content-Type: multipart/alternative; boundary=bcaec511e1b621dbd004e1999118 X-Gm-Message-State: ALoCoQnbyx+dDW5iqDNLEyx/wKNE6RIvF0oUKedr+tY3HEwJwhJsLpTrrtreYJjIIf7m0qx8HVdz/96gJAjzm1P35cOUJsrPAGfa+85UDNuA6u2jaAlxcS7Osh7mrpV06fd7x+XPW8VgCTluxHRHVxbxxbMcu2BfdJxA4fNwzxfnSIRMU9MSWxALsT7iVQfkbtSWn1mI+8og Cc: "paws@ietf.org" Subject: Re: [paws] PAWS meeting in Berlin, request for agenda time X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 04:39:59 -0000 --bcaec511e1b621dbd004e1999118 Content-Type: text/plain; charset=ISO-8859-1 I plan on attending in person. On Mon, Jul 15, 2013 at 7:34 PM, Vincent Chen wrote: > Gabor, > > I currently plan on attending remotely. > > -vince > > > On Mon, Jul 15, 2013 at 7:32 PM, wrote: > >> Hi all,**** >> >> ** ** >> >> PAWS will meet in Berlin on Monday, July 29th, 15:10pm for 2 hours, see >> https://datatracker.ietf.org/meeting/87/agenda.html.**** >> >> ** ** >> >> Remote participation is possible, please send me a note if you plan to >> attend remotely.**** >> >> ** ** >> >> If you would like to present, send a timeslot request to the chairs.**** >> >> ** ** >> >> **- **gabor**** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --bcaec511e1b621dbd004e1999118 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I plan on attending in person.


On Mon, Jul 15, 2013 at 7:34 PM= , Vincent Chen <vchen@google.com> wrote:
Gabor,

I= currently plan on attending remotely.

-vince


On Mon, Jul 15, 2013 at 7:32 PM, <Gabor.Bajko@nokia.com> wrote:

Hi all,

=A0

PAWS will meet in Berlin on Monday, July 29th, 15:10pm for 2 hours, see https://datatracker.ietf.org/meeting/87/agenda.html.

=A0

Remote participation is possible, please send me a n= ote if you plan to attend remotely.

=A0

If you would like to present, send a timeslot reques= t to the chairs.<= /p>

=A0

-=A0= =A0=A0=A0=A0=A0=A0=A0=A0 gabor


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


<= br clear=3D"all">

--
-vince

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


--bcaec511e1b621dbd004e1999118-- From Gabor.Bajko@nokia.com Thu Jul 18 15:38:12 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 0E91821F8F4F for ; Thu, 18 Jul 2013 15:38:12 -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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vjIM-YokxQ2 for ; Thu, 18 Jul 2013 15:38:06 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8158621F8DE3 for ; Thu, 18 Jul 2013 15:38:06 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6IMc1Td001250 for ; Fri, 19 Jul 2013 01:38:02 +0300 Received: from vaebh106.NOE.Nokia.com ([10.160.244.32]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 01:38:01 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jul 2013 01:38:01 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.208]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0328.011; Thu, 18 Jul 2013 22:37:48 +0000 From: To: Thread-Topic: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Thread-Index: Ac5tED3uJb/xv+13Q/isaSe3CRkDqgW8sfsQ Date: Thu, 18 Jul 2013 22:37:47 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476022E9E93@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.94.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2013 22:38:01.0492 (UTC) FILETIME=[75B77D40:01CE8407] X-Nokia-AV: Clean Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 18 Jul 2013 22:38:12 -0000 Here are some comments to the draft: You may want to define the ruleset, listing service, listing server in the = terminology section. Section 3.1, bullet 2 says that "The Database may use the rule-set list to = determine its response", which I think is not right. The Database uses the = location of the master device to determine its response, and the required p= arameters and ruleset to be supported are sent back to the master device ba= sed on the device's location. Section 4 starts with listing the components of paws. Spectrum use notify i= s missing from that list. Section 4.1 has this sentence: " A Device SHOULD support operation in any r= egulatory environment." It must be some leftover which I think should be de= leted. Section 4.1, configuration update: s/SHOULD be able to update/SHOULD update, 2 instances when the URI changes, the inclusion of the DbUpdateSpec should be a MUST in= stead of SHOULD. Same comment for the next sentence (s/SHOULD/MUST) Section 5.1 Both point and region are listed as optional for the Geolocation element. B= ut one of them has to be present. The Note below the figure says " Note: point and polygon are mutually exclu= sive", while it should say " Note: point and region are mutually exclusive" In several places you have 'depends'; expand what does it depend on. " If present, it indicates that the GeoLocation represents a region. Database support for regions is OPTIONAL." I would delete the second sentence, and instead state in 4.4.3 that the sup= port for this request is optional. " center: The center refers to the location of a GeoLocation point and is represented as the center of an ellipse. REQUIRED." What does the REQUIRED word mean here? That the parameter center must alway= s be present? That doesn't seem to be right as the ellipse shape may not be= present (instead the polygon may be present). Throughout section 6, where you define the schemas, the description field i= s broken up into multiple lines and you have quotation marks and + signs in= all lines. It would improve the readability of the document if you removed= those quotation marks and + signs.=20 - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Wednesday, June 19, 2013 10:18 AM To: paws@ietf.org Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol= -06 All, The Editor of the document posted a new version and indicated that all open= issues raised on the list were resolved, and that there are no more open i= ssues he is aware of. Therefore, I'd like to issue a wg last call on the document. We need review= s and feedback in order to be able to progress the document. Please read through the draft and send any comments you may have to the lis= t in the next 2-3 weeks. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Jul 18 15:42: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 EFD9D11E8204 for ; Thu, 18 Jul 2013 15:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWpIMAphby+9 for ; Thu, 18 Jul 2013 15:42:38 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id CD77911E81E3 for ; Thu, 18 Jul 2013 15:42:38 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6IMgbTV005000 for ; Fri, 19 Jul 2013 01:42:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 01:42:36 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.208]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.02.0328.011; Thu, 18 Jul 2013 22:42:36 +0000 From: To: Thread-Topic: Reviews requested for http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Thread-Index: Ac6ECAMrY2kuYF/5TTCJfFOcaTjfbQ== Date: Thu, 18 Jul 2013 22:42:35 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.94.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2013 22:42:36.0970 (UTC) FILETIME=[19EA18A0:01CE8408] X-Nokia-AV: Clean Subject: [paws] Reviews requested for http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 18 Jul 2013 22:42:44 -0000 Folks, I issued a WGLC on this document 4 weeks ago, and there was no feedback rec= eived at all. If you care about this document, you should review it and send your comment= s to the list. If you review it and you have no comments, then please send = a mail to the list stating that you have reviewed the document and have no = comments. Without reviews, we cannot make progress with the document. I cannot send i= t to the IESG requesting publication. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Wednesday, June 19, 2013 10:18 AM To: paws@ietf.org Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol= -06 All, The Editor of the document posted a new version and indicated that all open= issues raised on the list were resolved, and that there are no more open i= ssues he is aware of. Therefore, I'd like to issue a wg last call on the document. We need review= s and feedback in order to be able to progress the document. Please read through the draft and send any comments you may have to the lis= t in the next 2-3 weeks. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From vchen@google.com Thu Jul 18 18:13:22 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 72D1821F99F8 for ; Thu, 18 Jul 2013 18:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.075, 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 ltDSNspaQP0C for ; Thu, 18 Jul 2013 18:13:21 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B8D9221F9943 for ; Thu, 18 Jul 2013 18:13:19 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so5183020oag.29 for ; Thu, 18 Jul 2013 18:13: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=V9KDCEcYe7nCUcPbSu7o3Kk9214zXEoeqGPXvVKPWTk=; b=dQ2baczcptvKqq0zh0dOjPpAvsDuuONxzpxzWWPn136s6yobVCBXnDqQQ0hg59+O87 ZOZI0kg5bCoySSNyF1i6pL4hmbWlYLKtCdCvaHGSBcqwKTw2GqnxWtkxvWuLv/iwusjy 2Uh9LR5nN4ir/AZxE5enfiRDfB6W07oaZx4dDi34655zg2Q8FlnwJ3UOKFohKTmTxxiQ MkONQhy9D6J+8xaHQ+WvlKUKjw7F5SemNod4mcmfRqrQeVuSWucs7u5AiS+1IeWl7Tkj hskWQs+TXX2VS8kuxcNUekGcK1JaerJyeXecSSm14m2SGi0lHSB82okRw64u73wNVNhk l2yw== X-Google-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:x-gm-message-state; bh=V9KDCEcYe7nCUcPbSu7o3Kk9214zXEoeqGPXvVKPWTk=; b=E9Ke/gdB/ianI40M5Q2olqDr1LI42XCKO7WS5OpMTF/tMi1TKFGu22YE4YXyLNYyPG 75es0K9epPYpbtsqodxZQ0QBXJtW24fB23uYZEdmA3+cj5pksnFCjlWrnwUPg6B9gSfE XfKo3qIO6neq/+FejBcpf8Y3zNKG33oSyX8aweF/qqOzDUTL6K1n2WLmcKEdNrMmLAXl Rmv7IbK3xcDru06uVxnvqeRRV3IxXlH2dNkPf1Kjz7LRg8nMPjdNOKXau+DYDI0FcuCQ oDhEaZiNKBdTDxSInPT+Je4rH7WwZ9rP0iZNyZHm+CwtXKIOWk9pOL5UwS0NLIhD86Dc VCdA== MIME-Version: 1.0 X-Received: by 10.60.45.138 with SMTP id n10mr15801050oem.101.1374196398855; Thu, 18 Jul 2013 18:13:18 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 18 Jul 2013 18:13:18 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476022E9E93@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476022E9E93@008-AM1MPN1-006.mgdnok.nokia.com> Date: Thu, 18 Jul 2013 18:13:18 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=001a11c245e434b1e504e1d30813 X-Gm-Message-State: ALoCoQmKziAcgxxnhLHyDnMgYtjr6LoiQH77PMd815QSncZtS5drg8nnCZEzQeIyEQlqQ/7671tUe7hxstgbKGtbugRuJumxa4H5FDhhAbtiKShu8nOn80CEoUQp2OwEzhYgg2NiM0eKzW7fnC9vp19uadoOpkgbS+S/eWcopY1l8F/RvXDXHWJUCdg5MMa3GSf2CM3C00Tf Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 19 Jul 2013 01:13:22 -0000 --001a11c245e434b1e504e1d30813 Content-Type: text/plain; charset=ISO-8859-1 Gabor, Thanks for the suggestions. I'll incorporate them into a new draft. -vince On Thu, Jul 18, 2013 at 3:37 PM, wrote: > Here are some comments to the draft: > > You may want to define the ruleset, listing service, listing server in the > terminology section. > > Section 3.1, bullet 2 says that "The Database may use the rule-set list to > determine its response", which I think is not right. The Database uses the > location of the master device to determine its response, and the required > parameters and ruleset to be supported are sent back to the master device > based on the device's location. > > Section 4 starts with listing the components of paws. Spectrum use notify > is missing from that list. > > Section 4.1 has this sentence: " A Device SHOULD support operation in any > regulatory environment." It must be some leftover which I think should be > deleted. > > Section 4.1, configuration update: > s/SHOULD be able to update/SHOULD update, 2 instances > when the URI changes, the inclusion of the DbUpdateSpec should be a MUST > instead of SHOULD. Same comment for the next sentence (s/SHOULD/MUST) > > Section 5.1 > Both point and region are listed as optional for the Geolocation element. > But one of them has to be present. > The Note below the figure says " Note: point and polygon are mutually > exclusive", while it should say " Note: point and region are mutually > exclusive" > In several places you have 'depends'; expand what does it depend on. > > " If present, it indicates that the GeoLocation represents a > region. Database support for regions is OPTIONAL." > I would delete the second sentence, and instead state in 4.4.3 that the > support for this request is optional. > > " center: The center refers to the location of a GeoLocation point and > is represented as the center of an ellipse. REQUIRED." > What does the REQUIRED word mean here? That the parameter center must > always be present? That doesn't seem to be right as the ellipse shape may > not be present (instead the polygon may be present). > > Throughout section 6, where you define the schemas, the description field > is broken up into multiple lines and you have quotation marks and + signs > in all lines. It would improve the readability of the document if you > removed those quotation marks and + signs. > > - Gabor > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: Wednesday, June 19, 2013 10:18 AM > To: paws@ietf.org > Subject: [paws] WGLC on > http://tools.ietf.org/html/draft-ietf-paws-protocol-06 > > All, > > The Editor of the document posted a new version and indicated that all > open issues raised on the list were resolved, and that there are no more > open issues he is aware of. > Therefore, I'd like to issue a wg last call on the document. We need > reviews and feedback in order to be able to progress the document. > > Please read through the draft and send any comments you may have to the > list in the next 2-3 weeks. > If you review the draft and have no comments, send a note to the list that > the draft is good as it is, we need these notes as much as we need the > actual comments. > > Thanks, Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --001a11c245e434b1e504e1d30813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gabor,

Thanks for the suggestions. I= 9;ll incorporate them into a new draft.

-vince


On Th= u, Jul 18, 2013 at 3:37 PM, <Gabor.Bajko@nokia.com> wro= te:
Here are some comments to the draft:

You may want to define the ruleset, listing service, listing server in the = terminology section.

Section 3.1, bullet 2 says that "The Database may use the rule-set lis= t to determine its response", which I think is not right. The Database= uses the location of the master device to determine its response, and the = required parameters and ruleset to be supported are sent back to the master= device based on the device's location.

Section 4 starts with listing the components of paws. Spectrum use notify i= s missing from that list.

Section 4.1 has this sentence: " A Device SHOULD support operation in = any regulatory environment." It must be some leftover which I think sh= ould be deleted.

Section 4.1, configuration update:
s/SHOULD be able to update/SHOULD update, 2 instances
when the URI changes, the inclusion of the DbUpdateSpec should be a MUST in= stead of SHOULD. Same comment for the next sentence (s/SHOULD/MUST)

Section 5.1
Both point and region are listed as optional for the Geolocation element. B= ut one of them has to be present.
The Note below the figure says " Note: point and polygon are mutually = exclusive", while it should say " Note: point and region are mutu= ally exclusive"
In several places you have 'depends'; expand what does it depend on= .

" If present, it indicates that the GeoLocation represents a
=A0 =A0 =A0 region. =A0Database support for regions is OPTIONAL."
I would delete the second sentence, and instead state in 4.4.3 that the sup= port for this request is optional.

" =A0 center: =A0The center refers to the location of a GeoLocation po= int and
=A0 =A0 =A0 is represented as the center of an ellipse. =A0REQUIRED."<= br> What does the REQUIRED word mean here? That the parameter center must alway= s be present? That doesn't seem to be right as the ellipse shape may no= t be present (instead the polygon may be present).

Throughout section 6, where you define the schemas, the description field i= s broken up into multiple lines and you have quotation marks and + signs in= all lines. It would improve the readability of the document if you removed= those quotation marks and + signs.

- Gabor


-----Original Message-----
From: paws-bounces@ietf.org [m= ailto:paws-bounces@ietf.org] O= n Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, June 19, 2013 10:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paw= s-protocol-06

All,

The Editor of the document posted a new version and indicated that all open= issues raised on the list were resolved, and that there are no more open i= ssues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need re= views and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the lis= t in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments.

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



--
= -vince
--001a11c245e434b1e504e1d30813-- From vchen@google.com Thu Jul 18 18:16:46 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 0AB7521E80E8 for ; Thu, 18 Jul 2013 18:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 hT7m8FlJgy2m for ; Thu, 18 Jul 2013 18:16:45 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D6BB221E80FB for ; Thu, 18 Jul 2013 18:16:39 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id k7so5172592oag.9 for ; Thu, 18 Jul 2013 18:16:38 -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=+sEx7glB1Ogv+UOEK2FMgHfE89nKeCmDnuZFfH6Jy6Y=; b=cE6FZrVQ+r3Kvfdc25f74yAHsnrZMatCU8MHijkJOhJcZTp/xh7jjutHwLae1gA1fX NE7bwPQXaXiW+q/J7QnG16WYyZs5baSbQw/5KhpwFOSfvobTS8UfWZv3+htF09f/GNyW IuWBmo4GHhGm9fsOYvOrmc+zbrDsZhSpGGFIOcGaDSyhNQsJpzQiJX8YKv9zjELzb6cX KjlNeSY1dxqa+U4iiZtDNLX2Kvu2Rn4DbkvyNCn95hgdFU5S9qWXaTAOxgLTJWzNWbLF JspDqe8mqyIVDIFiQJIU8pQcUa/zs8hYamqJMn/ZdRo0FvKsCTajZEf5EMlyNvPLGFwa 5Z6Q== X-Google-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:x-gm-message-state; bh=+sEx7glB1Ogv+UOEK2FMgHfE89nKeCmDnuZFfH6Jy6Y=; b=aC8GaDDdU3zIVGwYgPvU5+rCfdrK3tDfIC0uKn0X1/Hnc26O7c5RiCyS4nBwBT/+gG 9VKeSoM5THDC0o2kbgu0CCn+u/d5gnyfOMy1mWBpEd/t63PNXbTEAzkQE+sYbAmsYEnT Ng+jYFRLQD5PXoKeO/NRW8lqloTHKmpo6ecxlVI76PIZG7snuxfA/5KM3/S4ji+z+psG v7PA76Z3lnDg07xR901vfBS04cz7Xyed3anrEx9WFfv4IcDRN7vRK1ciZXsu5CmKRtMo frzHLX7VJ2KOwwQ3VQwGWxi/fa7suNSExsLwFUPo64h10CLNSHBBwJeW311PIw9RdRop auxg== MIME-Version: 1.0 X-Received: by 10.60.52.16 with SMTP id p16mr16164700oeo.29.1374196598019; Thu, 18 Jul 2013 18:16:38 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 18 Jul 2013 18:16:37 -0700 (PDT) In-Reply-To: <51E49B9E.7090900@etri.re.kr> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> Date: Thu, 18 Jul 2013 18:16:37 -0700 Message-ID: From: Vincent Chen To: Sungjin Content-Type: multipart/alternative; boundary=001a11330b2213bb7f04e1d314a1 X-Gm-Message-State: ALoCoQmfEcZZ+DXOyCXBdZZigRbFoT5gFZW34m4BBOBxZjRzBhjX00quTSUc1gP1x9ahY5wKNrDacdBYgS7m6yjVQOC8zK89MGPME/Pn5MtKMH+ERNZxxCzvpSc/++N3L3tTChy+BVhUjXpfssRSFEn0RCrHSQDFR2NDzc3s4jaq0iHv5LWUvHq7q8YQ+2JFgJRPhC5uE0nT Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 19 Jul 2013 01:16:46 -0000 --001a11330b2213bb7f04e1d314a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sungjin, On Mon, Jul 15, 2013 at 6:02 PM, Sungjin wrote: > Vince, > > I understand "bandwidth" parameter is just for defining permissible power > or spectral density and > it dose not represent the operation bandwidth. (see 4.4.5. > SPECTRUC_USE_NOTIFY, 'spectra' parameter description) > If I misunderstand, please correct me. > Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent. I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always guaranteed to be the same. > > And I found another typos. > "jsonrpc": "2.0", should be added to all examples. > Thanks. I will incorporate this. > > Regards, > Sungjin > > > On 07/16/2013 06:56 AM, Vincent Chen wrote: > > Sungjin, > > Sorry for the long delay (vacation). Answers inline. > > > On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 wrote: > >> Hi All, >> >> I have found two typos. >> >> At example "getSpectrum" JSON-RPC in 6.4.1. : >> "id": "xxxxxx", --> Comma should be deleted. >> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >> "id": "xxxxxx", --> Comma should be deleted. >> > > Thanks! > > >> >> >> I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 >> and 6.5.2. >> There are two spectrum information parameters for the same frequency >> range. >> One is for bandwidth 6e6, and the other is for bandwidth 1e5. >> But spectral density of 6e6 is different from that of 1e5 in the same >> frequency range. >> It will be more nice if the spectral density of the same frequency range >> is same. >> Or it will be also nice if frequency ranges are modified to be different >> from each other. >> > > This is intended to represent the permissible maximum power in which > "wide-band" and "narrow-band" operations are permitted. > The available frequencies do not change (hence, the same start/stop > frequencies), just the permissible power. > > > Does that make sense? > > -vince > > > >> Thank you. >> >> BR, >> Sungjin >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Gabor.Bajko@nokia.com >> Sent: Thursday, June 20, 2013 2:18 AM >> To: paws@ietf.org >> Subject: [paws] WGLC on >> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >> >> >> All, >> >> The Editor of the document posted a new version and indicated that all >> open issues raised on the list were resolved, and that there are no more >> open issues he is aware of. >> Therefore, I'd like to issue a wg last call on the document. We need >> reviews and feedback in order to be able to progress the document. >> >> Please read through the draft and send any comments you may have to the >> list in the next 2-3 weeks. >> If you review the draft and have no comments, send a note to the list >> that the draft is good as it is, we need these notes as much as we need = the >> actual comments. >> >> Thanks, Gabor >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> > > > > -- > -vince > > > --=20 -vince --001a11330b2213bb7f04e1d314a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin = <sjyou@etri.re.kr> wrote:
=20 =20 =20
Vince,

I understand "bandwidth" parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does= not make sure the math works out to be equivalent.
I thought, th= ough, some regulators actually wants different power spectral density for n= arrow band, so it's not always
guaranteed to be the same.=C2=A0
=C2=A0

And I found another typos.
"jsonrpc": "2.0", should be added to all examples= .

Thanks. I will incorporat= e this.
=C2=A0

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
=20
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, =EC= =9C=A0=EC=84=B1=EC=A7=84 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC in 6.4.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id": "xxxxxx"= ;, =C2=A0 =C2=A0 --> Comma should be deleted.
At example "getSpectrumBatch" JSON-RPC in 6.5.1. :<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "id": "xxxxxx"= ;, =C2=A0 =C2=A0 --> Comma should be deleted.

Thanks!
=C2=A0


I have a comment about example "getSpectrum" JSON-R= PC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters =C2=A0for the same frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band&qu= ot; operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: pa= ws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/h= tml/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

Thanks, Gabor
_______________________________________________
paws mailing list
paws@i= etf.org
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
paws@i= etf.org
https://www.ietf.org/mailman/listinfo/paws



--
-vince




--
-vince
--001a11330b2213bb7f04e1d314a1-- From sjyou@etri.re.kr Thu Jul 18 21:49:34 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 B8FAD21E81AC for ; Thu, 18 Jul 2013 21:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.985 X-Spam-Level: X-Spam-Status: No, score=-100.985 tagged_above=-999 required=5 tests=[AWL=1.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyKdHep-ZN0U for ; Thu, 18 Jul 2013 21:49:29 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id EFCD021E819E for ; Thu, 18 Jul 2013 21:49:27 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Jul 2013 13:49:24 +0900 Received: from [129.254.65.147] (129.254.65.147) by SMTP4.etri.info (129.254.28.74) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Jul 2013 13:49:22 +0900 Message-ID: <51E8C552.4060100@etri.re.kr> Date: Fri, 19 Jul 2013 13:49:22 +0900 From: Sungjin Yoo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Vincent Chen References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040407010703030001000404" X-Originating-IP: [129.254.65.147] Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 19 Jul 2013 04:49:34 -0000 --------------040407010703030001000404 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Vince, Comment is in line. On 07/19/2013 10:16 AM, Vincent Chen wrote: > Sungjin, > > > On Mon, Jul 15, 2013 at 6:02 PM, Sungjin > wrote: > > Vince, > > I understand "bandwidth" parameter is just for defining > permissible power or spectral density and > it dose not represent the operation bandwidth. (see 4.4.5. > SPECTRUC_USE_NOTIFY, 'spectra' parameter description) > If I misunderstand, please correct me. > > > Oh, I understand what you're saying. The example does not make sure > the math works out to be equivalent. > I thought, though, some regulators actually wants different power > spectral density for narrow band, so it's not always > guaranteed to be the same. If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=27dBm + 17.78dB). The master device don't know which one is correct. So I think it will be clear if "frequencyRanges" in the second one(for "bandwidth" : 1e5) is modified to different frequency from first one(for "bandwidth" : 1e5) > And I found another typos. > "jsonrpc": "2.0", should be added to all examples. > > > Thanks. I will incorporate this. > > > Regards, > Sungjin > > > On 07/16/2013 06:56 AM, Vincent Chen wrote: >> Sungjin, >> >> Sorry for the long delay (vacation). Answers inline. >> >> >> On Sun, Jun 30, 2013 at 10:30 PM, 유성진 > > wrote: >> >> Hi All, >> >> I have found two typos. >> >> At example "getSpectrum" JSON-RPC in 6.4.1. : >> "id": "xxxxxx", --> Comma should be deleted. >> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >> "id": "xxxxxx", --> Comma should be deleted. >> >> >> Thanks! >> >> >> >> I have a comment about example "getSpectrum" JSON-RPC >> response in 6.4.2 and 6.5.2. >> There are two spectrum information parameters for the same >> frequency range. >> One is for bandwidth 6e6, and the other is for bandwidth 1e5. >> But spectral density of 6e6 is different from that of 1e5 in >> the same frequency range. >> It will be more nice if the spectral density of the same >> frequency range is same. >> Or it will be also nice if frequency ranges are modified to >> be different from each other. >> >> >> This is intended to represent the permissible maximum power in >> which "wide-band" and "narrow-band" operations are permitted. >> The available frequencies do not change (hence, the same >> start/stop frequencies), just the permissible power. >> >> Does that make sense? >> >> -vince >> >> >> >> Thank you. >> >> BR, >> Sungjin >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org >> [mailto:paws-bounces@ietf.org ] >> On Behalf Of Gabor.Bajko@nokia.com >> Sent: Thursday, June 20, 2013 2:18 AM >> To: paws@ietf.org >> Subject: [paws] WGLC on >> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >> >> >> All, >> >> The Editor of the document posted a new version and indicated >> that all open issues raised on the list were resolved, and >> that there are no more open issues he is aware of. >> Therefore, I'd like to issue a wg last call on the document. >> We need reviews and feedback in order to be able to progress >> the document. >> >> Please read through the draft and send any comments you may >> have to the list in the next 2-3 weeks. >> If you review the draft and have no comments, send a note to >> the list that the draft is good as it is, we need these notes >> as much as we need the actual comments. >> >> Thanks, Gabor >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> >> >> >> -- >> -vince > > > > > -- > -vince Regards, Sungjin --------------040407010703030001000404 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
Vince,

Comment is in line.

On 07/19/2013 10:16 AM, Vincent Chen wrote:
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <sjyou@etri.re.kr> wrote:
Vince,

I understand "bandwidth" parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always
guaranteed to be the same.

If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=27dBm + 17.78dB). The master device don't know which one is correct.
So I think it will be clear if "frequencyRanges" in the second one(for "bandwidth" : 1e5) is modified to different frequency from first one(for "bandwidth" : 1e5)

And I found another typos.
"jsonrpc": "2.0", should be added to all examples.

Thanks. I will incorporate this.
 

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC in 6.4.1. :
        "id": "xxxxxx",     --> Comma should be deleted.
At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
        "id": "xxxxxx",     --> Comma should be deleted.

Thanks!
 


I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters  for the same frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band" operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

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



--
-vince




--
-vince

Regards,
Sungjin

--------------040407010703030001000404-- From vchen@google.com Thu Jul 18 22:17:07 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 D15BF21E81C1 for ; Thu, 18 Jul 2013 22:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 eSmnRbOW7-Dl for ; Thu, 18 Jul 2013 22:17:06 -0700 (PDT) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 986AF21E81BF for ; Thu, 18 Jul 2013 22:17:06 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id f4so5410967oah.35 for ; Thu, 18 Jul 2013 22:17:06 -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=/SB9K1sBRrI+/G50fvN8rZUqW3gTwKvhxfiohGJCdwI=; b=ORSEnyNLx8gtNiRaatVS+FSqTAHVcA2yhb0JMHmLkFGrjop26ah5MnJWe7y+Wxp7TQ jDU2SxWMpHFZA+bAY8I3VQkG98rQAAqoeIXQxHtobhNgxkw1LbDvwUL2D13IrQ762LKA toSQTumzIfnlaXacmTyJLOr6WaF+LWabaiGZtEdapWPs9zO0yk2AIrOrQT9qXdJcfXGS yHomu0ZBur5Ejc8KNF2PKk2PGgNrVu9IKgrWC1jfUgMfi2IecRkM6wXABNno66bH/Xvi 5fZ7IWYwFtVZs/d5ML9XYZ4F3+LqWTwhPjiB6EKq/AtYTEy040nYyV7j3F58xn9JHzbG CegQ== X-Google-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:x-gm-message-state; bh=/SB9K1sBRrI+/G50fvN8rZUqW3gTwKvhxfiohGJCdwI=; b=OiDO0ic5/C/lZpljXCCpxfuw9oiuVQsIi7enqhUdYKTfdhqKOlhvmoIyij4px65qMo p/gtk2YPKe4s+nc4WpACWf0Zx4M/M85IHpOsjVQMV6n/LF+kgunxfZvhJi8I0iHXe6xK MBwevMcAlnFaLrrCpz9vmn668u6Xl3oGQhqRTBCuxwq7EF1epQ016+zwegu7HDUBtaUW OTe8NcHpjhWa108UEjuA4rLqUwRb7XEQzj754FmKP5LZ85atjfa6Up+Cw3q1UywR9nNa 23POWRLxLLr8TQ1zbfBSt1J9JpXzid3nbgTK+47Pp3iCcIGS/+2tblBVxBz9ImaiFA9r asYA== MIME-Version: 1.0 X-Received: by 10.182.128.42 with SMTP id nl10mr10667192obb.41.1374211025931; Thu, 18 Jul 2013 22:17:05 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 18 Jul 2013 22:17:05 -0700 (PDT) In-Reply-To: <51E8C552.4060100@etri.re.kr> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> Date: Thu, 18 Jul 2013 22:17:05 -0700 Message-ID: From: Vincent Chen To: Sungjin Yoo Content-Type: multipart/alternative; boundary=e89a8ff1cc9e0c25eb04e1d67098 X-Gm-Message-State: ALoCoQm1vNu7EtzIg7NE1+56NM/4d8Iqm6ZgN7I3fPO2B0VX9syBrG+5KBM22CiXfKHlqQBasDODBfG9L4satGO2ej/yvBux1Hd7YECNSZma4qEF7vytLGqqjGgH7HEaans4h83i2cZHKfTaTiyuQ+JJctlNOp1goBWNEZ9jE05JDWJfHHruFxalLo3GxZe+niSwgq34gv82 Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 19 Jul 2013 05:17:08 -0000 --e89a8ff1cc9e0c25eb04e1d67098 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sunglin, Some clarification: The maxPowerDbm is total power. It is not a spectral density. Thus, if a 6MHz channel is available, the Device may choose to put, say, ten 100kHz sub-channels within that channel. The total power summed over those 10 sub-channels cannot exceed 27dBm. So here is one way the Device may use the response. - The Device determines first if it wants to be a narrow band (1e5) or wideband (6e6) device - It selects the Spectrum specification, based on its mode -vince On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo wrote: > Vince, > > Comment is in line. > > > On 07/19/2013 10:16 AM, Vincent Chen wrote: > > Sungjin, > > > On Mon, Jul 15, 2013 at 6:02 PM, Sungjin wrote: > >> Vince, >> >> I understand "bandwidth" parameter is just for defining permissible powe= r >> or spectral density and >> it dose not represent the operation bandwidth. (see 4.4.5. >> SPECTRUC_USE_NOTIFY, 'spectra' parameter description) >> If I misunderstand, please correct me. >> > > Oh, I understand what you're saying. The example does not make sure the > math works out to be equivalent. > I thought, though, some regulators actually wants different power spectra= l > density for narrow band, so it's not always > guaranteed to be the same. > > > If master device receive the message in the example, it will be confused. > Assume the master device decides to use the spectrum from 5.18e8 Hz to > 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master > device may be confused to interpret permissible maximum power. First one = in > the example represents 30.0 dBm, but second one represents about 44.78 > dBm(=3D27dBm + 17.78dB). The master device don't know which one is correc= t. > So I think it will be clear if "frequencyRanges" in the second one(for > "bandwidth" : 1e5) is modified to different frequency from first one(for > "bandwidth" : 1e5) > > > And I found another typos. >> "jsonrpc": "2.0", should be added to all examples. >> > > Thanks. I will incorporate this. > > >> >> Regards, >> Sungjin >> >> >> On 07/16/2013 06:56 AM, Vincent Chen wrote: >> >> Sungjin, >> >> Sorry for the long delay (vacation). Answers inline. >> >> >> On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 wrote: >> >>> Hi All, >>> >>> I have found two typos. >>> >>> At example "getSpectrum" JSON-RPC in 6.4.1. : >>> "id": "xxxxxx", --> Comma should be deleted. >>> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >>> "id": "xxxxxx", --> Comma should be deleted. >>> >> >> Thanks! >> >> >>> >>> >>> I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 >>> and 6.5.2. >>> There are two spectrum information parameters for the same frequency >>> range. >>> One is for bandwidth 6e6, and the other is for bandwidth 1e5. >>> But spectral density of 6e6 is different from that of 1e5 in the same >>> frequency range. >>> It will be more nice if the spectral density of the same frequency rang= e >>> is same. >>> Or it will be also nice if frequency ranges are modified to be differen= t >>> from each other. >>> >> >> This is intended to represent the permissible maximum power in which >> "wide-band" and "narrow-band" operations are permitted. >> The available frequencies do not change (hence, the same start/stop >> frequencies), just the permissible power. >> >> >> Does that make sense? >> >> -vince >> >> >> >>> Thank you. >>> >>> BR, >>> Sungjin >>> >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> Gabor.Bajko@nokia.com >>> Sent: Thursday, June 20, 2013 2:18 AM >>> To: paws@ietf.org >>> Subject: [paws] WGLC on >>> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >>> >>> >>> All, >>> >>> The Editor of the document posted a new version and indicated that all >>> open issues raised on the list were resolved, and that there are no mor= e >>> open issues he is aware of. >>> Therefore, I'd like to issue a wg last call on the document. We need >>> reviews and feedback in order to be able to progress the document. >>> >>> Please read through the draft and send any comments you may have to the >>> list in the next 2-3 weeks. >>> If you review the draft and have no comments, send a note to the list >>> that the draft is good as it is, we need these notes as much as we need= the >>> actual comments. >>> >>> Thanks, Gabor >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >> >> >> >> -- >> -vince >> >> >> > > > -- > -vince > > > Regards, > Sungjin > > --=20 -vince --e89a8ff1cc9e0c25eb04e1d67098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sunglin,

Some clarification: The maxPow= erDbm is total power. It is not a spectral density.

Thus, if a 6MHz channel is available, the Device may choose to put, say, = ten 100kHz sub-channels within that channel.
The total power summed over those 10 sub-channels cannot exceed 27dBm.=

So here is one way the Device may use the response.=
=C2=A0- The Device determines first if it wants to be a narrow b= and (1e5) or wideband (6e6) device
=C2=A0- It selects the Spectrum specification, based on its mode
=


-vince


On Thu, Jul 18, 20= 13 at 9:49 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
=20 =20 =20
Vince,

Comment is in line.


On 07/19/2013 10:16 AM, Vincent Chen wrote:
=20
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <sjyou@etri.re.kr> wrote:
Vince,

I understand "bandwidth" parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always
guaranteed to be the same.

If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=3D27dBm + 17.78dB). The master device don't know which one is correct.
So I think it will be clear if "frequencyRanges" in the secon= d one(for "bandwidth" : 1e5) is modified to different frequency= from first one(for "bandwidth" : 1e5)


And I found another typos.
"jsonrpc": "2.0", should be added to = all examples.

Thanks. I will incorporate this.
=C2=A0

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 <sjyou= @etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC i= n 6.4.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id": &= quot;xxxxxx", =C2=A0 =C2=A0 --> Comma should be deleted.
At example "getSpectrumBatch" JSON-= RPC in 6.5.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "id": &= quot;xxxxxx", =C2=A0 =C2=A0 --> Comma should be deleted.

Thanks!
=C2=A0


I have a comment about example "getSpectrum" JSON-RPC response in = 6.4.2 and 6.5.2.
There are two spectrum information parameters =C2=A0for the same frequency range= .
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band&q= uot; operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://= tools.ietf.org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg las= t call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

Thanks, Gabor
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws<= /a>



--
-vince




--
-vince

Regards,
Sungjin




--
-vince
--e89a8ff1cc9e0c25eb04e1d67098-- From sjyou@etri.re.kr Thu Jul 18 23:02: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 2DA2911E82A2 for ; Thu, 18 Jul 2013 23:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.323 X-Spam-Level: X-Spam-Status: No, score=-101.323 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw1RvRF3RlH0 for ; Thu, 18 Jul 2013 23:02:08 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 38EE411E82A0 for ; Thu, 18 Jul 2013 23:02:07 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Jul 2013 15:02:05 +0900 Received: from [129.254.65.147] (129.254.65.147) by SMTP4.etri.info (129.254.28.74) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 19 Jul 2013 15:02:03 +0900 Message-ID: <51E8D65A.5030500@etri.re.kr> Date: Fri, 19 Jul 2013 15:02:02 +0900 From: Sungjin Yoo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Vincent Chen References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080109070506090803050000" X-Originating-IP: [129.254.65.147] Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 19 Jul 2013 06:02:13 -0000 --------------080109070506090803050000 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Vince, Comment is in line. On 07/19/2013 02:17 PM, Vincent Chen wrote: > Sunglin, > > Some clarification: The maxPowerDbm is total power. It is not a > spectral density. > I agree. But (maxPowerDBm / bandwidth) defines the spectral density. > Thus, if a 6MHz channel is available, the Device may choose to put, > say, ten 100kHz sub-channels within that channel. > The total power summed over those 10 sub-channels cannot exceed 27dBm. > > So here is one way the Device may use the response. > - The Device determines first if it wants to be a narrow band (1e5) > or wideband (6e6) device > - It selects the Spectrum specification, based on its mode > I think "bandwidth" parameter does not limit the operation bandwidth of the device, it is just reference bandwidth to define permissible power levels and that is equivalent to define spectral density. I think "maxContiguousBwHz" parameter(4.4.2) limit the operation bandwidth, and "bandwidth" parameter does not. I understand the "bandwidth" parameter from following paragraphs. 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed from the start and stop frequencies) MAY be different from the"bandwidth" value. 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP spectral density." 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a constraint on the maximum contiguous bandwidth (in Hertz) allowed." > > -vince > > > On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo > wrote: > > Vince, > > Comment is in line. > > > On 07/19/2013 10:16 AM, Vincent Chen wrote: >> Sungjin, >> >> >> On Mon, Jul 15, 2013 at 6:02 PM, Sungjin > > wrote: >> >> Vince, >> >> I understand "bandwidth" parameter is just for defining >> permissible power or spectral density and >> it dose not represent the operation bandwidth. (see 4.4.5. >> SPECTRUC_USE_NOTIFY, 'spectra' parameter description) >> If I misunderstand, please correct me. >> >> >> Oh, I understand what you're saying. The example does not make >> sure the math works out to be equivalent. >> I thought, though, some regulators actually wants different power >> spectral density for narrow band, so it's not always >> guaranteed to be the same. > > If master device receive the message in the example, it will be > confused. Assume the master device decides to use the spectrum > from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this > message. Then the master device may be confused to interpret > permissible maximum power. First one in the example represents > 30.0 dBm, but second one represents about 44.78 dBm(=27dBm + > 17.78dB). The master device don't know which one is correct. > So I think it will be clear if "frequencyRanges" in the second > one(for "bandwidth" : 1e5) is modified to different frequency from > first one(for "bandwidth" : 1e5) > > >> And I found another typos. >> "jsonrpc": "2.0", should be added to all examples. >> >> >> Thanks. I will incorporate this. >> >> >> Regards, >> Sungjin >> >> >> On 07/16/2013 06:56 AM, Vincent Chen wrote: >>> Sungjin, >>> >>> Sorry for the long delay (vacation). Answers inline. >>> >>> >>> On Sun, Jun 30, 2013 at 10:30 PM, 유성진 >> > wrote: >>> >>> Hi All, >>> >>> I have found two typos. >>> >>> At example "getSpectrum" JSON-RPC in 6.4.1. : >>> "id": "xxxxxx", --> Comma should be deleted. >>> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >>> "id": "xxxxxx", --> Comma should be deleted. >>> >>> >>> Thanks! >>> >>> >>> >>> I have a comment about example "getSpectrum" JSON-RPC >>> response in 6.4.2 and 6.5.2. >>> There are two spectrum information parameters for the >>> same frequency range. >>> One is for bandwidth 6e6, and the other is for bandwidth >>> 1e5. >>> But spectral density of 6e6 is different from that of >>> 1e5 in the same frequency range. >>> It will be more nice if the spectral density of the same >>> frequency range is same. >>> Or it will be also nice if frequency ranges are modified >>> to be different from each other. >>> >>> >>> This is intended to represent the permissible maximum power >>> in which "wide-band" and "narrow-band" operations are permitted. >>> The available frequencies do not change (hence, the same >>> start/stop frequencies), just the permissible power. >>> >>> Does that make sense? >>> >>> -vince >>> >>> >>> >>> Thank you. >>> >>> BR, >>> Sungjin >>> >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org >>> >>> [mailto:paws-bounces@ietf.org >>> ] On Behalf Of >>> Gabor.Bajko@nokia.com >>> Sent: Thursday, June 20, 2013 2:18 AM >>> To: paws@ietf.org >>> Subject: [paws] WGLC on >>> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >>> >>> >>> All, >>> >>> The Editor of the document posted a new version and >>> indicated that all open issues raised on the list were >>> resolved, and that there are no more open issues he is >>> aware of. >>> Therefore, I'd like to issue a wg last call on the >>> document. We need reviews and feedback in order to be >>> able to progress the document. >>> >>> Please read through the draft and send any comments you >>> may have to the list in the next 2-3 weeks. >>> If you review the draft and have no comments, send a >>> note to the list that the draft is good as it is, we >>> need these notes as much as we need the actual comments. >>> >>> Thanks, Gabor >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>> >>> >>> >>> >>> -- >>> -vince >> >> >> >> >> -- >> -vince > > Regards, > Sungjin > > > > > -- > -vince --------------080109070506090803050000 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
Vince,

Comment is in line.


On 07/19/2013 02:17 PM, Vincent Chen wrote:
Sunglin,

Some clarification: The maxPowerDbm is total power. It is not a spectral density.

I agree. But (maxPowerDBm / bandwidth) defines the spectral density.

Thus, if a 6MHz channel is available, the Device may choose to put, say, ten 100kHz sub-channels within that channel.
The total power summed over those 10 sub-channels cannot exceed 27dBm.

So here is one way the Device may use the response.
 - The Device determines first if it wants to be a narrow band (1e5) or wideband (6e6) device
 - It selects the Spectrum specification, based on its mode

I think "bandwidth" parameter does not limit the operation bandwidth of the device, it is just reference bandwidth to define permissible power levels and that is equivalent to define spectral density. I think "maxContiguousBwHz" parameter(4.4.2)  limit the operation bandwidth, and "bandwidth" parameter does not.

I understand the "bandwidth" parameter from following paragraphs.

4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed from the start and stop frequencies) MAY be different from the"bandwidth" value.

5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP spectral density."

4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a constraint on the maximum contiguous bandwidth (in Hertz) allowed."



-vince


On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
Vince,

Comment is in line.


On 07/19/2013 10:16 AM, Vincent Chen wrote:
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <sjyou@etri.re.kr> wrote:
Vince,

I understand "bandwidth" parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always
guaranteed to be the same.

If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=27dBm + 17.78dB). The master device don't know which one is correct.
So I think it will be clear if "frequencyRanges" in the second one(for "bandwidth" : 1e5) is modified to different frequency from first one(for "bandwidth" : 1e5)


And I found another typos.
"jsonrpc": "2.0", should be added to all examples.

Thanks. I will incorporate this.
 

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC in 6.4.1. :
        "id": "xxxxxx",     --> Comma should be deleted.
At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
        "id": "xxxxxx",     --> Comma should be deleted.

Thanks!
 


I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters  for the same frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band" operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

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



--
-vince




--
-vince

Regards,
Sungjin




--
-vince

--------------080109070506090803050000-- From mrhead@google.com Mon Jul 22 08:02:21 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 D9B3411E80F2 for ; Mon, 22 Jul 2013 08:02:21 -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 C0r4D4EFOccf for ; Mon, 22 Jul 2013 08:02:17 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EC93C11E80AE for ; Mon, 22 Jul 2013 08:02:16 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 17so3189270iea.17 for ; Mon, 22 Jul 2013 08:02:16 -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=nNjJTrFaAOItKqzE0AK4UePeoN/i3T8v3uEvBjKJ9+c=; b=eJ7L0k8v1x3AbQzRtt2KBU5gIJVJSQhCLs9E7kKMrrnMH7DxtwlUAWmnuVDrgdvk3h /zssDqBFWX2HbpmvVPMDN6XKpaU5whB5KZQ4ELiNaQRyCrmWDFi8+BttSh69F5JRGHHD 6lNSD9+bwmHXtvvwhMD0vLXcs3DCfwe7+uNAK1MPDx62yVaRV22f8MEhQ8PMCuC+p7tY aW89niEUPIS4lfiWRTuIPCEDQlCAv6eVzTCZXV1kfk9yk+E4gk/xpRoXUPUBMC3nrjti mMlTGfdk5Lx1VDMwhEv1aNd36otEzS3N412j+AAkdLW2hBDcb0/l1/a1/MrwttnyL0Mu /w9A== X-Google-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:x-gm-message-state; bh=nNjJTrFaAOItKqzE0AK4UePeoN/i3T8v3uEvBjKJ9+c=; b=FlJ2V9NM0NXbjrz2pOmpTrKHA913FSifmuJd1BEtuS/3SjHqJ0mZ7FA1VhWvmbU/xi JoM/pPeA7Atqka6iFr0CuGSWFShgmNF9K3zlA47hYZQ2vir9A9pQ6werj2uVSNBfZCjs /msAtuTyxFtQCSfnLJCbYqhPsOq0UHf7CXAmeahSXMT7DGyMIpfnMumo9kpQCbEe5NfX Q5emr0LK4nwwPY6+hsLsjuV/xWAAyLOVtCugIUxFEX4dYvU2t64p2tfv5iFQk3Mco6c4 0TRyEwNUb3sORnI45mLIOycA3TTExiSKaNS7GoHxG0USYimOesiWDQOzzYdFGoY98QdQ Zxxg== MIME-Version: 1.0 X-Received: by 10.43.133.70 with SMTP id hx6mr11060118icc.34.1374505336473; Mon, 22 Jul 2013 08:02:16 -0700 (PDT) Received: by 10.64.245.204 with HTTP; Mon, 22 Jul 2013 08:02:16 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 22 Jul 2013 08:02:16 -0700 Message-ID: From: Michael Head To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=20cf307f330c52f1d404e21af674 X-Gm-Message-State: ALoCoQnc8TSVMTLNqx1/0Et/dI7NZFaKl108MoghWCKo0IANHnf7cYYv7xTNUc1DhJzKP/Ts17uRgeoA6W8s1eLNyJeiNVDRbORWpZQGltnJ/5sx/aUI1i2am9dQp35UDJ0kJ4STI+u894pkL7Mlf6XpsOt3ARhBMHHhOoPzsYvvdksiDoGm6XbyPTwBOBA1/qNqhALZaXwg Cc: paws@ietf.org Subject: Re: [paws] Reviews requested for http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:02:22 -0000 --20cf307f330c52f1d404e21af674 Content-Type: text/plain; charset=ISO-8859-1 Thanks for the reminder, Gabor. I have two comments which I will start as separate threads. -- mike On Thu, Jul 18, 2013 at 3:42 PM, wrote: > Folks, > > I issued a WGLC on this document 4 weeks ago, and there was no feedback > received at all. > If you care about this document, you should review it and send your > comments to the list. If you review it and you have no comments, then > please send a mail to the list stating that you have reviewed the document > and have no comments. > Without reviews, we cannot make progress with the document. I cannot send > it to the IESG requesting publication. > > - Gabor > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: Wednesday, June 19, 2013 10:18 AM > To: paws@ietf.org > Subject: [paws] WGLC on > http://tools.ietf.org/html/draft-ietf-paws-protocol-06 > > All, > > The Editor of the document posted a new version and indicated that all > open issues raised on the list were resolved, and that there are no more > open issues he is aware of. > Therefore, I'd like to issue a wg last call on the document. We need > reviews and feedback in order to be able to progress the document. > > Please read through the draft and send any comments you may have to the > list in the next 2-3 weeks. > If you review the draft and have no comments, send a note to the list that > the draft is good as it is, we need these notes as much as we need the > actual comments. > > Thanks, Gabor > _______________________________________________ > 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 > -- ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --20cf307f330c52f1d404e21af674 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for the reminder, Gabor. I have two comments which = I will start as separate threads.

-- mike


On Thu, Jul 18, = 2013 at 3:42 PM, <Gabor.Bajko@nokia.com> wrote:
Folks,

I issued a WGLC on this document 4 weeks ago, and there was no feedback rec= eived at all.
If you care about this document, you should review it and send your comment= s to the list. If you review it and you have no comments, then please send = a mail to the list stating that you have reviewed the document and have no = comments.
Without reviews, we cannot make progress with the document. I cannot send i= t to the IESG requesting publication.

- Gabor

-----Original Message-----
From: paws-bounces@ietf.org [m= ailto:paws-bounces@ietf.org] O= n Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Wednesday, June 19, 2013 10:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paw= s-protocol-06

All,

The Editor of the document posted a new version and indicated that all open= issues raised on the list were resolved, and that there are no more open i= ssues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need re= views and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the lis= t in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments.

Thanks, Gabor
_______________________________________________
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



--
----= ------------------------------
Michael R Head <mrhead@google.com>
+1-201-BLISTER
--20cf307f330c52f1d404e21af674-- From mrhead@google.com Mon Jul 22 08:05:04 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 3767D21E80B6 for ; Mon, 22 Jul 2013 08:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=0.442, 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 dOyC173NRAp2 for ; Mon, 22 Jul 2013 08:04:59 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3335911E80F2 for ; Mon, 22 Jul 2013 08:04:59 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so15568357iec.41 for ; Mon, 22 Jul 2013 08:04:58 -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:cc:content-type; bh=iL6hZNUlLDpudPeK3psQrgvV/LT+Si8/5M8yIwOUzXM=; b=oY7piaO5NYnHneMhxlXrnWBqkKP3+RmKhf73ouJrtup3ybzweQaSAAn0CS7EHMfPI9 rftNSca317y9qCHj0uzYsDvoqgvBwGliESeUIbJMAO47bTiiWNNDG0ySIo4V0pg6tFyV adwYt4I2235+cYNkOGxt/57M8mPNeNpxtyb8sHADVtXM78TY3vOOI+Z+LmY3EsKvdUXR IkD1a3YS1XmUrk4r5KzaA+wfkoKRTtytvKaIatK1kdYBtn1lS72MAki98gShFNqSSwrQ 5jdcaG19XyGU+hTJoh9DwgnXC5nps6VcN39J3ielItpCEJMoVcAsJme5mveL/LTOL9Dz ewwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=iL6hZNUlLDpudPeK3psQrgvV/LT+Si8/5M8yIwOUzXM=; b=LgtnXE/61VgTcptVT0nzphr2hyV2IjMFkA3z9uls4cGi4dh7+UQQd0yKVLFapoyxvr 8jsFGnmpadU7NVuggZBUWvo+5PnrTiVqNmT80gMbhTOMPdCD4MDkpA6fsiQ0VlY00pOT b4GqHRefliHpHqmUJKjX21ZTIPt2Vv50dVsZJIBTNFoMEwbQF3vXx/eTAiZvzMpv+aHw BH0o4LhTEqD0XX7Nx6IvPTEuOM5rmV43HlPnupJdaeLoC0OkDaGKijC9y2pWRUcaANdT X4ldK4x7I0vEmHT55O6Qo4uxbudW+G1rpuDGDFdZsU2euXILiMLJavlzjTYOHAX98UDY 5RIw== MIME-Version: 1.0 X-Received: by 10.43.133.70 with SMTP id hx6mr11067446icc.34.1374505498703; Mon, 22 Jul 2013 08:04:58 -0700 (PDT) Received: by 10.64.245.204 with HTTP; Mon, 22 Jul 2013 08:04:58 -0700 (PDT) Date: Mon, 22 Jul 2013 08:04:58 -0700 Message-ID: From: Michael Head To: paws@ietf.org Content-Type: multipart/alternative; boundary=20cf307f330cfe349204e21aff1b X-Gm-Message-State: ALoCoQnxpV+np5q9B830bgb2SjLoTMp3/By33eSqzfkRe173VKKnyNyFwW7GpmFPavvC7hLN2lHYeDwcWL9wUlK51GfAyio7+voMyPHp8lBj2YDkEyuQKbWf+AdDHN7uUASQ9oGlKFs+EvY4maPPhHK+ulFQAPWuNDHmvhNwPnCzZG2IrYxhqVOK0AKg1DJvFHY0DfWOR+Wy Subject: [paws] Device assumptions about spectrum? Non-horizontal limit levels? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 15:05:04 -0000 --20cf307f330cfe349204e21aff1b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The current spectrum profile schema allows only for flat frequency ranges that cover a particular range of frequencies. What should database provide and devices assume about their usage outside the range? As I understand it, emitted power doesn=92t have fixed vertical boundaries: it has a tail off over neighboring frequencies. If the database finds available spectrum from frequencies in the closed/open range [720MHz-750Mhz) that allows for 35dB of output, what should the database report about frequencies below 720/above 750? If the database says nothing, what should the device do? It might be clearer if the format allowed for a more general shape, either a list of line segments that allow for (frequency =D7 power) pairs to defin= e a more curvey shape or a strictly ordered sequence of (frequency =D7 power) points to do the same. For example, either of these would allow for the following kinds of shapes (x axis representing frequency, y axis representing power -- hopefully the shapes come across OK): _______ _ _ | | / \ / \ | | | \/ | | | | | which would more clearly define the area underwhich the emitted power profile must fit. Such shapes could of course be simulated with horizontal levels by placing =93feet=94 at the bottom of vertical bars and =93quantizing=94 diagonals in= some way: _____ _ _ _ _ _ _ __ _ _ _ _ But unless the quantized steps are done at a high resolution, this would reduce the total returned spectrum, since I believe each step would need need take the minimum power value over the range of frequencies it covers in order for the result to remain in compliance with the regulators rules. -- ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --20cf307f330cfe349204e21aff1b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
The current spectrum profile schema allows only for flat f= requency ranges that cover a particular range of frequencies. What should d= atabase provide and devices assume about their usage outside the range?


As I understand it, emitted power doesn=92t have fixed vertical bou= ndaries: it has a tail off over neighboring frequencies. If the database fi= nds available spectrum from frequencies in the closed/open range [720MHz-75= 0Mhz) that allows for 35dB of output, what should the database report about= frequencies below 720/above 750? If the database says nothing, what should= the device do?


It might be clearer if the format allowed for a more general shape,= either a list of line segments that allow for (frequency =D7 power) pairs = to define a more curvey shape or a strictly ordered sequence of (frequency = =D7 power) points to do the same.


For example, either of these would allow for the following kinds of= shapes (x axis representing frequency, y axis representing power -- hopefu= lly the shapes come across OK):

=A0_____ =A0 =A0 =A0_ =A0 =A0= _
=A0 =A0 =A0 =A0 =A0 =A0_ _ =A0_ _
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ___ =A0 =A0 _ =A0 _ =A0 =A0 =A0 =A0_


But unless the quanti= zed steps are done at a high resolution, this would reduce the total return= ed spectrum, since I believe each step would need need take the minimum pow= er value over the range of frequencies it covers in order for the result to= remain in compliance with the regulators rules.

--
----------------------------------
Michael R Head <mrhead@google.com>
http://www.cs.binghamton.edu/~mike
+1= -201-BLISTER
--20cf307f330cfe349204e21aff1b-- From mrhead@google.com Mon Jul 22 08:06:53 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 CEB2121F9E88 for ; Mon, 22 Jul 2013 08:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=-0.221, 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 0zdnhUUhdYmK for ; Mon, 22 Jul 2013 08:06:48 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F37C321E8097 for ; Mon, 22 Jul 2013 08:06:37 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 17so3239843iea.3 for ; Mon, 22 Jul 2013 08:06:34 -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=uk0XX1hB+dbUgY7tZV7cExL7W+noXaBJF9ivseV6Rnw=; b=eEI+syw5d6W4PvwwuRjdsXfpNjyTOCBV4ePI2jPczY94P0hM+5TxQc96EuEl6FmMCr VkbNbImZG2K80AcWNFCOauGDg3a8nbdWx96a4XrBUVjJpe83zmk0dPhzrZpDFH7KTGu/ n0mjZqhxtNYPm+83GO8I7yFf1C60gNFrQJzQYGlqpibVrGZRdTx3hxafMuT+rIb+1wbo CUTYxnbED8ElnFzxQbRkcMxiZ5xLo0iV+h/F3X7e4XNcpK8EPi9DkNEUroDD/pP8mlCP DzYMJFxYbwH6o8qPDdCKyhE434L/DZ6kzkWVCcI6RrFTgTtijcOTWpWTv8uEv466jjQ+ qdVA== X-Google-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 :x-gm-message-state; bh=uk0XX1hB+dbUgY7tZV7cExL7W+noXaBJF9ivseV6Rnw=; b=lIV2gILEUK9E6zK4ULm+Bna9C8f+hEsYbja5iBHx8ilq3k4AEPpmnR8u+wNVyHXwTL ELROhDEXvEio3pe7+/ACOICGQmRKfXZpqTkz5jS+HHOSY5D4JOHzBETh5TBp2JGO3QVt bSm16mysgEVW5VwzP0n6B0xfgzjtRPiTmk2sCaw5trgBg8aDvMGJgNxKp28W1AT1qlQA ZRNTOj5RfBEQ2iqLKROZdJlO6XiulHEKMORCqKWQ1+vUnRBkBOaf3OOa4cb9t+LLNoZ9 RB8Egstm8eqEps67iaOPtySzBwsn3U4vx4Y677Y/rEeOyzgVIrfuIOEI5eY5JPX8MP1R J+cg== MIME-Version: 1.0 X-Received: by 10.43.145.69 with SMTP id jt5mr17220174icc.65.1374505594229; Mon, 22 Jul 2013 08:06:34 -0700 (PDT) Received: by 10.64.245.204 with HTTP; Mon, 22 Jul 2013 08:06:34 -0700 (PDT) Date: Mon, 22 Jul 2013 08:06:34 -0700 Message-ID: From: Michael Head To: paws@ietf.org Content-Type: multipart/alternative; boundary=001a11c30312afb35004e21b05d9 X-Gm-Message-State: ALoCoQlt+YPSL5zRxLwxv/KAp6nqz1OHjCtOL8AYJsTWBwpLhOQtw8BoCD4JTZlyRSeSHruSPzLzyguWT9I4PoffB+fA0srIjNHhfPZkaG3yjKsNIYRZhLPl1WvgO2hboQk1rtE+ebuzdTSgngqqc9gsrCXdwm5Ui1h8R0HuDZuSxuecMP+mm2nvbmtNS8lXXJEt0YaNo6OK Subject: [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: Mon, 22 Jul 2013 15:06:53 -0000 --001a11c30312afb35004e21b05d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 can only detect that the database requires these calls by inspecting 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 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 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=92t be particularly graceful: the client might send a version 1.1 message to the database, and 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 web= . JSON-RPC is really only built to allow for programmatic clients. So.... I=92d rather see a RESTful API that develops application state throu= gh 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 seen 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.respon= se-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 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-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 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 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 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 get 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 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 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 m= ight 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. --=20 ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --001a11c30312afb35004e21b05d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I suppose this will be controversial, but I=92m finding that relying on JS= ON-RPC is driving unnecessary coupling among the device, database and regul= atory 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 wel= l as the ruleset under which the server will operate.


For examp= le, 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 data= base 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 spectr= um.paws.Register to be called. The device can only detect that the database= requires these calls by inspecting 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 determined by the governing ruleset ID, and its = precise meaning must be baked into both the database and the device, and th= ey must assume that their respective semantics will agree.


Some of t= hese issues could be solved by reducing the amount of optionality (and perh= aps some of the optional calls) and requiring a standard sequence of operat= ions. This may work, but I feel the coupling would still be high. Protocol = version upgrades (and version negotiation) won=92t be particularly graceful= : the client might send a version 1.1 message to the database, and even tho= ugh the client might also support 1.0, it would get an error response if th= e database didn=92t support 1.0.


As a seco= ndary issue, it=92s less natural to expose the service via the web. JSON-RP= C is really only built to allow for programmatic clients.


So.... I= =92d rather see a RESTful API that develops application state through the u= se of hyperlinked, content-typed message bodies. I suppose REST-vs-RPC has = been discussed quite a bit in general, but I haven=92t seen 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<= /span>=


Device PO= STs an application/vnd.paws.init.request-v1+json message to http://example.com/paws with header

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


Database = (let=92s say it only supports v1) responds with a application/paws.init.res= ponse-v1+json message which includes the details in 4.2.2 of the draft -- w= ith, say a cache-control: max-age=3D86400 header -- but contain an addition= al field: spectrumResource: {acceptable-content-type: application/paws.gets= pectrum.request-v1+json; required-fields: device/fccId; uri: http://example.com/paws/available-spectrum}


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

= Accept: ap= plication/vnd.paws.notifyuse-v1+json


Database = response with an application/paws.getspectrum.response-v1+json response con= taining the details specified in 4.4.2 with an additional field (if it is r= equired 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<= span style=3D"font-size:15px;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;vertical-align:baseline;white-space:pre-wrap">}.

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


In this w= ay, the device only needs to know how to negotiate and handle the content t= ypes and be configured with the initial URL of the service. Some interestin= g benefits:


* The dev= ice can connect to the database to ask about any location and -- if the ori= ginal database doesn=92t support a given country -- be transparently direct= ed in the response to another database to file the get spectrum request. It= =92s feasible for any database to federate with other databases and provide= seamless database discovery anywhere whitespace databases are in use (thou= gh this doesn=92t speak to the protocol by which the databases would discov= er each other)

= * At each = POST, the device declares the response version it can handle which indicate= s to the server that it can safely use that version and assume it will be h= andled by the client according to that particular version of the spec. Furt= her, 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=92= s a very natural mapping to a web-browser accessible site for viewing/query= ing 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/longit= ude=3D75W might be bookmarked for repeated viewings for a particular locat= ion.

= * The init= ialization response could be augmented with ruleset definitions that could = be cachable, GETtable resources that (perhaps in a future version of the sp= ec when the breadth of rulesets is better known) allow devices to seamlessl= y upgrade their rulesets from the database.


<= /span>

--
--------------------------= --------
Michael R= Head <mrhead@google.com>
+1-2= 01-BLISTER
--001a11c30312afb35004e21b05d9-- From dharasty@appcomsci.com Mon Jul 22 09:54: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 9028111E815C for ; Mon, 22 Jul 2013 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 Qc0Vr95MDHXe for ; Mon, 22 Jul 2013 09:54:25 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id D235D21F84AF for ; Mon, 22 Jul 2013 09:49:47 -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 r6MGniln005099 for ; Mon, 22 Jul 2013 12:49:46 -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 r6MGniPH022657 for ; Mon, 22 Jul 2013 12:49:44 -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; Mon, 22 Jul 2013 12:49:44 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: [paws] JSON-RPC vs. JSON-REST Thread-Index: AQHOhu0jN+M/a1Sh+Uq38K6Wamu7GJlw3dQg Date: Mon, 22 Jul 2013 16:49:43 +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_EC510C021D06A34C92F5A5A488B5290B0CEEDAA9rrcatsexmb2atsa_" MIME-Version: 1.0 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: Mon, 22 Jul 2013 16:54:39 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEDAA9rrcatsexmb2atsa_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In considering Michaels input, these are my thoughts: =B7 I agree that the current draft's ruleset concept and the numbe= r of optional messages (especially server optional message) does not lead t= o 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). =B7 Moving this negotiation to the HTTP headers (as Michael propose= s) is - I suspect - workable. o However, it is my personal opinion that that ties the protocol MORE TIG= HTLY 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-packe= t 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. =A7 As a server process implementing this protocol, what is the benefit to= me to have to "go looking" for "how to handle this message" by looking a b= it in the message, and a bit in the HTTP headers? =B7 Yes, interworking of new protocols (or a new version of the "sa= me" protocol) with old ones is always a bit 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 anytime 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 prerogative to "step back" through older protocols that it= does 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". =B7 I agree that the ability to be "transparently redirected" to a = peer ("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. =B7 As for additional "mappings" from browsers: nothing in our curr= ent spec precludes a Database from replying one way to PAWS messages (in HT= TP 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-bounces@ietf.org] On Behalf Of Mic= hael 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 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEDAA9rrcatsexmb2atsa_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In consid= ering Michaels input, these are my thoughts:

 

= =B7&nbs= p;        I =A0agree that the current draft’s ruleset concept and the n= umber of optional messages (especially server optional message) does= not lead to a particularly clean “negotiation”.=A0 In fact, wh= ile it looks workable, I’m trying to implement it now, and it “= feels” rather clumsy.

   To r= emedy this, I was=A0 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 init= ialize any authentication schemes (if required by the server, and until a s= tandard certificate-based scheme is specified and adopted).

 

=B7         <= /span>Moving this negotiation to the HTTP headers (as Mich= ael proposes) is – I suspect – workable.

<= p class=3DMsoListParagraph style=3D'margin-left:1.0in;text-indent:-.25in;ms= o-list:l0 level2 lfo1'>o=    However, it is my personal opinion that that ties the = protocol MORE TIGHTLY to HTTP.=A0

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

o   <= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>And, as and implementer, I’d rather just deal with the options = of the protocol “in band”, in the protocol itself. <= /span>

=A7  = As a server process implementing this protocol, wha= t is the benefit to me to have to “go looking” for “how t= o handle this message” by looking a bit in the message, and a bit in = the HTTP headers?

&nb= sp;

=B7     &n= bsp;   Yes, interworking of= new protocols (or a new version of the “same” protocol) with o= ld ones is always a bit tricky; it is difficult to know NOW everything we&#= 8217;ll need in the future to make interworking work smoothly.

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

=A7  To my reading, t= he old PAWS server would reply with a JSON-RCP “method not implemente= d”… and thus interworking was handled smoothly.=A0 (It would be= the client’s prerogative to “step back” through older pr= otocols that it does 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 &#= 8220;ignoring unexpected fields” is REQUIRED.

o<= span style=3D'font:7.0pt "Times New Roman"'>   While I think Michael’s proposal would offer a di= fferent way to handle version negotiation, I don’t see that it is = 220;better”… just “a different way”.

 

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

= o   … but, to my read= ing, that is already accommodated by the Section 7 text regarding the handl= ing of HTTP Redirects.

 

= =B7    &nb= sp;    As for addition= al “mappings” from browsers: nothing in our current spec preclu= des 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) wit= h some of Michaels statements… but there is no particular need to go = in to all of that now.

 

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

1.    &nb= sp;  If the rest of the group fi= nds the current “feature/ruleset negotiation” scheme is just fi= ne, then perhaps no action is needed.

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

o   “Fix= ing it” in the current “style”: introduce a more clear &#= 8211; possibly REQUIRED – =A0“negotiation” to the existin= g JSON-RPC.

o   Changing direction n= ow to Michaels proposed use of HTTP headers.

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

 

Thoughts?<= /span>

 

Dan Harasty

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

 

From: paws-bounces@ietf.org [mai= lto:paws-bounces@ietf.org] On Behalf Of Michael Head
Sent:= Monday, July 22, 2013 11:07 AM
To: paws@ietf.org
Subject:<= /b> [paws] JSON-RPC vs. JSON-REST

 

I suppose this will be controversial, but I’m finding that rel= ying on JSON-RPC is driving unnecessary coupling among the device, database= and regulatory authority. What I mean by this is that each device/client h= as 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 impleme= nted so that it only makes the spectrum.paws.GetSpectrum RPC. However, in o= rder for this to work, the database it is configured to communicate with mu= st be built to allow for this: it won’t 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.

 

Some of these issue= s could be solved by reducing the amount of optionality (and perhaps some o= f the optional calls) and requiring a standard sequence of operations. This= may work, but I feel the coupling would still be high. Protocol version up= grades (and version negotiation) won’t be particularly graceful: the = client might send a version 1.1 message to the database, and even though th= e client might also support 1.0, it would get an error response if the data= base didn’t support 1.0.

 

As a se= condary issue, it’s less natural to expose the service via the web. J= SON-RPC is really only built to allow for programmatic clients.=

 

So.... I’d rather see a RESTful API that de= velops application state through the use of hyperlinked, content-typed mess= age bodies. I suppose 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 REST= ful 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 messag= e to http://example.com/paws with header

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

=  

Database= (let’s say it only supports v1) responds with a application/paws.ini= t.response-v1+json message which includes the details in 4.2.2 of the draft= -- with, say a cache-control: max-age=3D86400 header -- but contain an add= itional field: spectrumResource: {acceptable-content-type: application/paws= .getspectrum.request-v1+json; required-fields: device/fccId; uri: http://example.com/paws/availab= le-spectrum}

&= nbsp;

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

Accept: application/vnd.paws.no= tifyuse-v1+json

 =

Database response with= an application/paws.getspectrum.response-v1+json response containing the d= etails specified in 4.4.2 with an additional field (if it is required for s= pectrum 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 = the content types and be configured with the initial URL of the service. So= me interesting benefits:

&nb= sp;

* The device = can connect to the database to ask about any location and -- if the origina= l database doesn’t support a given country -- be transparently direct= ed in the response to another database to file the get spectrum request. It= ’s feasible for any database to federate with other databases and pro= vide seamless database discovery anywhere whitespace databases are in use (= though this doesn’t speak to the protocol by which the databases woul= d 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 ver= sion and assume it will be handled by the client according to that particul= ar 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 t= o design such a feature into the protocol itself.

* There’s a very natural= mapping to a web-browser accessible site for viewing/querying the database= contents: visit http://example.com/paws<= /span> in a browser, and it sends back a page with a map allowing th= e user to pick a location. URLs like http://example.com/paws/avail= able-spectrum/latitude=3D45N/longitude=3D75W might be bookmar= ked for repeated viewings for a particular location.

<= p style=3D'margin:0in;margin-bottom:.0001pt'>* The initialization respon= se could be augmented with ruleset definitions that could be cachable, GETt= able resources that (perhaps in a future version of the spec when the bread= th of rulesets is better known) allow devices to seamlessly upgrade their r= ulesets from the database.

<= o:p> 

 

--

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

Michael R Head <mrhead@google.com><= /o:p>

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEDAA9rrcatsexmb2atsa_-- From vchen@google.com Mon Jul 22 21:58:04 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 56EA111E81F7 for ; Mon, 22 Jul 2013 21:58:04 -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 Q922F4xxBiS1 for ; Mon, 22 Jul 2013 21:58:02 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 591E611E81E9 for ; Mon, 22 Jul 2013 21:58:02 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id dn14so9198733obc.16 for ; Mon, 22 Jul 2013 21:58:00 -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=1r5XgiV2V9TUwk/iyUbrU2hvlwGsqhjR1WRo8YsETRo=; b=lNv6FHqAgAL+8tyZLYeMMMSW6rupayDGodwvHwVQ7eEC/1UJFzPTP8a0l/d7JlRjmP EzhpftKZvn/1ICLjV+PyzyEKxOiqGXjM89YURdlbW/ST1sTrV6aBrgj9+UDggdRmmc5d E7+ZUy93FSowESyeEHU/HyyGj/VWkpwVO8inSYOfKjYaUlstf7scsFE04t80/zSlE0g5 lJzT6O7MSvBY021fuXeUkInKuvbrbD3h0fr4lHU2b/MjAsOa0I2yfKM8Kj1brT5VHqNI ZGKYp/wpOntmBPPmLGVeggy1/cIe6oJB/4rYo+Q5yYj57IHGc7MngPbOc9pwosSa/lP2 ij9g== X-Google-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:x-gm-message-state; bh=1r5XgiV2V9TUwk/iyUbrU2hvlwGsqhjR1WRo8YsETRo=; b=RusgfcZrQHmnEmB0FHCUbhSW3VE7m2MYMJj9RSVWY2uwuRC404kZPpSZspR/9GTcGp qNvoQCoswv8M7c0M1BRDPTHO+FDCm0Wv7rPwbgsTBvXOukbphMg3OxtDWvo2uEiFqZCY utQbeuNtP3h0vcudUQwRC//Q5RwgtCf22msaKZ0M4Q7q7qOGUKnwjEHAw15ogph7OfqU EgiLLjuK8VuLnNDOu/qq7i35WQC5y8YRQsayMi9OLYhuYj35GPdvCvEejeMpc9Lz8LGU euBkzky2UT/TnOY/4iQ1HJ/pGhfBmOfMMDBBdbI9lCSHSR/a5dpvk8CTgtvVfpY1Chsn C29g== MIME-Version: 1.0 X-Received: by 10.182.142.66 with SMTP id ru2mr8289788obb.4.1374555480499; Mon, 22 Jul 2013 21:58:00 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Mon, 22 Jul 2013 21:58:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Jul 2013 21:58:00 -0700 Message-ID: From: Vincent Chen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=001a11c2e12823c60e04e226a3c3 X-Gm-Message-State: ALoCoQkLXap7I8myEjbNTEvpMVSe0Myw1r5hc5QGCpgmuzYqEyJqdLLOW1KZTtzPTos6Zk1k7gfCPXCXsr/riQgO+4Npg5S1e9IiIFpKeWGocycbXhMB6xwO45T7wqsmtAV3JQQlGuQusHFAp39R1/ya0ldkG7aWOMiVqmY+wwVd69hcs8D5tUQb8jSyzgk150olt9+IgktO 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: Tue, 23 Jul 2013 04:58:04 -0000 --001a11c2e12823c60e04e226a3c3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Michael, Dan, Thanks for the thoughtful suggestions and response. Dan, please do make a proposal about the negotiation. I think, though, that we do not want to force each query of available spectrum to require two separate requests (INIT and AVAIL_SPECTRUM_GET). -vince 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 -vince --001a11c2e12823c60e04e226a3c3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Michael, Dan,

Thanks for the thoughtful= suggestions and response.

Dan, please do make a p= roposal about the negotiation.
I think, though, that we do not wa= nt to force each query of available spectrum to require two separate reques= ts (INIT and AVAIL_SPECTRUM_GET).


-vince


On Mon, Jul 22, 2013 at 9:49 AM, Ha= rasty, 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




--
-vince
--001a11c2e12823c60e04e226a3c3-- From mrhead@google.com Tue Jul 23 10:13:37 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 649AC21E80D4 for ; Tue, 23 Jul 2013 10:13:37 -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 OQqV6dQ7vHRG for ; Tue, 23 Jul 2013 10:13:36 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79911E823F for ; Tue, 23 Jul 2013 10:13:31 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id g12so11906033oah.11 for ; Tue, 23 Jul 2013 10:13:30 -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:cc:content-type; bh=QgfNlAqVcBFipGC2lxEqX+OSerDmeGPLzKmnDDWArMg=; b=YQCfvxc7+RFj3uHfGsMAHU11j1fE67olXcqUX8i2nbxrewxXmhIAPuctGBkVgdbjF6 qv5kG1RTcWBjB5+RQmvRq6oC+yFN2maTIkDX7I8lXH4W+Uf4jKVHIpBBDj57trbkpRzM DCLSzUr0SXBiHjxc0qDFlhvRLiMndERQccvNOAP70Nep4IZQ2hfuLo9AACa2CQU4edh7 u7Oa437SUaFWSgqSZX0RBeLTcqOOYIJgEJXMBvsjkLYIQmEWcnENMHjkPoQnl0GQgOJz 4J38Fpwlrmc7KFFQnQkJaiGg0legZJucrsBztdV5EFPz/TyGxxA0XOy7aGh9vsYKybqV ZMrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=QgfNlAqVcBFipGC2lxEqX+OSerDmeGPLzKmnDDWArMg=; b=kuMv2r6vnqtAgYfWHUx/LRyoWqI86UzjwfHnBjOi9J4yTfIWQakBASXiz+KUW+EV7a fQI2YdSRSC2Ec9bkoooFpAEWEOGB2NF9FXjQOa3v8iXjUTs/ha+AMfkyliaWcwZthXVp nr8OMw7YOjWAvThWQBcWlarQ+l20xrXVKprJsRlXK6LztX7yeqkspb2gFdN5xWeAg8Bh SoDyl3OJUQaqAsZj9oCqcKkZya7ZBqKDlaWErM53As70k6YJDs21GzbzqqsaVGdMDclK R3ehQKnjgqABqqvAaquXRTNbKGXheem42hr0WzqX6+hbIGxMXjv8stObIZ5jMGAYTerG eflw== MIME-Version: 1.0 X-Received: by 10.43.87.136 with SMTP id aw8mr18324224icc.77.1374599610596; Tue, 23 Jul 2013 10:13:30 -0700 (PDT) Received: by 10.64.245.204 with HTTP; Tue, 23 Jul 2013 10:13:30 -0700 (PDT) Date: Tue, 23 Jul 2013 18:13:30 +0100 Message-ID: From: Michael Head To: paws@ietf.org Content-Type: multipart/alternative; boundary=001a11c1f84081665904e230e997 X-Gm-Message-State: ALoCoQm8jWDVIB8xkm5eH/zc/cv9AchOXyC04BQkP6Mok2ZTjP+D6Sx8G3621Aebuer94oUnjo4/DgMI86HjeOSzqeZd18XiQqfnNIhUX94F6img+Z4q5vMmksD1KIcnjrfF9up5+ynvqT0Kt+TDNebY/nKej5E4HoRKKVoWRhCPa0v4bKfwmK2AvtcB1BwEX1pvr5OgUqrg Subject: [paws] EIRP vs. total power and bandwidth? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 17:13:37 -0000 --001a11c1f84081665904e230e997 Content-Type: text/plain; charset=ISO-8859-1 As I understand it, PAWS spectrum is described in terms of total power output over a bandwidth of frequencies (typically these are 6mhz-wide channels in the US, I guess?). This seems to assume that the devices will all use the same sized chunks of the available spectrum and precomputes the total power over those chunks. I believe some devices could use shorter bandwidth chunks (say 100khz) for various purposes. From what I can tell, they'll need to convert the "maxPowerDBm" value (for the given "bandwidth" size) down to an appropriate value for 100khz. Wouldn't it be more general to just give the per-hertz spectral density value here and let the device decide how much spectrum it wants to use and compute the appropriate power output over that range? Thanks, -- mike -- ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --001a11c1f84081665904e230e997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I understand it, PAWS spectrum is described in terms of= total power output over a bandwidth of frequencies (typically these are 6m= hz-wide channels in the US, I guess?). This seems to assume that the device= s will all use the same sized chunks of the available spectrum and precompu= tes the total power over those chunks.=A0

I believe some devices could use shorter bandwidth chunks (s= ay 100khz) for various purposes. From what I can tell, they'll need to = convert the "maxPowerDBm" value (for the given "bandwidth&qu= ot; size) down to an appropriate value for 100khz.

Wouldn't it be more general to just give the per-he= rtz spectral density value here and let the device decide how much spectrum= it wants to use and compute the appropriate power output over that range?<= /div>

Thanks,
-- mike

-= -
----------------------------------
Michael R Head <mrhead@g= oogle.com>
+1-201-BLISTER
--001a11c1f84081665904e230e997-- From vchen@google.com Tue Jul 23 19:14:40 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 49B2311E81C3 for ; Tue, 23 Jul 2013 19:14:40 -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 ZriYVODQUjiw for ; Tue, 23 Jul 2013 19:14:39 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id AF0D911E81C1 for ; Tue, 23 Jul 2013 19:14:38 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n12so8305184oag.22 for ; Tue, 23 Jul 2013 19:14:38 -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=LFPIuJCPQ+DXmcCkstXybiOWG4yxfwFBRnrgRnZKZfM=; b=eK3893CtZoUO0wJUWyL5DhfCm2RUkRUepwZRoJ0PN2WJAbpak+aganWYOYdDsjlu56 YW68p9Eobnli/QB37ddcjgF4RjdbFW+1h56wWz7rl40aQIA5AnbFiOiModtE1NUVbcm9 3pRsULPQpkfM2Ic+4cTzMUMHofSd8reYKPyMfsweX4WxtN+KoTk/OSQ7/SFqKkbZAc5+ fWj39kl7lSPP7FAHj+yvTzDxJCwJUtCLFT/T4EKjRmxeDTAZfCuTAGmXL8AzCyohRwzJ k/4eDIwBkLo6tEAudMh0XzcziovaGo7nnaohjsay82T1yqeFchbK6XRUUDKSpR5Pbosy sZZg== X-Google-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:x-gm-message-state; bh=LFPIuJCPQ+DXmcCkstXybiOWG4yxfwFBRnrgRnZKZfM=; b=pRL/ZBq81gMFvhpLz8s202dJjwH7ldPSKZmyM7yAeZCbtKcsFiaMjby7Q3CyXuYPo4 A1raZtLKXPZPvq8HiMVWiHAPYvrlj1YQTk+dROAVmbPX98wfZN39HSiTaiwXth1g8CmM xFaubnP9E1x/GFYX4FYfpVhr/hErtUkEmfy/XT/C1pD6dfGWG9ISNhi16xIhp9TDfp/M BF0/NWEZhjSdM+MqXP7dO5RKiftdvKHx/igRo8RAnYd7iGUjgubtUCZqoiB4Xl0ZB2Xc igDHdvBMibz0x5UHZqJdQd2fBiDLyHbZjtrawxX6qgpdz2yX1Afz65cD6XkRJnPvDwdl FsDg== MIME-Version: 1.0 X-Received: by 10.60.52.16 with SMTP id p16mr34219920oeo.29.1374632078014; Tue, 23 Jul 2013 19:14:38 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Tue, 23 Jul 2013 19:14:37 -0700 (PDT) In-Reply-To: <51E8D65A.5030500@etri.re.kr> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> <51E8D65A.5030500@etri.re.kr> Date: Tue, 23 Jul 2013 19:14:37 -0700 Message-ID: From: Vincent Chen To: Sungjin Yoo Content-Type: multipart/alternative; boundary=001a11330b22b5327004e2387817 X-Gm-Message-State: ALoCoQnCF1ZVdtG13fnCD3PUgz3t1ihhasMo7gHcgAzRlQQAUci3BfWlbQoqSlbYDHWsfldTL7TI+mTDCvuFUIXntAxb6wyq8CJDL75LF0lQyEaGpe4WjvTYtc92ijYuHB9jr9wmIkQxvobKqCNFfxn8WYxw20bpWW6YihZ2nq1AbZgrc7Xafy6uP7rTPUTYZ3nx9lB0I3Xf Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 02:14:40 -0000 --001a11330b22b5327004e2387817 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sungjin, Sorry for the delay and the confusion. Assuming we have the response that contains: "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, ... ] }, { "bandwidth": 1e5, "frequencyRanges": [ {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, ... ] } This specifies that the frequencies in the range [518MHz, 536MHz) are available, and the device must satisfy two conditions: - Within any 6MHz in that range, total power may not exceed 30.0 dBm AND - Within any 100kHz in that range, total power may not exceed 27 dBm In this example, it means that the device may fit two 100kHz "sub-channels" at 27dBm within any 6MHz channel. (There are many other possibilities.) Does this make sense? If so, I'll update the draft to make this more clear. Thanks. -vince On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo wrote: > Vince, > > Comment is in line. > > > On 07/19/2013 02:17 PM, Vincent Chen wrote: > > Sunglin, > > Some clarification: The maxPowerDbm is total power. It is not a spectral > density. > > I agree. But (maxPowerDBm / bandwidth) defines the spectral density. > > > Thus, if a 6MHz channel is available, the Device may choose to put, say, > ten 100kHz sub-channels within that channel. > The total power summed over those 10 sub-channels cannot exceed 27dBm. > > So here is one way the Device may use the response. > - The Device determines first if it wants to be a narrow band (1e5) or > wideband (6e6) device > - It selects the Spectrum specification, based on its mode > > I think "bandwidth" parameter does not limit the operation bandwidth of > the device, it is just reference bandwidth to define permissible power > levels and that is equivalent to define spectral density. I think > "maxContiguousBwHz" parameter(4.4.2) limit the operation bandwidth, and > "bandwidth" parameter does not. > > I understand the "bandwidth" parameter from following paragraphs. > > 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed > from the start and stop frequencies) MAY be different from the"bandwidth" > value. > > 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum > permitted EIRP spectral density." > > 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a > constraint on the maximum contiguous bandwidth (in Hertz) allowed." > > > > > -vince > > > On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo wrote: > >> Vince, >> >> Comment is in line. >> >> >> On 07/19/2013 10:16 AM, Vincent Chen wrote: >> >> Sungjin, >> >> >> On Mon, Jul 15, 2013 at 6:02 PM, Sungjin wrote: >> >>> Vince, >>> >>> I understand "bandwidth" parameter is just for defining permissible >>> power or spectral density and >>> it dose not represent the operation bandwidth. (see 4.4.5. >>> SPECTRUC_USE_NOTIFY, 'spectra' parameter description) >>> If I misunderstand, please correct me. >>> >> >> Oh, I understand what you're saying. The example does not make sure the >> math works out to be equivalent. >> I thought, though, some regulators actually wants different power >> spectral density for narrow band, so it's not always >> guaranteed to be the same. >> >> >> If master device receive the message in the example, it will be confused= . >> Assume the master device decides to use the spectrum from 5.18e8 Hz to >> 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master >> device may be confused to interpret permissible maximum power. First one= in >> the example represents 30.0 dBm, but second one represents about 44.78 >> dBm(=3D27dBm + 17.78dB). The master device don't know which one is corre= ct. >> So I think it will be clear if "frequencyRanges" in the second one(for >> "bandwidth" : 1e5) is modified to different frequency from first one(for >> "bandwidth" : 1e5) >> >> >> And I found another typos. >>> "jsonrpc": "2.0", should be added to all examples. >>> >> >> Thanks. I will incorporate this. >> >> >>> >>> Regards, >>> Sungjin >>> >>> >>> On 07/16/2013 06:56 AM, Vincent Chen wrote: >>> >>> Sungjin, >>> >>> Sorry for the long delay (vacation). Answers inline. >>> >>> >>> On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 wrote: >>> >>>> Hi All, >>>> >>>> I have found two typos. >>>> >>>> At example "getSpectrum" JSON-RPC in 6.4.1. : >>>> "id": "xxxxxx", --> Comma should be deleted. >>>> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >>>> "id": "xxxxxx", --> Comma should be deleted. >>>> >>> >>> Thanks! >>> >>> >>>> >>>> >>>> I have a comment about example "getSpectrum" JSON-RPC response in 6.4.= 2 >>>> and 6.5.2. >>>> There are two spectrum information parameters for the same frequency >>>> range. >>>> One is for bandwidth 6e6, and the other is for bandwidth 1e5. >>>> But spectral density of 6e6 is different from that of 1e5 in the same >>>> frequency range. >>>> It will be more nice if the spectral density of the same frequency >>>> range is same. >>>> Or it will be also nice if frequency ranges are modified to be >>>> different from each other. >>>> >>> >>> This is intended to represent the permissible maximum power in which >>> "wide-band" and "narrow-band" operations are permitted. >>> The available frequencies do not change (hence, the same start/stop >>> frequencies), just the permissible power. >>> >>> >>> Does that make sense? >>> >>> -vince >>> >>> >>> >>>> Thank you. >>>> >>>> BR, >>>> Sungjin >>>> >>>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>> Of Gabor.Bajko@nokia.com >>>> Sent: Thursday, June 20, 2013 2:18 AM >>>> To: paws@ietf.org >>>> Subject: [paws] WGLC on >>>> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >>>> >>>> >>>> All, >>>> >>>> The Editor of the document posted a new version and indicated that all >>>> open issues raised on the list were resolved, and that there are no mo= re >>>> open issues he is aware of. >>>> Therefore, I'd like to issue a wg last call on the document. We need >>>> reviews and feedback in order to be able to progress the document. >>>> >>>> Please read through the draft and send any comments you may have to th= e >>>> list in the next 2-3 weeks. >>>> If you review the draft and have no comments, send a note to the list >>>> that the draft is good as it is, we need these notes as much as we nee= d the >>>> actual comments. >>>> >>>> Thanks, Gabor >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>> >>> >>> >>> -- >>> -vince >>> >>> >>> >> >> >> -- >> -vince >> >> >> Regards, >> Sungjin >> >> > > > -- > -vince > > > --=20 -vince --001a11330b22b5327004e2387817 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sungjin,

Sorry for the delay and the co= nfusion.

Assuming we have the response that contai= ns:

       "spectra": [
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":27.0},
            ...
          ]
         }

This specifies that the frequencies in the = range [518MHz, 536MHz) are available, and the device must satisfy two condi= tions:

=C2=A0- Within any 6MHz in that range, tota= l power may not exceed 30.0 dBm
AND
=C2=A0- Within any 100kHz in that range, total power may= not exceed 27 dBm

In this example, it means that = the device may fit two 100kHz "sub-channels" at 27dBm within any = 6MHz channel.

(There are many other possibilities.)

Does this make sense? If so, I'll update the draft to make this= more clear.

Thanks.

-vince
=C2=A0=C2=A0

On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo <= span dir=3D"ltr"><= sjyou@etri.re.kr> wrote:
=20 =20 =20
Vince,

Comment is in line.


On 07/19/2013 02:17 PM, Vincent Chen wrote:
=20
Sunglin,

Some clarification: The maxPowerDbm is total power. It is not a spectral density.

I agree. But (maxPowerDBm / bandwidth) defines the spectral density.

Thus, if a 6MHz channel is available, the Device may choose to put, say, ten 100kHz sub-channels within that channel.
The total power summed over those 10 sub-channels cannot exceed 27dBm.

So here is one way the Device may use the response.
=C2=A0- The Device determines first if it wants to be a narr= ow band (1e5) or wideband (6e6) device
=C2=A0- It selects the Spectrum specification, based on its mode

I think "bandwidth" parameter does not limit the operation ba= ndwidth of the device, it is just reference bandwidth to define permissible power levels and that is equivalent to define spectral density. I think "maxContiguousBwHz" parameter(4.4.2)=C2=A0 limit the op= eration bandwidth, and "bandwidth" parameter does not.

I understand the "bandwidth" parameter from following paragra= phs.

4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed from the start and stop frequencies) MAY be different from the"bandwidth" value.

5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP spectral density."

4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a constraint on the maximum contiguous bandwidth (in Hertz) allowed."




-vince


On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
Vince,

Comment is in line.


On 07/19/2013 10:16 AM, Vincent Chen wrote:
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <sjyou@etri.re.kr> wrote:
Vince,

I understand "bandwidth" parameter = is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parame= ter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always
guaranteed to be the same.

If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=3D27dBm + 17.78dB). The master device don't know which one is correct.
So I think it will be clear if "frequencyRanges" in= the second one(for "bandwidth" : 1e5) is modified to di= fferent frequency from first one(for "bandwidth" : 1e5)


And I found another typos.
"jsonrpc": "2.0", shoul= d be added to all examples.

Thanks. I will incorporate this.
=C2=A0

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C= =A0=EC=84=B1=EC=A7=84 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum&qu= ot; JSON-RPC in 6.4.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;id": "xxxxxx", =C2=A0 =C2=A0 --> Comma should be deleted.
At example "getSpectrumBatch" JS= ON-RPC in 6.5.1. :
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &qu= ot;id": "xxxxxx", =C2=A0 =C2=A0 --> Comma should be deleted.

Thanks!
=C2=A0
<= br>
I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters =C2=A0fo= r the same frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band" operati= ons are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince


<= br> Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf= .org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

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



--
-vince




--
-vince

Regards,
Sungjin




--
-vince




--
-vince
--001a11330b22b5327004e2387817-- From sjyou@etri.re.kr Wed Jul 24 00:24:56 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 8D6EE11E80E2 for ; Wed, 24 Jul 2013 00:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.998 X-Spam-Level: X-Spam-Status: No, score=-101.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRx4G-X90-P0 for ; Wed, 24 Jul 2013 00:24:51 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9B02E11E80F0 for ; Wed, 24 Jul 2013 00:24:50 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 24 Jul 2013 16:24:46 +0900 Received: from [129.254.65.147] (129.254.65.147) by SMTP4.etri.info (129.254.28.74) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 24 Jul 2013 16:24:45 +0900 Message-ID: <51EF813D.40609@etri.re.kr> Date: Wed, 24 Jul 2013 16:24:45 +0900 From: Sungjin Yoo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Vincent Chen References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> <51E8D65A.5030500@etri.re.kr> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060207040305030307050504" X-Originating-IP: [129.254.65.147] Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 07:24:56 -0000 --------------060207040305030307050504 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Vince and all, Thanks for the explanation. I understand what you mean. I think current encoding format may cause a misunderstanding. Because maximum power informations for the same frequency may be distributed to multiple object. I think it's clearer if "bandwidth" is coupled with "maxPowerDBm". How about the following format? "spectra": [ { "maxPower":[ {"bandwidthHz":6e6, "maxPowerDBm":30.0}, {"bandwidthHz":1e5, "maxPowerDBm":27.0} ] "frequencyRanges": [ {"startHz":5.18e8, "stopHz":5.36e8}, ... ] Regards, Sungjin On 07/24/2013 11:14 AM, Vincent Chen wrote: > Sungjin, > > Sorry for the delay and the confusion. > > Assuming we have the response that contains: > > "spectra": [ > { > "bandwidth": 6e6, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, > ... > ] > }, > { > "bandwidth": 1e5, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, > ... > ] > } > > This specifies that the frequencies in the range [518MHz, 536MHz) are > available, and the device must satisfy two conditions: > > - Within any 6MHz in that range, total power may not exceed 30.0 dBm > AND > - Within any 100kHz in that range, total power may not exceed 27 dBm > > In this example, it means that the device may fit two 100kHz > "sub-channels" at 27dBm within any 6MHz channel. > > (There are many other possibilities.) > > Does this make sense? If so, I'll update the draft to make this more > clear. > > Thanks. > > -vince > > > On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo > wrote: > > Vince, > > Comment is in line. > > > On 07/19/2013 02:17 PM, Vincent Chen wrote: >> Sunglin, >> >> Some clarification: The maxPowerDbm is total power. It is not a >> spectral density. >> > I agree. But (maxPowerDBm / bandwidth) defines the spectral density. > > >> Thus, if a 6MHz channel is available, the Device may choose to >> put, say, ten 100kHz sub-channels within that channel. >> The total power summed over those 10 sub-channels cannot exceed >> 27dBm. >> >> So here is one way the Device may use the response. >> - The Device determines first if it wants to be a narrow band >> (1e5) or wideband (6e6) device >> - It selects the Spectrum specification, based on its mode >> > I think "bandwidth" parameter does not limit the operation > bandwidth of the device, it is just reference bandwidth to define > permissible power levels and that is equivalent to define spectral > density. I think "maxContiguousBwHz" parameter(4.4.2) limit the > operation bandwidth, and "bandwidth" parameter does not. > > I understand the "bandwidth" parameter from following paragraphs. > > 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as > computed from the start and stop frequencies) MAY be different > from the"bandwidth" value. > > 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the > maximum permitted EIRP spectral density." > > 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY > return a constraint on the maximum contiguous bandwidth (in Hertz) > allowed." > > > >> >> -vince >> >> >> On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo > > wrote: >> >> Vince, >> >> Comment is in line. >> >> >> On 07/19/2013 10:16 AM, Vincent Chen wrote: >>> Sungjin, >>> >>> >>> On Mon, Jul 15, 2013 at 6:02 PM, Sungjin >> > wrote: >>> >>> Vince, >>> >>> I understand "bandwidth" parameter is just for defining >>> permissible power or spectral density and >>> it dose not represent the operation bandwidth. (see >>> 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description) >>> If I misunderstand, please correct me. >>> >>> >>> Oh, I understand what you're saying. The example does not >>> make sure the math works out to be equivalent. >>> I thought, though, some regulators actually wants different >>> power spectral density for narrow band, so it's not always >>> guaranteed to be the same. >> >> If master device receive the message in the example, it will >> be confused. Assume the master device decides to use the >> spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after >> receiving this message. Then the master device may be >> confused to interpret permissible maximum power. First one in >> the example represents 30.0 dBm, but second one represents >> about 44.78 dBm(=27dBm + 17.78dB). The master device don't >> know which one is correct. >> So I think it will be clear if "frequencyRanges" in the >> second one(for "bandwidth" : 1e5) is modified to different >> frequency from first one(for "bandwidth" : 1e5) >> >> >>> And I found another typos. >>> "jsonrpc": "2.0", should be added to all examples. >>> >>> >>> Thanks. I will incorporate this. >>> >>> >>> Regards, >>> Sungjin >>> >>> >>> On 07/16/2013 06:56 AM, Vincent Chen wrote: >>>> Sungjin, >>>> >>>> Sorry for the long delay (vacation). Answers inline. >>>> >>>> >>>> On Sun, Jun 30, 2013 at 10:30 PM, 유성진 >>>> > wrote: >>>> >>>> Hi All, >>>> >>>> I have found two typos. >>>> >>>> At example "getSpectrum" JSON-RPC in 6.4.1. : >>>> "id": "xxxxxx", --> Comma should be deleted. >>>> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >>>> "id": "xxxxxx", --> Comma should be deleted. >>>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> I have a comment about example "getSpectrum" >>>> JSON-RPC response in 6.4.2 and 6.5.2. >>>> There are two spectrum information parameters for >>>> the same frequency range. >>>> One is for bandwidth 6e6, and the other is for >>>> bandwidth 1e5. >>>> But spectral density of 6e6 is different from that >>>> of 1e5 in the same frequency range. >>>> It will be more nice if the spectral density of the >>>> same frequency range is same. >>>> Or it will be also nice if frequency ranges are >>>> modified to be different from each other. >>>> >>>> >>>> This is intended to represent the permissible maximum >>>> power in which "wide-band" and "narrow-band" operations >>>> are permitted. >>>> The available frequencies do not change (hence, the >>>> same start/stop frequencies), just the permissible power. >>>> >>>> Does that make sense? >>>> >>>> -vince >>>> >>>> >>>> >>>> Thank you. >>>> >>>> BR, >>>> Sungjin >>>> >>>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org >>>> >>>> [mailto:paws-bounces@ietf.org >>>> ] On Behalf Of >>>> Gabor.Bajko@nokia.com >>>> Sent: Thursday, June 20, 2013 2:18 AM >>>> To: paws@ietf.org >>>> Subject: [paws] WGLC on >>>> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >>>> >>>> >>>> All, >>>> >>>> The Editor of the document posted a new version and >>>> indicated that all open issues raised on the list >>>> were resolved, and that there are no more open >>>> issues he is aware of. >>>> Therefore, I'd like to issue a wg last call on the >>>> document. We need reviews and feedback in order to >>>> be able to progress the document. >>>> >>>> Please read through the draft and send any comments >>>> you may have to the list in the next 2-3 weeks. >>>> If you review the draft and have no comments, send >>>> a note to the list that the draft is good as it is, >>>> we need these notes as much as we need the actual >>>> comments. >>>> >>>> Thanks, Gabor >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> _______________________________________________ >>>> paws mailing list >>>> paws@ietf.org >>>> https://www.ietf.org/mailman/listinfo/paws >>>> >>>> >>>> >>>> >>>> -- >>>> -vince >>> >>> >>> >>> >>> -- >>> -vince >> >> Regards, >> Sungjin >> >> >> >> >> -- >> -vince > > > > > -- > -vince --------------060207040305030307050504 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
Vince and all,

Thanks for the explanation.
I understand what you mean.

I think current encoding format may cause a misunderstanding. Because maximum power informations for the same frequency may be distributed to multiple object. I think it's clearer if "bandwidth" is coupled with "maxPowerDBm".

How about the following format?

       "spectra": [
         {
          "maxPower":[
	    {"bandwidthHz":6e6, "maxPowerDBm":30.0},
            {"bandwidthHz":1e5, "maxPowerDBm":27.0}
          ]
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8},
            ...
          ]

Regards,
Sungjin

On 07/24/2013 11:14 AM, Vincent Chen wrote:
Sungjin,

Sorry for the delay and the confusion.

Assuming we have the response that contains:

       "spectra": [
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0},
            ...
          ]
         }

This specifies that the frequencies in the range [518MHz, 536MHz) are available, and the device must satisfy two conditions:

 - Within any 6MHz in that range, total power may not exceed 30.0 dBm
AND
 - Within any 100kHz in that range, total power may not exceed 27 dBm

In this example, it means that the device may fit two 100kHz "sub-channels" at 27dBm within any 6MHz channel.

(There are many other possibilities.)

Does this make sense? If so, I'll update the draft to make this more clear.

Thanks.

-vince
  


On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
Vince,

Comment is in line.


On 07/19/2013 02:17 PM, Vincent Chen wrote:
Sunglin,

Some clarification: The maxPowerDbm is total power. It is not a spectral density.

I agree. But (maxPowerDBm / bandwidth) defines the spectral density.


Thus, if a 6MHz channel is available, the Device may choose to put, say, ten 100kHz sub-channels within that channel.
The total power summed over those 10 sub-channels cannot exceed 27dBm.

So here is one way the Device may use the response.
 - The Device determines first if it wants to be a narrow band (1e5) or wideband (6e6) device
 - It selects the Spectrum specification, based on its mode

I think "bandwidth" parameter does not limit the operation bandwidth of the device, it is just reference bandwidth to define permissible power levels and that is equivalent to define spectral density. I think "maxContiguousBwHz" parameter(4.4.2)  limit the operation bandwidth, and "bandwidth" parameter does not.

I understand the "bandwidth" parameter from following paragraphs.

4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed from the start and stop frequencies) MAY be different from the"bandwidth" value.

5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP spectral density."

4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a constraint on the maximum contiguous bandwidth (in Hertz) allowed."




-vince


On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
Vince,

Comment is in line.


On 07/19/2013 10:16 AM, Vincent Chen wrote:
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <sjyou@etri.re.kr> wrote:
Vince,

I understand "bandwidth" parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always
guaranteed to be the same.

If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=27dBm + 17.78dB). The master device don't know which one is correct.
So I think it will be clear if "frequencyRanges" in the second one(for "bandwidth" : 1e5) is modified to different frequency from first one(for "bandwidth" : 1e5)


And I found another typos.
"jsonrpc": "2.0", should be added to all examples.

Thanks. I will incorporate this.
 

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, 유성진 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum" JSON-RPC in 6.4.1. :
        "id": "xxxxxx",     --> Comma should be deleted.
At example "getSpectrumBatch" JSON-RPC in 6.5.1. :
        "id": "xxxxxx",     --> Comma should be deleted.

Thanks!
 


I have a comment about example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters  for the same frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5.
But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same.
Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band" and "narrow-band" operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

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



--
-vince




--
-vince

Regards,
Sungjin




--
-vince




--
-vince

--------------060207040305030307050504-- From mrhead@google.com Wed Jul 24 02:44:56 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 2777E11E839B for ; Wed, 24 Jul 2013 02:44:56 -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 NZmhfNneXhjx for ; Wed, 24 Jul 2013 02:44:55 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5136511E8156 for ; Wed, 24 Jul 2013 02:44:51 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so406399oah.24 for ; Wed, 24 Jul 2013 02:44:50 -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=7bBcNxC96C8kTO9Rf8ge/AKmc5lEMOBvwdhmgNsBLNk=; b=UmsF/sin/GlhOytY+7aaQfo9gWRIw5rUiMSQDQ6eou25Qk9/OKSSTMPQRfjKiNwV06 55aCKw0nkPgd0ERan33NdYNVlk8M8DDc3ULMs2Urj7OyeZnXfum8JGbUZ6BeDntT+YpX Qseb8zvm9D4XW7FYpchNvSITDWfgQLfhyRyykHonvDGzjhn0RwIvYFU5OHAfIXTZd3sB 1NZEDg33ySpfeiOVcdLzOeoDHpKEu6vKDEkI4h0VS4s9Gum7nGbHYB+gxKXqmF5ruqpH RYGhjGZNiCA8l+MB2T0ry75ix1X3ydGPujtPzKBLfEnlWmyzTWWorcN/Y/ABtWR4MLYH 7QLw== X-Google-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 :x-gm-message-state; bh=7bBcNxC96C8kTO9Rf8ge/AKmc5lEMOBvwdhmgNsBLNk=; b=jkd/hYma4Aphi9N8kjOYFHg71LsicugHZWL5xVB/YsCUf/kFleIoDWa7yKvw/0VZdI xDkD4ns7/ExvLdq/8q1swKH0YPWQogReN47I3oO+rQt2ZH+8SiP5xm5QK5y0rdWiHFUm epRGV9YYliZL3wRWVCAXQbbugV8mzhTCFbMi3CVO2/zOnkM1/suvLkxo2H4vVEO+10zA 7sZi6UeFzfS0w4HfKDx+CGYb8AwEBp4n9mYR9mBBMIBT864cC7Z5LiycajOZDx0LppRj DY5BUKy+NX8a39UJfMT65MlVFUGwUOayKKhf5MFDZWWbOcuBZPVHfkV12ILDTsNZBqcm FcHA== MIME-Version: 1.0 X-Received: by 10.50.164.167 with SMTP id yr7mr322626igb.22.1374659089842; Wed, 24 Jul 2013 02:44:49 -0700 (PDT) Received: by 10.64.245.204 with HTTP; Wed, 24 Jul 2013 02:44:49 -0700 (PDT) Date: Wed, 24 Jul 2013 10:44:49 +0100 Message-ID: From: Michael Head To: paws@ietf.org, Andy Lee Content-Type: multipart/alternative; boundary=089e0122a7fcbce7f904e23ec28d X-Gm-Message-State: ALoCoQmFqrQit5T79YXRVQFqT/7CEEfplC9+Z6ORmZ58xiO6be6JfOvDwpS2jIwrMjvQHtw26E7lHe7iMpN3ceup9g1UWFSNNYQxRMSAjL0RHpbaOKRFP/0KQRPc2udfTU8/6SrzkgnZtTieeqvWjUMHfVQK3JBLipEMyfvf4Mw0nnH9l8AkmkoLVBNvBrc0XKSreNKNhQoB Subject: [paws] Supporting multiple authorities / rulesets in a PAWS response? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 09:44:56 -0000 --089e0122a7fcbce7f904e23ec28d Content-Type: text/plain; charset=ISO-8859-1 >From my reading, a device can only get information about spectrum under a single ruleset at a time. (I suppose there is one way around this if a device opts to skip the Init operation and the database opts not to include the rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in the spirit of the protocol). Now, there may be multiple rulesets that govern a particular location. For example, in disputed territories where two governments claim authority (or even just near an undisputed border, the device may want/need to know the spectrum available on both sides of the border). Even within a particular domain, there may be different rulesets governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices might be built to support both and may need to consult a database to get information about all bands. What should devices and databases do? I suppose it can be done by having the device send multiple, independent querys. In the first case, it would send a spectrum request with a DeviceDescriptor with a restricted set of ruleset ids to cover the regulatory domains it cares about (but then, how would it know which domains are useful at a given lat/lon?). For the second case, the device could fire separate requests with DeviceCapabilities set to cover the different bands it supports, which seems a little more workable. Still, it would be nice if these could be handled in a single request/response. Furthermore, certain databases might want to give additional information about spectrum at a location, but the spec doesn't have a standard way of allowing for that. Of course, the database is free to add any fields, anywhere it likes, but it would be nice if there were a structured way to allow a PAWS response to include independent spectrum reports. -- mike -- ---------------------------------- Michael R Head http://www.cs.binghamton.edu/~mike +1-201-BLISTER --089e0122a7fcbce7f904e23ec28d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From my reading, a device can only get information about s= pectrum under a single ruleset at a time. (I suppose there is one way aroun= d this if a device opts to skip the Init operation and the database opts no= t to include the rulesetInfo in the AvailSpectrumResp, but that doesn't= seem to be in the spirit of the protocol).

Now, there may be multiple rulesets that govern a particular= location. For example, in disputed territories where two governments claim= authority (or even just near an undisputed border, the device may want/nee= d to know the spectrum available on both sides of the border).=A0

Even within a particular domain, there may be different= rulesets governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5g= hz bands). Devices might be built to support both and may need to consult a= database to get information about all bands.

What should devices and databases do? I suppose it can = be done by having the device send multiple, independent querys. In the firs= t case, it would send a spectrum request with a DeviceDescriptor with a res= tricted set of ruleset ids to cover the regulatory domains it cares about (= but then, how would it know which domains are useful at a given lat/lon?). = For the second case, the device could fire separate requests with DeviceCap= abilities set to cover the different bands it supports, which seems a littl= e more workable. =A0Still, it would be nice if these could be handled in a = single request/response.

Furthermore, certain databases might want to give addit= ional information about spectrum at a location, but the spec doesn't ha= ve a standard way of allowing for that. Of course, the database is free to = add any fields, anywhere it likes, but it would be nice if there were a str= uctured way to allow a PAWS response to include independent spectrum report= s.

-- mike


--
=
----------------------------------
Michael R Head <mrhead@google.= com>
+1-201-BLISTER
--089e0122a7fcbce7f904e23ec28d-- From vchen@google.com Wed Jul 24 08:25: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 2BDA411E820E for ; Wed, 24 Jul 2013 08:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.527 X-Spam-Level: X-Spam-Status: No, score=-1.527 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 sqgUIsDyR2gd for ; Wed, 24 Jul 2013 08:25:45 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9718621F9D7E for ; Wed, 24 Jul 2013 08:25:21 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so13179879obc.40 for ; Wed, 24 Jul 2013 08:25:21 -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=1w4XscZQpPwk5PvYFO8EoVYfqj0Fwk4upNLic4eQ5GE=; b=iCB0Y/dBSR0ErGKSACzOpGBy5lAOqcDLuJbArc0K0FqukZVoXQdumx8Y63pbmX2t5F /HuaUGNs3mAFIrONnkJ0L8fPKqMEQF2+NaovO6UWe0z8NIIU2Rmj42cw9hKDpk1FLyiZ lbbP9sXogcH7/u88/4t0b7Iqny9WVgcgOUcPzQ+MNu9ei7ZilpEyO7scfgLkikDtQ010 OvVtkcSb+pLaaDXmyTNJCUa+8XZ2FF0Tp8W1WxQ/zG1VFYB0aA37SPZulbonmLuYZhfZ abzoOoWbcqrj/R4hng4fP/j9Eip39yg/uK80F9qqqPgTRkB/AYyKUZgGyWfZaK0Z6aAh rcqA== X-Google-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:x-gm-message-state; bh=1w4XscZQpPwk5PvYFO8EoVYfqj0Fwk4upNLic4eQ5GE=; b=gmdG1BPpmNUfvsnA/kpzjf0npl1PwOOcfDJS/l/ReGrDN3vCes2DzykigN+928B59i TPtWLZsuAIdQ5QjzEoeELWr8gEkr/XCsUWwLo6dkTsD04/zPTXMgEr++X9iaONKz70SK PMGb2m6GgcL2JwC6NBQGf1p4qwfXWAB95cgjIzrjLNr+jhMzyRsL39O6GNKIxUN7kc/w 9oyR+rTmQFXDlEJuCqKLoof0BDOiKTE7jIyMi3Bonry9Y7N0HajU9rmYO6iQBth8eSM9 t7nrQ3CjRdy+C4dh+5olwoDCawbeOK0WRkRHEGDGiXzdJBRklpnmvzESg3QKt8in7W4G RM6Q== MIME-Version: 1.0 X-Received: by 10.182.119.229 with SMTP id kx5mr13894486obb.23.1374679520648; Wed, 24 Jul 2013 08:25:20 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Wed, 24 Jul 2013 08:25:20 -0700 (PDT) In-Reply-To: <51EF813D.40609@etri.re.kr> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> <51E8D65A.5030500@etri.re.kr> <51EF813D.40609@etri.re.kr> Date: Wed, 24 Jul 2013 08:25:20 -0700 Message-ID: From: Vincent Chen To: Sungjin Yoo Content-Type: multipart/alternative; boundary=001a11c2e352823dc804e2438442 X-Gm-Message-State: ALoCoQkGrup58rQsGb6PggVCVXubndJwS/fpQwchrte3NaoI2guLVCvvPrJ7bs8w78HKwH9Y661hqH8SZwx0d9h+l1ol4gRKIj06F015/w1/28+D/+DBkHCG5ghQtkQ3i7tEZ+U64XeQGWSUFd69Q/oqT4m2KnZt1yqPhQSnQAxnyfJvaQpeo3/3KHOGg22crrGpPI0yGuHb Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:25:51 -0000 --001a11c2e352823dc804e2438442 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sungjin, All, Actually, the max power must be associated with each available-frequency range, since it can be different for different ranges. The list of {startHz, stopHz, maxPowerDBm} "roughly" defines a spectral mask. So there might be one for wide-band and a different mask for narrow band operations. There was a question, though, of whether the "mask" should be encoded differently, e.g., Option 1: List of {startHz, maxStartPowerDBm, stopHz, maxStopPowerDBm} Option 2: List of {frequencyHz, maxPowerDBm} sorted by frequencyHz Does anyone have any thoughts on this? -vince On Wed, Jul 24, 2013 at 12:24 AM, Sungjin Yoo wrote: > Vince and all, > > Thanks for the explanation. > I understand what you mean. > > I think current encoding format may cause a misunderstanding. Because > maximum power informations for the same frequency may be distributed to > multiple object. I think it's clearer if "bandwidth" is coupled with > "maxPowerDBm". > > How about the following format? > > "spectra": [ > { > "maxPower":[ > {"bandwidthHz":6e6, "maxPowerDBm":30.0}, > {"bandwidthHz":1e5, "maxPowerDBm":27.0} > ] > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8}, > ... > ] > > > Regards, > Sungjin > > > On 07/24/2013 11:14 AM, Vincent Chen wrote: > > Sungjin, > > Sorry for the delay and the confusion. > > Assuming we have the response that contains: > > "spectra": [ > { > "bandwidth": 6e6, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, > ... > ] > }, > { > "bandwidth": 1e5, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, > ... > ] > } > > > This specifies that the frequencies in the range [518MHz, 536MHz) are > available, and the device must satisfy two conditions: > > - Within any 6MHz in that range, total power may not exceed 30.0 dBm > AND > - Within any 100kHz in that range, total power may not exceed 27 dBm > > In this example, it means that the device may fit two 100kHz > "sub-channels" at 27dBm within any 6MHz channel. > > (There are many other possibilities.) > > Does this make sense? If so, I'll update the draft to make this more > clear. > > Thanks. > > -vince > > > > On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo wrote: > >> Vince, >> >> Comment is in line. >> >> >> On 07/19/2013 02:17 PM, Vincent Chen wrote: >> >> Sunglin, >> >> Some clarification: The maxPowerDbm is total power. It is not a >> spectral density. >> >> I agree. But (maxPowerDBm / bandwidth) defines the spectral density. >> >> >> Thus, if a 6MHz channel is available, the Device may choose to put, >> say, ten 100kHz sub-channels within that channel. >> The total power summed over those 10 sub-channels cannot exceed 27dBm. >> >> So here is one way the Device may use the response. >> - The Device determines first if it wants to be a narrow band (1e5) or >> wideband (6e6) device >> - It selects the Spectrum specification, based on its mode >> >> I think "bandwidth" parameter does not limit the operation bandwidth >> of the device, it is just reference bandwidth to define permissible powe= r >> levels and that is equivalent to define spectral density. I think >> "maxContiguousBwHz" parameter(4.4.2) limit the operation bandwidth, and >> "bandwidth" parameter does not. >> >> I understand the "bandwidth" parameter from following paragraphs. >> >> 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as compute= d >> from the start and stop frequencies) MAY be different from the"bandwidth= " >> value. >> >> 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximu= m >> permitted EIRP spectral density." >> >> 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return = a >> constraint on the maximum contiguous bandwidth (in Hertz) allowed." >> >> >> >> >> -vince >> >> >> On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo wrote: >> >>> Vince, >>> >>> Comment is in line. >>> >>> >>> On 07/19/2013 10:16 AM, Vincent Chen wrote: >>> >>> Sungjin, >>> >>> >>> On Mon, Jul 15, 2013 at 6:02 PM, Sungjin wrote: >>> >>>> Vince, >>>> >>>> I understand "bandwidth" parameter is just for defining permissible >>>> power or spectral density and >>>> it dose not represent the operation bandwidth. (see 4.4.5. >>>> SPECTRUC_USE_NOTIFY, 'spectra' parameter description) >>>> If I misunderstand, please correct me. >>>> >>> >>> Oh, I understand what you're saying. The example does not make sure >>> the math works out to be equivalent. >>> I thought, though, some regulators actually wants different power >>> spectral density for narrow band, so it's not always >>> guaranteed to be the same. >>> >>> >>> If master device receive the message in the example, it will be >>> confused. Assume the master device decides to use the spectrum from 5.1= 8e8 >>> Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the >>> master device may be confused to interpret permissible maximum power. F= irst >>> one in the example represents 30.0 dBm, but second one represents about >>> 44.78 dBm(=3D27dBm + 17.78dB). The master device don't know which one i= s >>> correct. >>> So I think it will be clear if "frequencyRanges" in the second one(for >>> "bandwidth" : 1e5) is modified to different frequency from first one(fo= r >>> "bandwidth" : 1e5) >>> >>> >>> And I found another typos. >>>> "jsonrpc": "2.0", should be added to all examples. >>>> >>> >>> Thanks. I will incorporate this. >>> >>> >>>> >>>> Regards, >>>> Sungjin >>>> >>>> >>>> On 07/16/2013 06:56 AM, Vincent Chen wrote: >>>> >>>> Sungjin, >>>> >>>> Sorry for the long delay (vacation). Answers inline. >>>> >>>> >>>> On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 wrote: >>>> >>>>> Hi All, >>>>> >>>>> I have found two typos. >>>>> >>>>> At example "getSpectrum" JSON-RPC in 6.4.1. : >>>>> "id": "xxxxxx", --> Comma should be deleted. >>>>> At example "getSpectrumBatch" JSON-RPC in 6.5.1. : >>>>> "id": "xxxxxx", --> Comma should be deleted. >>>>> >>>> >>>> Thanks! >>>> >>>> >>>>> >>>>> >>>>> I have a comment about example "getSpectrum" JSON-RPC response in >>>>> 6.4.2 and 6.5.2. >>>>> There are two spectrum information parameters for the same frequency >>>>> range. >>>>> One is for bandwidth 6e6, and the other is for bandwidth 1e5. >>>>> But spectral density of 6e6 is different from that of 1e5 in the same >>>>> frequency range. >>>>> It will be more nice if the spectral density of the same frequency >>>>> range is same. >>>>> Or it will be also nice if frequency ranges are modified to be >>>>> different from each other. >>>>> >>>> >>>> This is intended to represent the permissible maximum power in which >>>> "wide-band" and "narrow-band" operations are permitted. >>>> The available frequencies do not change (hence, the same start/stop >>>> frequencies), just the permissible power. >>>> >>>> >>>> Does that make sense? >>>> >>>> -vince >>>> >>>> >>>> >>>>> Thank you. >>>>> >>>>> BR, >>>>> Sungjin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>>> Of Gabor.Bajko@nokia.com >>>>> Sent: Thursday, June 20, 2013 2:18 AM >>>>> To: paws@ietf.org >>>>> Subject: [paws] WGLC on >>>>> http://tools.ietf.org/html/draft-ietf-paws-protocol-06 >>>>> >>>>> >>>>> All, >>>>> >>>>> The Editor of the document posted a new version and indicated that al= l >>>>> open issues raised on the list were resolved, and that there are no m= ore >>>>> open issues he is aware of. >>>>> Therefore, I'd like to issue a wg last call on the document. We need >>>>> reviews and feedback in order to be able to progress the document. >>>>> >>>>> Please read through the draft and send any comments you may have to >>>>> the list in the next 2-3 weeks. >>>>> If you review the draft and have no comments, send a note to the list >>>>> that the draft is good as it is, we need these notes as much as we ne= ed the >>>>> actual comments. >>>>> >>>>> Thanks, Gabor >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>> >>>> >>>> >>>> >>>> -- >>>> -vince >>>> >>>> >>>> >>> >>> >>> -- >>> -vince >>> >>> >>> Regards, >>> Sungjin >>> >>> >> >> >> -- >> -vince >> >> >> > > > -- > -vince > > > --=20 -vince --001a11c2e352823dc804e2438442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sungjin, All,

Actually, the max power m= ust be associated with each available-frequency range, since it can be diff= erent
for different ranges.

The list of = {startHz, stopHz, maxPowerDBm} "roughly" defines a spectral mask.= So there might be one
for wide-band and a different mask for narrow band operations.

There was a question, though, of whether the "mask&q= uot; should be encoded differently, e.g.,

Option 1= : List of {startHz, maxStartPowerDBm, stopHz, maxStopPowerDBm}

Option 2: List of {frequencyHz, maxPowerDBm} sorted by = frequencyHz

Does anyone have any thoughts on this?=

-vince


On Wed, Jul 24, 2013 at 12:24 AM, Sungjin Yo= o <sjyou@etri.re.kr> wrote:
=20 =20 =20
Vince and all,

Thanks for the explanation.
I understand what you mean.

I think current encoding format may cause a misunderstanding. Because maximum power informations for the same frequency may be distributed to multiple object. I think it's clearer if "bandwidth" is coupled with "maxPowerDBm".

How about the following format?

       "=
;spectra": [
         {
          "maxPower":[
	    {"bandwidthHz":6e6, "maxPowerDBm":30.0},
            {"bandwidthHz":1e5, "maxPowerDBm":27.0}
          ]
         =C2=A0"frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8},
            ...
          ]

Regards,
Sungjin


On 07/24/2013 11:14 AM, Vincent Chen wrote:
=20
Sungjin,

Sorry for the delay and the confusion.

Assuming we have the response that contains:

       &=
quot;spectra": [
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":27.0},
            ...
          ]
         }

This specifies that the frequencies in the range [518MHz, 536MHz) are available, and the device must satisfy two conditions:

=C2=A0- Within any 6MHz in that range, total power may not exceed 30.0 dBm
AND
=C2=A0- Within any 100kHz in that range, total power may not exceed 27 dBm

In this example, it means that the device may fit two 100kHz "sub-channels" at 27dBm within any 6MHz channel.=

(There are many other possibilities.)

Does this make sense? If so, I'll update the draft to make this more clear.

Thanks.

-vince
=C2=A0=C2=A0


On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
Vince,

Comment is in line.


On 07/19/2013 02:17 PM, Vincent Chen wrote:
Sunglin,

Some clarification: The maxPowerDbm is total power. It is not a spectral density.

I agree. But (maxPowerDBm / bandwidth) defines the spectral density.


Thus, if a 6MHz channel is available, the Device may choose to put, say, ten 100kHz sub-channels within that channel.
The total power summed over those 10 sub-channels cannot exceed 27dBm.

So here is one way the Device may use the response.
=C2=A0- The Device determines first if it wants = to be a narrow band (1e5) or wideband (6e6) device
=C2=A0- It selects the Spectrum specification, based on its mode

I think "bandwidth" parameter does not limit the op= eration bandwidth of the device, it is just reference bandwidth to define permissible power levels and that is equivalent to define spectral density. I think "maxContiguousBwHz"= ; parameter(4.4.2)=C2=A0 limit the operation bandwidth, and "bandwidth" parameter does not.

I understand the "bandwidth" parameter from followi= ng paragraphs.

4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as computed from the start and stop frequencies) MAY be different from the"bandwidth" value.

5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the maximum permitted EIRP spectral density."
4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY return a constraint on the maximum contiguous bandwidth (in Hertz) allowed."




-vince


On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo <sjyou@etri.re.kr> wrote:
Vince,

Comment is in line.


On 07/19/2013 10:16 AM, Vincent Chen wrote:
Sungjin,


On Mon, Jul 15, 2013 at 6:02 PM, Sungjin <sjyou@e= tri.re.kr> wrote:
Vince,

I understand "bandwidth&qu= ot; parameter is just for defining permissible power or spectral density and
it dose not represent the operation bandwidth. (see 4.4.5. SPECTRUC_USE_NOTIFY, 'spectra' parameter description)
If I misunderstand, please correct me.

Oh, I understand what you're saying. The example does not make sure the math works out to be equivalent.
I thought, though, some regulators actually wants different power spectral density for narrow band, so it's not always
guaranteed to be the same.

If master device receive the message in the example, it will be confused. Assume the master device decides to use the spectrum from 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. Then the master device may be confused to interpret permissible maximum power. First one in the example represents 30.0 dBm, but second one represents about 44.78 dBm(=3D27dBm + 17.78dB). The master device don't know whic= h one is correct.
So I think it will be clear if "frequencyRanges" in the second one(f= or "bandwidth" : 1e5) is modified to dif= ferent frequency from first one(for "bandwidth&qu= ot; : 1e5)


And I found another typos.
"jsonrpc": "2.= 0", should be added to all examples.

Thanks. I will incorporate this.
=C2=A0

Regards,
Sungjin


On 07/16/2013 06:56 AM, Vincent Chen wrote:
Sungjin,

Sorry for the long delay (vacation). Answers inline.


On Sun, Jun 30, 2013 at 10:30 PM, =EC=9C=A0=EC=84= =B1=EC=A7=84 <sjyou@etri.re.kr> wrote:
Hi All,

I have found two typos.

At example "getSpectrum= " JSON-RPC in 6.4.1. :
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 "id": "xxxxxx"= ;, =C2=A0 =C2=A0 --> Comma should be deleted.
At example "getSpectrum= Batch" JSON-RPC in 6.5.1. :
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 "id": "xxxxxx"= ;, =C2=A0 =C2=A0 --> Comma should be deleted.

Thanks!
=C2=A0


I have a comment about example "getSpectrum= " JSON-RPC response in 6.4.2 and 6.5.2.
There are two spectrum information parameters =C2=A0for the sam= e frequency range.
One is for bandwidth 6e6, and the other is for bandwidth 1e5. But spectral density of 6e6 is different from that of 1e5 in the same frequency range.
It will be more nice if the spectral density of the same frequency range is same. Or it will be also nice if frequency ranges are modified to be different from each other.

This is intended to represent the permissible maximum power in which "wide-band&q= uot; and "narrow-band= " operations are permitted.
The available frequencies do not change (hence, the same start/stop frequencies), just the permissible power.

Does that make sense?

-vince



Thank you.

BR,
Sungjin


-----Original Message-----
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.co= m
Sent: Thursday, June 20, 2013 2:18 AM
To: paws@ietf.org
Subject: [paws] WGLC on http://= tools.ietf.org/html/draft-ietf-paws-protocol-06


All,

The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of.
Therefore, I'= d like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document.

Please read through the draft and send any comments you may have to the list in the next 2-3 weeks.
If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments.

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



--
-vince




--
-vince

Regards,
Sungjin




--
-vince




--
-vince




--
-vince
--001a11c2e352823dc804e2438442-- From vchen@google.com Wed Jul 24 10:38:17 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 DA8D511E8104 for ; Wed, 24 Jul 2013 10:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.335 X-Spam-Level: X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 s1UaDBB9voUB for ; Wed, 24 Jul 2013 10:38:17 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id C2CDC11E80F8 for ; Wed, 24 Jul 2013 10:38:16 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 1so1907916qec.36 for ; Wed, 24 Jul 2013 10:38:07 -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=ORsrJkBIKAlpIK42Zk/6bZql6N+wazaBGH6Mvn3CDE4=; b=I2JIK8fneSQFrPMPqj97/KOV16qpQ4j0PhV3YlfEilWm0BtueyYjcN76KudM4fTGF0 mRzwdqI0/ouYz5oDdyaqFDtspsBE81+4PWCP5hesxo/CXCa2yEQGuhjfTV1vACVpFiYH W70EFibClLI/2zs26uT+RDMAw1alMy5PLSINpwl1VG3jCxvgMySi8k0RHhC20XjYngCr F0gSh/uOAzsTi56TZ8yexa7Hjw6Kr+b/EFYhDmAkVff1XZSw+Knxw61ARSta+c5P1XDW xjYQMhsOGVYR76SBARCUqXVJOsN7oYK0UuCbEjbm85rYB5SlhKvI4j1N9fWMY+5mmiUL Bu4w== X-Google-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:x-gm-message-state; bh=ORsrJkBIKAlpIK42Zk/6bZql6N+wazaBGH6Mvn3CDE4=; b=RxE4uYsp7JNWf4pu2QWUePerOOhaQ1BH7QxgxYR0Bi2Ag8f5oW58ISwfEIqBi+OInH Y+9qP/GDRztv1a19XTTSrA1PY/sfJywELLgzsUQXuDQ6y1MDCz6r/578LXHKXtuz+t83 NXx7gCsLw8EagmPRrz050Aa3qS4VqNAWJGxdFqyYieeRUfR8s9elzL3xCbLwp7H4ZAOz ax1FqLNtsIhLIgsnJRRbyoz+V9r581XOCKdUcy/6tXUBI0eO1sBK7rQ6acMj+pmej25n Uuc8jIBKWZPEjd+MqLJvre5/4nO9/U+HZRXhGmmlznnqKvfpe0+sRvEPdHvpSKUwfAYS 3feg== MIME-Version: 1.0 X-Received: by 10.224.169.3 with SMTP id w3mr13292191qay.13.1374687487122; Wed, 24 Jul 2013 10:38:07 -0700 (PDT) Received: by 10.229.161.80 with HTTP; Wed, 24 Jul 2013 10:38:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 10:38:07 -0700 Message-ID: From: Vincent Chen To: Michael Head Content-Type: multipart/alternative; boundary=089e011823a258ff2f04e2455fc9 X-Gm-Message-State: ALoCoQktvoHyoj29TDgZ9bc+qenMYZAXonRUhgrickifBCvEPoEoi8ANUJ13M77T8SE9/+QIzELbjnyG7YFIyvf1vtS3NH0ZJH1AyTQpAeB53GdmXx7rXphBU/yiH9pBRjclP06wWMAU39j0merdiu/wDZBKnQsM6s25Bmsq2u3rNmriWVBca/1TUpTVs32f3t8caleqkQzI Cc: "paws@ietf.org" Subject: Re: [paws] Supporting multiple authorities / rulesets in a PAWS response? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:38:18 -0000 --089e011823a258ff2f04e2455fc9 Content-Type: text/plain; charset=ISO-8859-1 Mike, Ah, good point. To support responses for multiple rulesets requires additional layering of the response. This seems to be a relatively slight modification to the AVAIL_SPECTRUM_RESP (and associated batch response) to have a list of (rulesetInfo, SpectrumSchedule list) objects. Does that sound right? All, should I update the response message to support this? -vince On Wed, Jul 24, 2013 at 2:44 AM, Michael Head wrote: > From my reading, a device can only get information about spectrum under a > single ruleset at a time. (I suppose there is one way around this if a > device opts to skip the Init operation and the database opts not to include > the rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in > the spirit of the protocol). > > Now, there may be multiple rulesets that govern a particular location. For > example, in disputed territories where two governments claim authority (or > even just near an undisputed border, the device may want/need to know the > spectrum available on both sides of the border). > > Even within a particular domain, there may be different rulesets governing > different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices > might be built to support both and may need to consult a database to get > information about all bands. > > What should devices and databases do? I suppose it can be done by having > the device send multiple, independent querys. In the first case, it would > send a spectrum request with a DeviceDescriptor with a restricted set of > ruleset ids to cover the regulatory domains it cares about (but then, how > would it know which domains are useful at a given lat/lon?). For the second > case, the device could fire separate requests with DeviceCapabilities set > to cover the different bands it supports, which seems a little more > workable. Still, it would be nice if these could be handled in a single > request/response. > > Furthermore, certain databases might want to give additional information > about spectrum at a location, but the spec doesn't have a standard way of > allowing for that. Of course, the database is free to add any fields, > anywhere it likes, but it would be nice if there were a structured way to > allow a PAWS response to include independent spectrum reports. > > -- mike > > > -- > ---------------------------------- > 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 > > -- -vince --089e011823a258ff2f04e2455fc9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mike,

Ah, good point. To support respon= ses for multiple rulesets requires additional layering of the response.

This seems to be a relatively slight modification to = the AVAIL_SPECTRUM_RESP (and associated batch response)
to have a list of (rulesetInfo, SpectrumSchedule list) objects.
<= div>
Does that sound right?

All, sho= uld I update the response message to support this?

-vince


On Wed, Jul 24, 2013 at 2:44 AM, Michael Head &= lt;mrhead@google.com= > wrote:
From my reading, a device c= an only get information about spectrum under a single ruleset at a time. (I= suppose there is one way around this if a device opts to skip the Init ope= ration and the database opts not to include the rulesetInfo in the AvailSpe= ctrumResp, but that doesn't seem to be in the spirit of the protocol).<= div>
Now, there may be multiple rulesets that govern a particular= location. For example, in disputed territories where two governments claim= authority (or even just near an undisputed border, the device may want/nee= d to know the spectrum available on both sides of the border).=A0

Even within a particular domain, there may be different= rulesets governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5g= hz bands). Devices might be built to support both and may need to consult a= database to get information about all bands.

What should devices and databases do? I suppose it can = be done by having the device send multiple, independent querys. In the firs= t case, it would send a spectrum request with a DeviceDescriptor with a res= tricted set of ruleset ids to cover the regulatory domains it cares about (= but then, how would it know which domains are useful at a given lat/lon?). = For the second case, the device could fire separate requests with DeviceCap= abilities set to cover the different bands it supports, which seems a littl= e more workable. =A0Still, it would be nice if these could be handled in a = single request/response.

Furthermore, certain databases might want to give addit= ional information about spectrum at a location, but the spec doesn't ha= ve a standard way of allowing for that. Of course, the database is free to = add any fields, anywhere it likes, but it would be nice if there were a str= uctured way to allow a PAWS response to include independent spectrum report= s.

-- mike


--
-------------------= ---------------
Michael R= Head <mrhead@goo= gle.com>
+1-201-BLISTER

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




--
-vince
--089e011823a258ff2f04e2455fc9-- From vchen@google.com Wed Jul 24 10:51:15 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 C4FAB11E80F8 for ; Wed, 24 Jul 2013 10:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.275 X-Spam-Level: X-Spam-Status: No, score=-1.275 tagged_above=-999 required=5 tests=[AWL=-0.181, 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 kcrkYztGL7kX for ; Wed, 24 Jul 2013 10:51:14 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61811E80F9 for ; Wed, 24 Jul 2013 10:51:13 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bq6so100597qab.11 for ; Wed, 24 Jul 2013 10:51:12 -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=uTt2d+fgwrYtwcNhQMunB6/Bb80vA1v7lXCEXMx7N8I=; b=E7Ljntt3HYzljWN6ybxs1IgLU7Ha9vBltUNHw81iq5aLoHzjfRUnOUx9ATRmObZw5w 3pqnLHlCMgjQSWQMx9W8PF4QXPWjQGTorn0qjaw2RZA1YwE1j3plP7jHNPSQSXC5malC 40svCHBz6Z0zlDtOAmLbDwi/vBml6o1zTKFs0NXvuaV/cEY98r4g9lCVqLtxU1qTZPAL OvprqXKvFHpCYMPl/LlvY/xJlcmjXRjv8HeQpWsW7tnk4FeMp+iwVxbTR4VS5eip1fTc MjO7hP30Bg4rL9iL+41pPRz2l5XYqi1PL56uZlH8GmXLh6ihRbOQUbDx3wJqA7hYfPeQ EYFg== X-Google-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:x-gm-message-state; bh=uTt2d+fgwrYtwcNhQMunB6/Bb80vA1v7lXCEXMx7N8I=; b=A84U7NItKvyrREx3+f4BjhvCl3vGihGU8KvXFnHJHVaU9oGKCxQ2T2ZzgLSuJeCP3L BZPtnfGaqf1N8Fk1ol+WqT8DomSIl7N9dnaip4GxV0NHnjsME3yct7uj0aT2m/DqnFkT zL/pJqSvRhuPw6yj14w263USSKWjEgVSCRseg6znQSbDjjgkWFuW00MpV4k6ByrGcXoY jUK/mN6T2wpDulgKJobyEJKItZPa1JnZybVpWeycQ3VCDVYxZOsHzbAN7BakDDEdKYI6 HSm78F1/oOjJbGDSoeenxGvth4TkP4io4y9O4fN33Uzywi48ymPYf8I5Flbwfupd00Yi my3w== MIME-Version: 1.0 X-Received: by 10.224.115.5 with SMTP id g5mr45996261qaq.53.1374688272471; Wed, 24 Jul 2013 10:51:12 -0700 (PDT) Received: by 10.229.161.80 with HTTP; Wed, 24 Jul 2013 10:51:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Jul 2013 10:51:12 -0700 Message-ID: From: Vincent Chen To: Michael Head Content-Type: multipart/alternative; boundary=047d7bdc95142873be04e2458ef6 X-Gm-Message-State: ALoCoQmf+zLHI0QiYYw9fqtt9LqZZQbKHH1t0a9XSu+gu037TDp1+C2neN+Jz9+GpoSnzljr+fWI1PspJ/aG9NLDWanlETiFHxsYz5Vde9+Cy1gvs+fsevy2wj2xpFOndWg0N4gimQsGMjL0wrTMQ/WYu5+d4Zj7gKIgUKewo6fZbr+FufW/YaY2f7hjArBhar0Ew8KDRO4+ Cc: "paws@ietf.org" Subject: Re: [paws] Supporting multiple authorities / rulesets in a PAWS response? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:51:16 -0000 --047d7bdc95142873be04e2458ef6 Content-Type: text/plain; charset=ISO-8859-1 Actually, something like: +---------------------------------------+ |AVAIL_SPECTRUM_RESP | +----------------------------+----------+ |timestamp:string | required | |deviceDesc:DeviceDescriptor | required | |spectrumSpecs:list | required |----+ |............................|..........| | |location:GeoLocation | optional | | |............................|..........| | |databaseChange:DbUpdateSpec | optional | | |*other:any | depends | | +----------------------------+----------+ | 1..* V +------------------------------------+ | SpectrumSpec | +-------------------------+----------| |spectrumSchedules:list | required |--+ |needsSpectrumReport:bool | optional | | |maxTotalBwHz:float | optional | | |maxContiguousBwHz:float | optional | | |rulesetInfo:RulesetInfo | required | | 0..* +-------------------------+----------+ V +----------------+ |SpectrumSchedule| +----------------+ In this encoding, the rulesetInfo becomes required. Thoughts? -vince On Wed, Jul 24, 2013 at 10:38 AM, Vincent Chen wrote: > Mike, > > Ah, good point. To support responses for multiple rulesets requires > additional layering of the response. > > This seems to be a relatively slight modification to the > AVAIL_SPECTRUM_RESP (and associated batch response) > to have a list of (rulesetInfo, SpectrumSchedule list) objects. > > Does that sound right? > > All, should I update the response message to support this? > > -vince > > > On Wed, Jul 24, 2013 at 2:44 AM, Michael Head wrote: > >> From my reading, a device can only get information about spectrum under a >> single ruleset at a time. (I suppose there is one way around this if a >> device opts to skip the Init operation and the database opts not to include >> the rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in >> the spirit of the protocol). >> >> Now, there may be multiple rulesets that govern a particular location. >> For example, in disputed territories where two governments claim authority >> (or even just near an undisputed border, the device may want/need to know >> the spectrum available on both sides of the border). >> >> Even within a particular domain, there may be different rulesets >> governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). >> Devices might be built to support both and may need to consult a database >> to get information about all bands. >> >> What should devices and databases do? I suppose it can be done by having >> the device send multiple, independent querys. In the first case, it would >> send a spectrum request with a DeviceDescriptor with a restricted set of >> ruleset ids to cover the regulatory domains it cares about (but then, how >> would it know which domains are useful at a given lat/lon?). For the second >> case, the device could fire separate requests with DeviceCapabilities set >> to cover the different bands it supports, which seems a little more >> workable. Still, it would be nice if these could be handled in a single >> request/response. >> >> Furthermore, certain databases might want to give additional information >> about spectrum at a location, but the spec doesn't have a standard way of >> allowing for that. Of course, the database is free to add any fields, >> anywhere it likes, but it would be nice if there were a structured way to >> allow a PAWS response to include independent spectrum reports. >> >> -- mike >> >> >> -- >> ---------------------------------- >> 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 >> >> > > > -- > -vince > -- -vince --047d7bdc95142873be04e2458ef6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually, something like:

=A0 =A0+-------------------------------------= --+
=A0 =A0|AVAIL_SP= ECTRUM_RESP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0+------------------------= ----+----------+
=A0= =A0|timestamp:string =A0 =A0 =A0 =A0 =A0 =A0| required |
= =A0 =A0|deviceDesc:DeviceDescriptor |= required |
=A0 =A0|spectrumSpecs:list =A0 = =A0 =A0 =A0 =A0| required |----+
=A0 =A0|............................|...= .......| =A0 =A0|
=A0 =A0|location:GeoLocati= on =A0 =A0 =A0 =A0| optional | =A0 =A0|
=A0 =A0|............................|..........| =A0 = =A0|
=A0 =A0|databas= eChange:DbUpdateSpec | optional | =A0 =A0|
=A0 =A0|*other:any =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0| depends =A0| =A0 =A0|
=A0 =A0+----------------------------+----------= + =A0 =A0| 1..*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 V
<= div>=A0 =A0 =A0 =A0 =A0 =A0 =A0+-----= -------------------------------+
=A0 =A0 =A0 =A0 =A0 =A0 =A0| SpectrumSpec =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0+----= ---------------------+----------|
=A0 =A0 =A0 =A0 =A0 =A0 =A0|spectrumSchedules:list =A0 |= required |--+
=A0 =A0 =A0 =A0 =A0 =A0 =A0|needsSpec= trumReport:bool | optional | =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0|maxTotalBwHz:float =A0 =A0 =A0 | = optional | =A0|
=A0 = =A0 =A0 =A0 =A0 =A0 =A0|maxContiguousBwHz:float =A0| optional | =A0|=
=A0 =A0 =A0 =A0 =A0 =A0 =A0|rule= setInfo:RulesetInfo =A0| required | =A0| 0..*
=A0 =A0 =A0 =A0 =A0 =A0 =A0+---------------= ----------+----------+ =A0V
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|SpectrumSchedul= e|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+----------------+

In this encoding, the rulesetInfo becomes required.
Thoughts?

-vince


On Wed, Jul 24, 2013 at 10:38 = AM, Vincent Chen <vchen@google.com> wrote:
Mike,

Ah= , good point. To support responses for multiple rulesets requires additiona= l layering of the response.

This seems to be a relatively slight modification to th= e AVAIL_SPECTRUM_RESP (and associated batch response)
to have a list of (rulesetInfo, SpectrumSchedule list) objects.
<= div>
Does that sound right?

All, sho= uld I update the response message to support this?

-vince


On Wed, Jul 24, 2013 at 2:44 AM, Michael H= ead <mrhead@google.com> wrote:
From my reading, a device can only get information about spectrum = under a single ruleset at a time. (I suppose there is one way around this i= f a device opts to skip the Init operation and the database opts not to inc= lude the rulesetInfo in the AvailSpectrumResp, but that doesn't seem to= be in the spirit of the protocol).

Now, there may be multiple rulesets that govern a particular= location. For example, in disputed territories where two governments claim= authority (or even just near an undisputed border, the device may want/nee= d to know the spectrum available on both sides of the border).=A0

Even within a particular domain, there may be different= rulesets governing different shared spectrum bands (TVWS vs. 3.5 ghz or 5g= hz bands). Devices might be built to support both and may need to consult a= database to get information about all bands.

What should devices and databases do? I suppose it can = be done by having the device send multiple, independent querys. In the firs= t case, it would send a spectrum request with a DeviceDescriptor with a res= tricted set of ruleset ids to cover the regulatory domains it cares about (= but then, how would it know which domains are useful at a given lat/lon?). = For the second case, the device could fire separate requests with DeviceCap= abilities set to cover the different bands it supports, which seems a littl= e more workable. =A0Still, it would be nice if these could be handled in a = single request/response.

Furthermore, certain databases might want to give addit= ional information about spectrum at a location, but the spec doesn't ha= ve a standard way of allowing for that. Of course, the database is free to = add any fields, anywhere it likes, but it would be nice if there were a str= uctured way to allow a PAWS response to include independent spectrum report= s.

-- mike


--
----------------------------------
Michael R= Head <mrhead@goo= gle.com>
+1-201-BLISTER

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


<= br clear=3D"all">

--
-vince



--
-vince --047d7bdc95142873be04e2458ef6-- From dharasty@appcomsci.com Wed Jul 24 11:10:38 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 A62CE11E8213 for ; Wed, 24 Jul 2013 11:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 a4yNyQ8pA5eD for ; Wed, 24 Jul 2013 11:10:33 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1E14711E8125 for ; Wed, 24 Jul 2013 11:10:29 -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 r6OIARnw029994; Wed, 24 Jul 2013 14:10:27 -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 r6OIARar005487; Wed, 24 Jul 2013 14:10:27 -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; Wed, 24 Jul 2013 14:10:27 -0400 From: "Harasty, Daniel J" To: Vincent Chen , Michael Head Thread-Topic: [paws] Supporting multiple authorities / rulesets in a PAWS response? Thread-Index: AQHOiFJ92OTHCRGm4EinfQ8Zz8z+q5l0W4aA//++ZNA= Date: Wed, 24 Jul 2013 18:10:26 +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_EC510C021D06A34C92F5A5A488B5290B0CEEE7C5rrcatsexmb2atsa_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Supporting multiple authorities / rulesets in a PAWS response? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 18:10:38 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEE7C5rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PAWS concept of "rulesets" seems to be principally based on the idea th= at different locations might have a specific "ruleset" (singular) that appl= ies. Like Mike, I have wondered if this is laying the groundwork for PAWS = to handle multiple "rulesets" (plural) at a particular location. I think we should tease out TWO separate impacts if that is expected (or at= least allowed): * If a Device doesn't know which of its supported rulesets apply at= a given location, should we support a way for the Database to inform the D= evice? o Actually we need the overlap of THREE sets: rulesets supported by the D= evice, rulesets allowed (by the regulatory authority) at this location, and= the rulesets supported by the Database. o Thus, this seems like a natural "extension" to the "ruleset negotiation= " we contemplated in an early email. Maybe this should be handled at INIT_= REQ time? * If multiple rulesets are allowed at a given location, should we s= upport a way to make a SINGLE AVAIL_SPECTRUM_REQ to get both? o That sounds logical, and not too difficult to define in the spec.... o .... however, I'd like to not "force" the implementation on the Databas= e that it must implement "all rulesets for a given location on every server= that supports that location." o Said other way: I think a Database should be allowed to implement diffe= rent rulesets at different URLs, and use the redirect mechanism to get spec= ific AVAIL_SPECTRUM_REQs (with a specific ruleset) to the "right" server in= stance in its federation. o Can we adapt PAWS to accommodate this? It is tricky: how would a serve= r instance "half reply" to a message, yet "half redirect" it? o If this is too difficult to specify, then I'd suggest we simply stick w= ith the model that AVAIL_SPECTRUM_REQs only contain one "ruleset" at a time= , and the device send independent ones. I think the downsides are pretty s= light. One more comment: I'm 100% comfortable sidestepping the possibility that "m= ultiple authorities may claim authority at a given location". I'm fine if = PAWS has the model "one location, one authority". - Dan Harasty From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Wednesday, July 24, 2013 1:38 PM To: Michael Head Cc: paws@ietf.org Subject: Re: [paws] Supporting multiple authorities / rulesets in a PAWS re= sponse? Mike, Ah, good point. To support responses for multiple rulesets requires additio= nal layering of the response. This seems to be a relatively slight modification to the AVAIL_SPECTRUM_RES= P (and associated batch response) to have a list of (rulesetInfo, SpectrumSchedule list) objects. Does that sound right? All, should I update the response message to support this? -vince On Wed, Jul 24, 2013 at 2:44 AM, Michael Head > wrote: >From my reading, a device can only get information about spectrum under a s= ingle ruleset at a time. (I suppose there is one way around this if a devic= e opts to skip the Init operation and the database opts not to include the = rulesetInfo in the AvailSpectrumResp, but that doesn't seem to be in the sp= irit of the protocol). Now, there may be multiple rulesets that govern a particular location. For = example, in disputed territories where two governments claim authority (or = even just near an undisputed border, the device may want/need to know the s= pectrum available on both sides of the border). Even within a particular domain, there may be different rulesets governing = different shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices m= ight be built to support both and may need to consult a database to get inf= ormation about all bands. What should devices and databases do? I suppose it can be done by having th= e device send multiple, independent querys. In the first case, it would sen= d a spectrum request with a DeviceDescriptor with a restricted set of rules= et ids to cover the regulatory domains it cares about (but then, how would = it know which domains are useful at a given lat/lon?). For the second case,= the device could fire separate requests with DeviceCapabilities set to cov= er the different bands it supports, which seems a little more workable. St= ill, it would be nice if these could be handled in a single request/respons= e. Furthermore, certain databases might want to give additional information ab= out spectrum at a location, but the spec doesn't have a standard way of all= owing for that. Of course, the database is free to add any fields, anywhere= it likes, but it would be nice if there were a structured way to allow a P= AWS response to include independent spectrum reports. -- mike -- ---------------------------------- 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 -- -vince --_000_EC510C021D06A34C92F5A5A488B5290B0CEEE7C5rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The PAWS = concept of “rulesets” seems to be principally based on the idea= that different locations might have a specific “ruleset” (sing= ular) that applies.  Like Mike, I have wondered if this is laying the = groundwork for PAWS to handle multiple “rulesets” (plural) at a= particular location.

 

I think we should tease= out TWO separate impacts if that is expected (or at least allowed):

 

·         If a Device doesn’t know which of= its supported rulesets apply at a given location, should we support a way = for the Database to inform the Device?

o   = Actually we need the overlap of THREE sets: rulesets supported by th= e Device, rulesets allowed (by the regulatory authority) at this location, = and the rulesets supported by the Database.

o   Thus, this seems like a natural “extension” to th= e “ruleset negotiation” we contemplated in an early email. = ; Maybe this should be handled at INIT_REQ time?

 

·         <= ![endif]>If multiple rulesets are allowed at a given location, shoul= d we support a way to make a SINGLE AVAIL_SPECTRUM_REQ to get both?

o   That sounds logical, and not too diffic= ult to define in the spec….

o   …. however, I’d like to not “force” the implement= ation on the Database that it must implement “all rulesets for a give= n location on every server that supports that location.”  <= /o:p>

o   = Said other way: I think a Database sh= ould be allowed to implement different rulesets at different URLs, and use = the redirect mechanism to get specific AVAIL_SPECTRUM_REQs (with a specific= ruleset) to the “right” server instance in its federation.

o &n= bsp; Can we adapt PAWS to accommodate= this?  It is tricky: how would a server instance “half reply= 221; to a message, yet “half redirect” it?

o   <= /span>If this is too difficult to specify, then I’d = suggest we simply stick with the model that AVAIL_SPECTRUM_REQs only contai= n one “ruleset” at a time, and the device send independent ones= .  I think the downsides are pretty slight.

 

One more comment: I’m 100% comfortable sidestepping the possibili= ty that “multiple authorities may claim authority at a given location= ”.  I’m fine if PAWS has the model “one location, on= e authority”.

 

- Dan Harasty

 

 

F= rom: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf O= f Vincent Chen
Sent: Wednesday, July 24, 2013 1:38 PM
T= o: Michael Head
Cc: paws@ietf.org
Subject: Re: [paw= s] Supporting multiple authorities / rulesets in a PAWS response?

 

Mike,

 

Ah, good point. To support responses f= or multiple rulesets requires additional layering of the response.

 

This seems to be a relatively slight modification to the AV= AIL_SPECTRUM_RESP (and associated batch response)

=

to have a list of (rulesetInfo, SpectrumSchedule list)= objects.

 

Does that sound right?

 

All, should I update the response message to support this?=

 

-vince

 

On Wed, Jul 24, 2013 at 2:44 AM, Michael Head <mrhead@google.com> wrote:<= /p>

From my reading, a device can only get informa= tion about spectrum under a single ruleset at a time. (I suppose there is o= ne way around this if a device opts to skip the Init operation and the data= base opts not to include the rulesetInfo in the AvailSpectrumResp, but that= doesn't seem to be in the spirit of the protocol).

 

Now, = there may be multiple rulesets that govern a particular location. For examp= le, in disputed territories where two governments claim authority (or even = just near an undisputed border, the device may want/need to know the spectr= um available on both sides of the border). 

<= p class=3DMsoNormal> 

Ev= en within a particular domain, there may be different rulesets governing di= fferent shared spectrum bands (TVWS vs. 3.5 ghz or 5ghz bands). Devices mig= ht be built to support both and may need to consult a database to get infor= mation about all bands.

=  

What should devices and dat= abases do? I suppose it can be done by having the device send multiple, ind= ependent querys. In the first case, it would send a spectrum request with a= DeviceDescriptor with a restricted set of ruleset ids to cover the regulat= ory domains it cares about (but then, how would it know which domains are u= seful at a given lat/lon?). For the second case, the device could fire sepa= rate requests with DeviceCapabilities set to cover the different bands it s= upports, which seems a little more workable.  Still, it would be nice = if these could be handled in a single request/response.

 

Furthermore, certain databases might want to give additional informati= on about spectrum at a location, but the spec doesn't have a standard way o= f allowing for that. Of course, the database is free to add any fields, any= where it likes, but it would be nice if there were a structured way to allo= w a PAWS response to include independent spectrum reports.

 

-- mike

 

 

--

<= div>

----------------------------------

Michael R Head <mrhead@google.com>

+1-201-BLISTER


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


 

--
-vince

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEE7C5rrcatsexmb2atsa_-- From Peter.McCann@huawei.com Wed Jul 24 11:20: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 0ACF411E8125 for ; Wed, 24 Jul 2013 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 Xg2iBYQnNk9m for ; Wed, 24 Jul 2013 11:20:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 15C2511E824B for ; Wed, 24 Jul 2013 11:20:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ76690; Wed, 24 Jul 2013 18:20:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 19:19:53 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 19:20:06 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 11:20:04 -0700 From: Peter McCann To: Vincent Chen , Sungjin Yoo Thread-Topic: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Thread-Index: AQHOiBOWuZSEO1ueIkGBEQLTEDamMJl0JIfg Date: Wed, 24 Jul 2013 18:20:03 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F5075B@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> <51E8D65A.5030500@etri.re.kr> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.91] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 18:20:18 -0000 RG8gd2UgbmVlZCB0byB0YWxrIGFib3V0IHRoZSBzbG9wZSBvZiB0aGUgZmlsdGVyIG1hc2sgdGhh dCBjYXBzIHRoZQ0Kb3V0LW9mLWJhbmQgZW1pc3Npb25zPw0KDQotUGV0ZQ0KDQoNClZpbmNlbnQg Q2hlbiB3cm90ZToNCj4gU3VuZ2ppbiwNCj4gDQo+IFNvcnJ5IGZvciB0aGUgZGVsYXkgYW5kIHRo ZSBjb25mdXNpb24uDQo+IA0KPiBBc3N1bWluZyB3ZSBoYXZlIHRoZSByZXNwb25zZSB0aGF0IGNv bnRhaW5zOg0KPiANCj4gDQo+ICAgICAgICAic3BlY3RyYSI6IFsNCj4gICAgICAgICAgew0KPiAg ICAgICAgICAgImJhbmR3aWR0aCI6IDZlNiwNCj4gICAgICAgICAgICJmcmVxdWVuY3lSYW5nZXMi OiBbDQo+ICAgICAgICAgICAgIHsic3RhcnRIeiI6NS4xOGU4LCAic3RvcEh6Ijo1LjM2ZTgsICJt YXhQb3dlckRCbSI6MzAuMH0sDQo+ICAgICAgICAgICAgIC4uLg0KPiAgICAgICAgICAgXQ0KPiAg ICAgICAgICB9LA0KPiAgICAgICAgICB7DQo+ICAgICAgICAgICAiYmFuZHdpZHRoIjogMWU1LA0K PiAgICAgICAgICAgImZyZXF1ZW5jeVJhbmdlcyI6IFsNCj4gICAgICAgICAgICAgeyJzdGFydEh6 Ijo1LjE4ZTgsICJzdG9wSHoiOjUuMzZlOCwgIm1heFBvd2VyREJtIjoyNy4wfSwNCj4gICAgICAg ICAgICAgLi4uDQo+ICAgICAgICAgICBdDQo+ICAgICAgICAgIH0NCj4gVGhpcyBzcGVjaWZpZXMg dGhhdCB0aGUgZnJlcXVlbmNpZXMgaW4gdGhlIHJhbmdlIFs1MThNSHosIDUzNk1IeikgYXJlIA0K PiBhdmFpbGFibGUsIGFuZCB0aGUgZGV2aWNlIG11c3Qgc2F0aXNmeSB0d28gY29uZGl0aW9uczoN Cj4gDQo+ICAtIFdpdGhpbiBhbnkgNk1IeiBpbiB0aGF0IHJhbmdlLCB0b3RhbCBwb3dlciBtYXkg bm90IGV4Y2VlZCAzMC4wIGRCbSAgDQo+IEFORCAtIFdpdGhpbiBhbnkgMTAwa0h6IGluIHRoYXQg cmFuZ2UsIHRvdGFsIHBvd2VyIG1heSBub3QgZXhjZWVkIDI3IA0KPiBkQm0gSW4gdGhpcyBleGFt cGxlLCBpdCBtZWFucyB0aGF0IHRoZSBkZXZpY2UgbWF5IGZpdCB0d28gMTAwa0h6ICJzdWItIA0K PiBjaGFubmVscyIgYXQgMjdkQm0gd2l0aGluIGFueSA2TUh6IGNoYW5uZWwuDQo+IA0KPiAoVGhl cmUgYXJlIG1hbnkgb3RoZXIgcG9zc2liaWxpdGllcy4pDQo+IA0KPiBEb2VzIHRoaXMgbWFrZSBz ZW5zZT8gSWYgc28sIEknbGwgdXBkYXRlIHRoZSBkcmFmdCB0byBtYWtlIHRoaXMgbW9yZSANCj4g Y2xlYXIuDQo+IA0KPiBUaGFua3MuDQo+IA0KPiAtdmluY2UNCj4gDQo+IA0KPiANCj4gT24gVGh1 LCBKdWwgMTgsIDIwMTMgYXQgMTE6MDIgUE0sIFN1bmdqaW4gWW9vIDxzanlvdUBldHJpLnJlLmty PiB3cm90ZToNCj4gDQo+IA0KPiAJVmluY2UsDQo+IA0KPiAJQ29tbWVudCBpcyBpbiBsaW5lLg0K PiANCj4gDQo+IA0KPiAJT24gMDcvMTkvMjAxMyAwMjoxNyBQTSwgVmluY2VudCBDaGVuIHdyb3Rl Og0KPiANCj4gDQo+IAkJU3VuZ2xpbiwNCj4gDQo+IAkJU29tZSBjbGFyaWZpY2F0aW9uOiBUaGUg bWF4UG93ZXJEYm0gaXMgdG90YWwgcG93ZXIuIEl0IGlzIG5vdCBhIA0KPiBzcGVjdHJhbCBkZW5z aXR5Lg0KPiANCj4gDQo+IAlJIGFncmVlLiBCdXQgKG1heFBvd2VyREJtIC8gYmFuZHdpZHRoKSBk ZWZpbmVzIHRoZSBzcGVjdHJhbCBkZW5zaXR5Lg0KPiANCj4gDQo+IA0KPiAJCVRodXMsIGlmIGEg Nk1IeiBjaGFubmVsIGlzIGF2YWlsYWJsZSwgdGhlIERldmljZSBtYXkgY2hvb3NlIHRvIHB1dCwN Cj4gc2F5LCB0ZW4gMTAwa0h6IHN1Yi1jaGFubmVscyB3aXRoaW4gdGhhdCBjaGFubmVsLiAJCVRo ZSB0b3RhbCBwb3dlcg0KPiBzdW1tZWQgb3ZlciB0aG9zZSAxMCBzdWItY2hhbm5lbHMgY2Fubm90 IGV4Y2VlZCAyN2RCbS4NCj4gDQo+IA0KPiAJCVNvIGhlcmUgaXMgb25lIHdheSB0aGUgRGV2aWNl IG1heSB1c2UgdGhlIHJlc3BvbnNlLg0KPiAJCSAtIFRoZSBEZXZpY2UgZGV0ZXJtaW5lcyBmaXJz dCBpZiBpdCB3YW50cyB0byBiZSBhIG5hcnJvdyBiYW5kICgxZTUpIA0KPiBvciB3aWRlYmFuZCAo NmU2KSBkZXZpY2UNCj4gCQkgLSBJdCBzZWxlY3RzIHRoZSBTcGVjdHJ1bSBzcGVjaWZpY2F0aW9u LCBiYXNlZCBvbiBpdHMgbW9kZQ0KPiANCj4gDQo+IAlJIHRoaW5rICJiYW5kd2lkdGgiIHBhcmFt ZXRlciBkb2VzIG5vdCBsaW1pdCB0aGUgb3BlcmF0aW9uIGJhbmR3aWR0aCANCj4gb2YgdGhlIGRl dmljZSwgaXQgaXMganVzdCByZWZlcmVuY2UgYmFuZHdpZHRoIHRvIGRlZmluZSBwZXJtaXNzaWJs ZSANCj4gcG93ZXIgbGV2ZWxzIGFuZCB0aGF0IGlzIGVxdWl2YWxlbnQgdG8gZGVmaW5lIHNwZWN0 cmFsIGRlbnNpdHkuIEkgDQo+IHRoaW5rICJtYXhDb250aWd1b3VzQndIeiIgcGFyYW1ldGVyKDQu NC4yKSAgbGltaXQgdGhlIG9wZXJhdGlvbiANCj4gYmFuZHdpZHRoLCBhbmQgImJhbmR3aWR0aCIg cGFyYW1ldGVyIGRvZXMgbm90Lg0KPiANCj4gCUkgdW5kZXJzdGFuZCB0aGUgImJhbmR3aWR0aCIg cGFyYW1ldGVyIGZyb20gZm9sbG93aW5nIHBhcmFncmFwaHMuDQo+IA0KPiAJNC40LjUuIFNQRUNU UlVNX1VTRV9OT1RJRlksICJUaGUgYWN0dWFsIGJhbmR3aWR0aCB0byBiZSB1c2VkIChhcyANCj4g Y29tcHV0ZWQgZnJvbSB0aGUgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMpIE1BWSBiZSBkaWZm ZXJlbnQgZnJvbSANCj4gdGhlImJhbmR3aWR0aCIgdmFsdWUuDQo+IA0KPiAJNS40LiBGcmVxdWVu Y3lSYW5nZSwgIk5PVEU6IChtYXhQb3dlckRCbSAvIGJhbmR3aWR0aCkgZGVmaW5lcyB0aGUgDQo+ IG1heGltdW0gcGVybWl0dGVkIEVJUlAgc3BlY3RyYWwgZGVuc2l0eS4iDQo+IA0KPiAJNC40LjIu IEFWQUlMX1NQRUNUUlVNX1JFU1AsICJtYXhDb250aWd1b3VzQndIejogVGhlIERhdGFiYXNlIE1B WSANCj4gcmV0dXJuIGEgY29uc3RyYWludCBvbiB0aGUgbWF4aW11bSBjb250aWd1b3VzIGJhbmR3 aWR0aCAoaW4gSGVydHopIGFsbG93ZWQuIg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IAkJLXZpbmNl DQo+IA0KPiANCj4gCQlPbiBUaHUsIEp1bCAxOCwgMjAxMyBhdCA5OjQ5IFBNLCBTdW5namluIFlv byA8c2p5b3VAZXRyaS5yZS5rcj4gd3JvdGU6DQo+IA0KPiANCj4gCQkJVmluY2UsDQo+IA0KPiAJ CQlDb21tZW50IGlzIGluIGxpbmUuDQo+IA0KPiANCj4gCQkJT24gMDcvMTkvMjAxMyAxMDoxNiBB TSwgVmluY2VudCBDaGVuIHdyb3RlOg0KPiANCj4gDQo+IAkJCQlTdW5namluLA0KPiANCj4gDQo+ IAkJCQlPbiBNb24sIEp1bCAxNSwgMjAxMyBhdCA2OjAyIFBNLCBTdW5namluIDxzanlvdUBldHJp LnJlLmtyPiB3cm90ZToNCj4gDQo+IA0KPiAJCQkJCVZpbmNlLA0KPiANCj4gCQkJCQlJIHVuZGVy c3RhbmQgImJhbmR3aWR0aCIgcGFyYW1ldGVyIGlzIGp1c3QgZm9yIGRlZmluaW5nIA0KPiBwZXJt aXNzaWJsZSBwb3dlciBvciBzcGVjdHJhbCBkZW5zaXR5IGFuZA0KPiAJCQkJCWl0IGRvc2Ugbm90 IHJlcHJlc2VudCB0aGUgb3BlcmF0aW9uIGJhbmR3aWR0aC4gKHNlZSA0LjQuNS4NCj4gU1BFQ1RS VUNfVVNFX05PVElGWSwgJ3NwZWN0cmEnIHBhcmFtZXRlcg0KPiBkZXNjcmlwdGlvbikNCj4gCQkJ CQlJZiBJIG1pc3VuZGVyc3RhbmQsIHBsZWFzZSBjb3JyZWN0IG1lLg0KPiANCj4gDQo+IA0KPiAJ CQkJT2gsIEkgdW5kZXJzdGFuZCB3aGF0IHlvdSdyZSBzYXlpbmcuIFRoZSBleGFtcGxlIGRvZXMg bm90IG1ha2UgDQo+IHN1cmUgdGhlIG1hdGggd29ya3Mgb3V0IHRvIGJlIGVxdWl2YWxlbnQuDQo+ IAkJCQlJIHRob3VnaHQsIHRob3VnaCwgc29tZSByZWd1bGF0b3JzIGFjdHVhbGx5IHdhbnRzIGRp ZmZlcmVudCBwb3dlciANCj4gc3BlY3RyYWwgZGVuc2l0eSBmb3IgbmFycm93IGJhbmQsIHNvIGl0 J3Mgbm90IGFsd2F5cw0KPiAJCQkJZ3VhcmFudGVlZCB0byBiZSB0aGUgc2FtZS4NCj4gDQo+IA0K PiANCj4gCQkJSWYgbWFzdGVyIGRldmljZSByZWNlaXZlIHRoZSBtZXNzYWdlIGluIHRoZSBleGFt cGxlLCBpdCB3aWxsIGJlIA0KPiBjb25mdXNlZC4gQXNzdW1lIHRoZSBtYXN0ZXIgZGV2aWNlIGRl Y2lkZXMgdG8gdXNlIHRoZSBzcGVjdHJ1bSBmcm9tDQo+IDUuMThlOCBIeiB0byA1LjI0ZTggSHoo Nk1IeiBiYW5kd2lkdGgpIGFmdGVyIHJlY2VpdmluZyB0aGlzIG1lc3NhZ2UuDQo+IFRoZW4gdGhl IG1hc3RlciBkZXZpY2UgbWF5IGJlIGNvbmZ1c2VkIHRvIGludGVycHJldCBwZXJtaXNzaWJsZSAN Cj4gbWF4aW11bSBwb3dlci4gRmlyc3Qgb25lIGluIHRoZSBleGFtcGxlIHJlcHJlc2VudHMgMzAu MCBkQm0sIGJ1dCANCj4gc2Vjb25kIG9uZSByZXByZXNlbnRzIGFib3V0IDQ0Ljc4IGRCbSg9Mjdk Qm0gKyAxNy43OGRCKS4gVGhlIG1hc3RlciANCj4gZGV2aWNlIGRvbid0IGtub3cgd2hpY2ggb25l IGlzIGNvcnJlY3QuDQo+IAkJCVNvIEkgdGhpbmsgaXQgd2lsbCBiZSBjbGVhciBpZiAiZnJlcXVl bmN5UmFuZ2VzIiBpbiB0aGUgc2Vjb25kIA0KPiBvbmUoZm9yICJiYW5kd2lkdGgiIDogMWU1KSBp cyBtb2RpZmllZCB0byBkaWZmZXJlbnQgZnJlcXVlbmN5IGZyb20gDQo+IGZpcnN0IG9uZShmb3Ig ImJhbmR3aWR0aCIgOiAxZTUpDQo+IA0KPiANCj4gDQo+IAkJCQkJQW5kIEkgZm91bmQgYW5vdGhl ciB0eXBvcy4NCj4gCQkJCQkianNvbnJwYyI6ICIyLjAiLCBzaG91bGQgYmUgYWRkZWQgdG8gYWxs IGV4YW1wbGVzLg0KPiANCj4gDQo+IA0KPiAJCQkJVGhhbmtzLiBJIHdpbGwgaW5jb3Jwb3JhdGUg dGhpcy4NCj4gDQo+IA0KPiANCj4gCQkJCQlSZWdhcmRzLA0KPiAJCQkJCVN1bmdqaW4NCj4gDQo+ IA0KPiAJCQkJCU9uIDA3LzE2LzIwMTMgMDY6NTYgQU0sIFZpbmNlbnQgQ2hlbg0KPiB3cm90ZToN Cj4gDQo+IA0KPiAJCQkJCQlTdW5namluLA0KPiANCj4gCQkJCQkJU29ycnkgZm9yIHRoZSBsb25n IGRlbGF5DQo+ICh2YWNhdGlvbikuIEFuc3dlcnMgaW5saW5lLg0KPiANCj4gDQo+IAkJCQkJCU9u IFN1biwgSnVuIDMwLCAyMDEzIGF0IDEwOjMwIFBNLCDsnKDshLHsp4QgPHNqeW91QGV0cmkucmUu a3I+IHdyb3RlOg0KPiANCj4gDQo+IAkJCQkJCQlIaSBBbGwsDQo+IA0KPiAJCQkJCQkJSSBoYXZl IGZvdW5kIHR3byB0eXBvcy4NCj4gDQo+IAkJCQkJCQlBdCBleGFtcGxlICJnZXRTcGVjdHJ1bSIN Cj4gSlNPTi1SUEMgaW4gNi40LjEuIDoNCj4gCQkJCQkJCSAgICAgICAgImlkIjogInh4eHh4eCIs ICAgICAtDQo+IC0+IENvbW1hIHNob3VsZCBiZSBkZWxldGVkLg0KPiAJCQkJCQkJQXQgZXhhbXBs ZSAiZ2V0U3BlY3RydW1CYXRjaCINCj4gSlNPTi1SUEMgaW4gNi41LjEuIDoNCj4gCQkJCQkJCSAg ICAgICAgImlkIjogInh4eHh4eCIsICAgICAtDQo+IC0+IENvbW1hIHNob3VsZCBiZSBkZWxldGVk Lg0KPiANCj4gDQo+IA0KPiAJCQkJCQlUaGFua3MhDQo+IA0KPiANCj4gDQo+IA0KPiAJCQkJCQkJ SSBoYXZlIGEgY29tbWVudCBhYm91dA0KPiBleGFtcGxlICJnZXRTcGVjdHJ1bSIgSlNPTi1SUEMg cmVzcG9uc2UgaW4gNi40LjIgYW5kIDYuNS4yLg0KPiAJCQkJCQkJVGhlcmUgYXJlIHR3byBzcGVj dHJ1bQ0KPiBpbmZvcm1hdGlvbiBwYXJhbWV0ZXJzICBmb3IgdGhlIHNhbWUgZnJlcXVlbmN5IHJh bmdlLg0KPiAJCQkJCQkJT25lIGlzIGZvciBiYW5kd2lkdGggNmU2LCBhbmQNCj4gdGhlIG90aGVy IGlzIGZvciBiYW5kd2lkdGggMWU1Lg0KPiAJCQkJCQkJQnV0IHNwZWN0cmFsIGRlbnNpdHkgb2Yg NmU2DQo+IGlzIGRpZmZlcmVudCBmcm9tIHRoYXQgb2YgMWU1IGluIHRoZSBzYW1lIGZyZXF1ZW5j eSByYW5nZS4NCj4gCQkJCQkJCUl0IHdpbGwgYmUgbW9yZSBuaWNlIGlmIHRoZQ0KPiBzcGVjdHJh bCBkZW5zaXR5IG9mIHRoZSBzYW1lIGZyZXF1ZW5jeSByYW5nZSBpcyBzYW1lLg0KPiAJCQkJCQkJ T3IgaXQgd2lsbCBiZSBhbHNvIG5pY2UgaWYNCj4gZnJlcXVlbmN5IHJhbmdlcyBhcmUgbW9kaWZp ZWQgdG8gYmUgZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlci4NCj4gDQo+IA0KPiANCj4gCQkJCQkJ VGhpcyBpcyBpbnRlbmRlZCB0byByZXByZXNlbnQgdGhlIHBlcm1pc3NpYmxlIG1heGltdW0gcG93 ZXIgaW4gDQo+IHdoaWNoICJ3aWRlLWJhbmQiIGFuZCAibmFycm93LWJhbmQiDQo+IG9wZXJhdGlv bnMgYXJlIHBlcm1pdHRlZC4NCj4gCQkJCQkJVGhlIGF2YWlsYWJsZSBmcmVxdWVuY2llcyBkbyBu b3QgY2hhbmdlIChoZW5jZSwgdGhlIHNhbWUgDQo+IHN0YXJ0L3N0b3AgZnJlcXVlbmNpZXMpLCBq dXN0IHRoZSBwZXJtaXNzaWJsZSBwb3dlci4NCj4gDQo+IA0KPiAJCQkJCQlEb2VzIHRoYXQgbWFr ZSBzZW5zZT8NCj4gDQo+IAkJCQkJCS12aW5jZQ0KPiANCj4gDQo+IA0KPiANCj4gCQkJCQkJCVRo YW5rIHlvdS4NCj4gDQo+IAkJCQkJCQlCUiwNCj4gCQkJCQkJCVN1bmdqaW4NCj4gDQo+IA0KPiAN Cj4gCQkJCQkJCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIAkJCQkJCQlGcm9tOiBwYXdzLWJv dW5jZXNAaWV0Zi5vcmcNCj4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBHYWJvci5CYWprb0Bub2tpYS5jb20NCj4gCQkJCQkJCVNlbnQ6IFRodXJzZGF5LCBKdW5l IDIwLCAyMDEzIDI6MTggQU0gCQkJCQkJCVRvOiBwYXdzQGlldGYub3JnDQo+IAkJCQkJCQlTdWJq ZWN0OiBbcGF3c10gV0dMQyBvbg0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXBhd3MtcHJvdG9jb2wtMDYNCj4gDQo+IA0KPiAJCQkJCQkJQWxsLA0KPiANCj4gCQkJCQkJ CVRoZSBFZGl0b3Igb2YgdGhlIGRvY3VtZW50IHBvc3RlZCBhIG5ldyB2ZXJzaW9uIGFuZCBpbmRp Y2F0ZWQgDQo+IHRoYXQgYWxsIG9wZW4gaXNzdWVzIHJhaXNlZCBvbiB0aGUgbGlzdCB3ZXJlIHJl c29sdmVkLCBhbmQgdGhhdCB0aGVyZQ0KPiBhcmUgbm8gbW9yZSBvcGVuIGlzc3VlcyBoZSBpcyBh d2FyZSBvZi4gCQkJCQkJCVRoZXJlZm9yZSwgSSdkIGxpa2UgdG8NCj4gaXNzdWUgYSB3ZyBsYXN0 IGNhbGwgb24gdGhlIGRvY3VtZW50LiBXZSBuZWVkIHJldmlld3MgYW5kIGZlZWRiYWNrIGluIA0K PiBvcmRlciB0byBiZSBhYmxlIHRvIHByb2dyZXNzIHRoZSBkb2N1bWVudC4NCj4gDQo+IAkJCQkJ CQlQbGVhc2UgcmVhZCB0aHJvdWdoIHRoZSBkcmFmdA0KPiBhbmQgc2VuZCBhbnkgY29tbWVudHMg eW91IG1heSBoYXZlIHRvIHRoZSBsaXN0IGluIHRoZSBuZXh0IDItMyB3ZWVrcy4NCj4gCQkJCQkJ CUlmIHlvdSByZXZpZXcgdGhlIGRyYWZ0IGFuZA0KPiBoYXZlIG5vIGNvbW1lbnRzLCBzZW5kIGEg bm90ZSB0byB0aGUgbGlzdCB0aGF0IHRoZSBkcmFmdCBpcyBnb29kIGFzIGl0IA0KPiBpcywgd2Ug bmVlZCB0aGVzZSBub3RlcyBhcyBtdWNoIGFzIHdlIG5lZWQgdGhlIGFjdHVhbCBjb21tZW50cy4N Cj4gDQo+IAkJCQkJCQlUaGFua3MsIEdhYm9yDQo+IA0KPiAJX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gCQkJCQkJCXBhd3MgbWFpbGluZyBsaXN0DQo+ IAkJCQkJCQlwYXdzQGlldGYub3JnDQo+IA0KPiAJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wYXdzDQo+IA0KPiAJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gCQkJCQkJCXBhd3MgbWFpbGluZyBsaXN0DQo+IAkJCQkJCQlwYXdz QGlldGYub3JnDQo+IA0KPiAJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gCQkJCQkJLS0NCj4gCQkJCQkJLXZpbmNlDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gCQkJCS0tDQo+IAkJCQktdmluY2UNCj4gDQo+IA0KPiAJCQlSZWdh cmRzLA0KPiAJCQlTdW5namluDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IAkJLS0NCj4gCQkt dmluY2UNCj4gDQo+IA0KPiANCj4gDQo+DQoNCg0KDQo= From vchen@google.com Wed Jul 24 13:29: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 4907B11E80DE for ; Wed, 24 Jul 2013 13:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 hFRF6eDAq0Ck for ; Wed, 24 Jul 2013 13:29:42 -0700 (PDT) Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7243F11E80D2 for ; Wed, 24 Jul 2013 13:29:41 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id k5so3354607qej.9 for ; Wed, 24 Jul 2013 13:29:41 -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=urtFt8Tl3ZxPTdJ6xpVxuhlr1YxFfF+0zOaPDoQXK7M=; b=KPRqXou7L3GCUphAp4F51k668/AcGrUEuWcN8kEYiC+hm5zhKAIGyye+mxN+/aq4bp Yzp9bIdmti2BYvdu6aIyEZ3lv1AEIg+ktmD2qmzUtgCWEbOlWsuyHEMN8vILFSgV1zVS S3DlS/yvdZ7QzOVSIKrtRLNukSJOP6eQTUs2axHx3j/3wMKWc/JPtTp7qXbmgOX4cfbF f4KXZW+T1xeugbnIMrPYvkwezNG2KK63FEvyI7qy2EbNOWPEEOlTUCEL4Ai68RTCjgpy KUMQ+keCKz+ugH9RNaFanrdwOo3qkPKK7xXnWk5VbCtu3bZuCpB8t9SVU0vTHhv7ByrW i4pQ== X-Google-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:x-gm-message-state; bh=urtFt8Tl3ZxPTdJ6xpVxuhlr1YxFfF+0zOaPDoQXK7M=; b=eiTa/VPhNvQ2kD7m9WIi45DiOyBpFXElju+1RgLtWE0ISRWf59OUaUFG0vJdxtxRzM 1FLV2NxGIFNjD/Rqer4Zl98ocr27NxwbmBjrfhHaj69cho60C1T4eK5kTf2e7z6mef6K MNjAOo2YprUQFncPHHEPX6NFHy65d03BhHXJgoIGiCO13Jkq51o85AZsQZWYZsLBTPlc Bl2+M0TxdWetekq28Fq+lcNRCiSJBFMpZsOrezXqkFYid56JN8JtxGdaunhUNq77508f Wlf4euIB+if4CA23QVRUl4coDMc89aPBAgtVcrWZ0T6zBeOdw3SJkHtvkqmwsLADxYNj Vclw== MIME-Version: 1.0 X-Received: by 10.229.139.196 with SMTP id f4mr10586973qcu.34.1374697780882; Wed, 24 Jul 2013 13:29:40 -0700 (PDT) Received: by 10.229.161.80 with HTTP; Wed, 24 Jul 2013 13:29:40 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F5075B@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> <51E49B9E.7090900@etri.re.kr> <51E8C552.4060100@etri.re.kr> <51E8D65A.5030500@etri.re.kr> <5963DDF1F751474D8DEEFDCDBEE43AE716F5075B@dfweml512-mbx.china.huawei.com> Date: Wed, 24 Jul 2013 13:29:40 -0700 Message-ID: From: Vincent Chen To: Peter McCann Content-Type: multipart/alternative; boundary=001a11c3ce22e748a204e247c44b X-Gm-Message-State: ALoCoQkP43EweT+bKctMgPJwr3fpNQnfgIQdZtosOf6EYtU5sHOZtayX6gp7adlU6ndYHFu5nJWmdayQEMnu6bjzi5dvdl63xxFA0OgGuzHp0CQXAs/013/5ppLg9q/kzR6stKCVS/CbfOMLe+QTs56d6r+nTvf4tjDb6bNHUHo4IMjJubtZ32qg2brSgmSn54ACs+vZmN4n Cc: "paws@ietf.org" Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 20:29:44 -0000 --001a11c3ce22e748a204e247c44b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Peter, That's what makes the Option 2, perhaps, more generic: List of [frequencyHz, maxPowerDBm] in that you can start to build piece-wise linear shapes.... It would make the protocol more future-proof, even if we don't use it initially to capture such shapes. I guess the trade-off is, at what point the protocol becomes too complex..... -vince On Wed, Jul 24, 2013 at 11:20 AM, Peter McCann wro= te: > Do we need to talk about the slope of the filter mask that caps the > out-of-band emissions? > > -Pete > > > Vincent Chen wrote: > > Sungjin, > > > > Sorry for the delay and the confusion. > > > > Assuming we have the response that contains: > > > > > > "spectra": [ > > { > > "bandwidth": 6e6, > > "frequencyRanges": [ > > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, > > ... > > ] > > }, > > { > > "bandwidth": 1e5, > > "frequencyRanges": [ > > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, > > ... > > ] > > } > > This specifies that the frequencies in the range [518MHz, 536MHz) are > > available, and the device must satisfy two conditions: > > > > - Within any 6MHz in that range, total power may not exceed 30.0 dBm > > AND - Within any 100kHz in that range, total power may not exceed 27 > > dBm In this example, it means that the device may fit two 100kHz "sub- > > channels" at 27dBm within any 6MHz channel. > > > > (There are many other possibilities.) > > > > Does this make sense? If so, I'll update the draft to make this more > > clear. > > > > Thanks. > > > > -vince > > > > > > > > On Thu, Jul 18, 2013 at 11:02 PM, Sungjin Yoo wrote: > > > > > > Vince, > > > > Comment is in line. > > > > > > > > On 07/19/2013 02:17 PM, Vincent Chen wrote: > > > > > > Sunglin, > > > > Some clarification: The maxPowerDbm is total power. It is > not a > > spectral density. > > > > > > I agree. But (maxPowerDBm / bandwidth) defines the spectral > density. > > > > > > > > Thus, if a 6MHz channel is available, the Device may > choose to put, > > say, ten 100kHz sub-channels within that channel. The total > power > > summed over those 10 sub-channels cannot exceed 27dBm. > > > > > > So here is one way the Device may use the response. > > - The Device determines first if it wants to be a narrow > band (1e5) > > or wideband (6e6) device > > - It selects the Spectrum specification, based on its mo= de > > > > > > I think "bandwidth" parameter does not limit the operation > bandwidth > > of the device, it is just reference bandwidth to define permissible > > power levels and that is equivalent to define spectral density. I > > think "maxContiguousBwHz" parameter(4.4.2) limit the operation > > bandwidth, and "bandwidth" parameter does not. > > > > I understand the "bandwidth" parameter from following paragraphs. > > > > 4.4.5. SPECTRUM_USE_NOTIFY, "The actual bandwidth to be used (as > > computed from the start and stop frequencies) MAY be different from > > the"bandwidth" value. > > > > 5.4. FrequencyRange, "NOTE: (maxPowerDBm / bandwidth) defines the > > maximum permitted EIRP spectral density." > > > > 4.4.2. AVAIL_SPECTRUM_RESP, "maxContiguousBwHz: The Database MAY > > return a constraint on the maximum contiguous bandwidth (in Hertz) > allowed." > > > > > > > > > > > > -vince > > > > > > On Thu, Jul 18, 2013 at 9:49 PM, Sungjin Yoo < > sjyou@etri.re.kr> wrote: > > > > > > Vince, > > > > Comment is in line. > > > > > > On 07/19/2013 10:16 AM, Vincent Chen wrote: > > > > > > Sungjin, > > > > > > On Mon, Jul 15, 2013 at 6:02 PM, Sungjin = < > sjyou@etri.re.kr> wrote: > > > > > > Vince, > > > > I understand "bandwidth" paramete= r > is just for defining > > permissible power or spectral density and > > it dose not represent the > operation bandwidth. (see 4.4.5. > > SPECTRUC_USE_NOTIFY, 'spectra' parameter > > description) > > If I misunderstand, please correc= t > me. > > > > > > > > Oh, I understand what you're saying. The > example does not make > > sure the math works out to be equivalent. > > I thought, though, some regulators > actually wants different power > > spectral density for narrow band, so it's not always > > guaranteed to be the same. > > > > > > > > If master device receive the message in the > example, it will be > > confused. Assume the master device decides to use the spectrum from > > 5.18e8 Hz to 5.24e8 Hz(6MHz bandwidth) after receiving this message. > > Then the master device may be confused to interpret permissible > > maximum power. First one in the example represents 30.0 dBm, but > > second one represents about 44.78 dBm(=3D27dBm + 17.78dB). The master > > device don't know which one is correct. > > So I think it will be clear if "frequencyRanges" > in the second > > one(for "bandwidth" : 1e5) is modified to different frequency from > > first one(for "bandwidth" : 1e5) > > > > > > > > And I found another typos. > > "jsonrpc": "2.0", should be added > to all examples. > > > > > > > > Thanks. I will incorporate this. > > > > > > > > Regards, > > Sungjin > > > > > > On 07/16/2013 06:56 AM, Vincent > Chen > > wrote: > > > > > > Sungjin, > > > > Sorry for the long delay > > (vacation). Answers inline. > > > > > > On Sun, Jun 30, 2013 at > 10:30 PM, =EC=9C=A0=EC=84=B1=EC=A7=84 wrote: > > > > > > Hi All, > > > > I have found two > typos. > > > > At example > "getSpectrum" > > JSON-RPC in 6.4.1. : > > "id": > "xxxxxx", - > > -> Comma should be deleted. > > At example > "getSpectrumBatch" > > JSON-RPC in 6.5.1. : > > "id": > "xxxxxx", - > > -> Comma should be deleted. > > > > > > > > Thanks! > > > > > > > > > > I have a comment > about > > example "getSpectrum" JSON-RPC response in 6.4.2 and 6.5.2. > > There are two > spectrum > > information parameters for the same frequency range. > > One is for > bandwidth 6e6, and > > the other is for bandwidth 1e5. > > But spectral > density of 6e6 > > is different from that of 1e5 in the same frequency range. > > It will be more > nice if the > > spectral density of the same frequency range is same. > > Or it will be als= o > nice if > > frequency ranges are modified to be different from each other. > > > > > > > > This is intended to > represent the permissible maximum power in > > which "wide-band" and "narrow-band" > > operations are permitted. > > The available frequencies > do not change (hence, the same > > start/stop frequencies), just the permissible power. > > > > > > Does that make sense? > > > > -vince > > > > > > > > > > Thank you. > > > > BR, > > Sungjin > > > > > > > > -----Original > Message----- From: > paws-bounces@ietf.org > > [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com > > Sent: Thursday, > June 20, 2013 2:18 AM T= o: > paws@ietf.org > > Subject: [paws] > WGLC on > > http://tools.ietf.org/html/draft-ietf-paws-protocol-06 > > > > > > All, > > > > The Editor of the > document posted a new version and indicated > > that all open issues raised on the list were resolved, and that there > > are no more open issues he is aware of. > Therefore, I'd like to > > issue a wg last call on the document. We need reviews and feedback in > > order to be able to progress the document. > > > > Please read > through the draft > > and send any comments you may have to the list in the next 2-3 weeks. > > If you review the > draft and > > have no comments, send a note to the list that the draft is good as it > > is, we need these notes as much as we need the actual comments. > > > > Thanks, Gabor > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > > > https://www.ietf.org/mailman/listinfo/paws > > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > > > > > > -- > > -vince > > > > > > > > > > > > -- > > -vince > > > > > > Regards, > > Sungjin > > > > > > > > > > > > > > -- > > -vince > > > > > > > > > > > > > > --=20 -vince --001a11c3ce22e748a204e247c44b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+UGV0ZXIsPGRpdj48YnI+PC9kaXY+PGRpdj5UaGF0JiMzOTtzIHdoYXQg bWFrZXMgdGhlIE9wdGlvbiAyLCBwZXJoYXBzLCBtb3JlIGdlbmVyaWM6PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj7CoCBMaXN0IG9mIFtmcmVxdWVuY3lIeiwgbWF4UG93ZXJEQm1dPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5pbiB0aGF0IHlvdSBjYW4gc3RhcnQgdG8gYnVpbGQgcGllY2Utd2lz ZSBsaW5lYXIgc2hhcGVzLi4uLjwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGRpdj5JdCB3b3VsZCBt YWtlIHRoZSBwcm90b2NvbCBtb3JlIGZ1dHVyZS1wcm9vZiwgZXZlbiBpZiB3ZSBkb24mIzM5O3Qg dXNlIGl0IGluaXRpYWxseSB0byBjYXB0dXJlIHN1Y2ggc2hhcGVzLjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+SSBndWVzcyB0aGUgdHJhZGUtb2ZmIGlzLCBhdCB3aGF0IHBvaW50IHRoZSBwcm90 b2NvbCBiZWNvbWVzIHRvbyBjb21wbGV4Li4uLi48L2Rpdj4NCjxkaXY+PGJyPjwvZGl2PjxkaXY+ LXZpbmNlPC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48YnI+PGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwgSnVsIDI0LCAyMDEzIGF0IDExOjIwIEFNLCBQZXRl ciBNY0Nhbm4gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86UGV0ZXIuTWNDYW5u QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5QZXRlci5NY0Nhbm5AaHVhd2VpLmNvbTwvYT4m Z3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0 eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5n LWxlZnQ6MWV4Ij5EbyB3ZSBuZWVkIHRvIHRhbGsgYWJvdXQgdGhlIHNsb3BlIG9mIHRoZSBmaWx0 ZXIgbWFzayB0aGF0IGNhcHMgdGhlPGJyPg0Kb3V0LW9mLWJhbmQgZW1pc3Npb25zPzxicj4NCjxi cj4NCi1QZXRlPGJyPg0KPGJyPg0KPGJyPg0KVmluY2VudCBDaGVuIHdyb3RlOjxicj4NCiZndDsg U3VuZ2ppbiw8YnI+DQomZ3Q7PGJyPg0KPGRpdiBjbGFzcz0iSE9FblpiIj48ZGl2IGNsYXNzPSJo NSI+Jmd0OyBTb3JyeSBmb3IgdGhlIGRlbGF5IGFuZCB0aGUgY29uZnVzaW9uLjxicj4NCiZndDs8 YnI+DQomZ3Q7IEFzc3VtaW5nIHdlIGhhdmUgdGhlIHJlc3BvbnNlIHRoYXQgY29udGFpbnM6PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgJnF1b3Q7c3BlY3RyYSZxdW90 OzogWzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqB7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCAm cXVvdDtiYW5kd2lkdGgmcXVvdDs6IDZlNiw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgICZxdW90 O2ZyZXF1ZW5jeVJhbmdlcyZxdW90OzogWzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgeyZx dW90O3N0YXJ0SHomcXVvdDs6NS4xOGU4LCAmcXVvdDtzdG9wSHomcXVvdDs6NS4zNmU4LCAmcXVv dDttYXhQb3dlckRCbSZxdW90OzozMC4wfSw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIC4u Ljxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgXTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqB9LDxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqB7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCAmcXVvdDti YW5kd2lkdGgmcXVvdDs6IDFlNSw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgICZxdW90O2ZyZXF1 ZW5jeVJhbmdlcyZxdW90OzogWzxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgeyZxdW90O3N0 YXJ0SHomcXVvdDs6NS4xOGU4LCAmcXVvdDtzdG9wSHomcXVvdDs6NS4zNmU4LCAmcXVvdDttYXhQ b3dlckRCbSZxdW90OzoyNy4wfSw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIC4uLjxicj4N CiZndDsgwqAgwqAgwqAgwqAgwqAgXTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqB9PGJyPg0KJmd0 OyBUaGlzIHNwZWNpZmllcyB0aGF0IHRoZSBmcmVxdWVuY2llcyBpbiB0aGUgcmFuZ2UgWzUxOE1I eiwgNTM2TUh6KSBhcmU8YnI+DQomZ3Q7IGF2YWlsYWJsZSwgYW5kIHRoZSBkZXZpY2UgbXVzdCBz YXRpc2Z5IHR3byBjb25kaXRpb25zOjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgLSBXaXRoaW4gYW55 IDZNSHogaW4gdGhhdCByYW5nZSwgdG90YWwgcG93ZXIgbWF5IG5vdCBleGNlZWQgMzAuMCBkQm08 YnI+DQomZ3Q7IEFORCAtIFdpdGhpbiBhbnkgMTAwa0h6IGluIHRoYXQgcmFuZ2UsIHRvdGFsIHBv d2VyIG1heSBub3QgZXhjZWVkIDI3PGJyPg0KJmd0OyBkQm0gSW4gdGhpcyBleGFtcGxlLCBpdCBt ZWFucyB0aGF0IHRoZSBkZXZpY2UgbWF5IGZpdCB0d28gMTAwa0h6ICZxdW90O3N1Yi08YnI+DQom Z3Q7IGNoYW5uZWxzJnF1b3Q7IGF0IDI3ZEJtIHdpdGhpbiBhbnkgNk1IeiBjaGFubmVsLjxicj4N CiZndDs8YnI+DQomZ3Q7IChUaGVyZSBhcmUgbWFueSBvdGhlciBwb3NzaWJpbGl0aWVzLik8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBEb2VzIHRoaXMgbWFrZSBzZW5zZT8gSWYgc28sIEkmIzM5O2xsIHVw ZGF0ZSB0aGUgZHJhZnQgdG8gbWFrZSB0aGlzIG1vcmU8YnI+DQomZ3Q7IGNsZWFyLjxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtdmluY2U8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIFRodSwgSnVsIDE4LCAyMDEzIGF0IDEx OjAyIFBNLCBTdW5namluIFlvbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNqeW91QGV0cmkucmUua3Ii PnNqeW91QGV0cmkucmUua3I8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgwqAgwqAgwqAgVmluY2UsPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgQ29tbWVu dCBpcyBpbiBsaW5lLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAg wqAgwqAgT24gMDcvMTkvMjAxMyAwMjoxNyBQTSwgVmluY2VudCBDaGVuIHdyb3RlOjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdW5nbGluLDxicj4N CiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNvbWUgY2xhcmlmaWNhdGlvbjog VGhlIG1heFBvd2VyRGJtIGlzIHRvdGFsIHBvd2VyLiBJdCBpcyBub3QgYTxicj4NCiZndDsgc3Bl Y3RyYWwgZGVuc2l0eS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgSSBh Z3JlZS4gQnV0IChtYXhQb3dlckRCbSAvIGJhbmR3aWR0aCkgZGVmaW5lcyB0aGUgc3BlY3RyYWwg ZGVuc2l0eS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKg IMKgIMKgIMKgIMKgIFRodXMsIGlmIGEgNk1IeiBjaGFubmVsIGlzIGF2YWlsYWJsZSwgdGhlIERl dmljZSBtYXkgY2hvb3NlIHRvIHB1dCw8YnI+DQomZ3Q7IHNheSwgdGVuIDEwMGtIeiBzdWItY2hh bm5lbHMgd2l0aGluIHRoYXQgY2hhbm5lbC4gwqAgwqAgwqAgwqAgwqAgwqAgVGhlIHRvdGFsIHBv d2VyPGJyPg0KJmd0OyBzdW1tZWQgb3ZlciB0aG9zZSAxMCBzdWItY2hhbm5lbHMgY2Fubm90IGV4 Y2VlZCAyN2RCbS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAg wqAgwqAgU28gaGVyZSBpcyBvbmUgd2F5IHRoZSBEZXZpY2UgbWF5IHVzZSB0aGUgcmVzcG9uc2Uu PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoC0gVGhlIERldmljZSBkZXRlcm1pbmVz IGZpcnN0IGlmIGl0IHdhbnRzIHRvIGJlIGEgbmFycm93IGJhbmQgKDFlNSk8YnI+DQomZ3Q7IG9y IHdpZGViYW5kICg2ZTYpIGRldmljZTxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAt IEl0IHNlbGVjdHMgdGhlIFNwZWN0cnVtIHNwZWNpZmljYXRpb24sIGJhc2VkIG9uIGl0cyBtb2Rl PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIEkgdGhpbmsgJnF1b3Q7YmFu ZHdpZHRoJnF1b3Q7IHBhcmFtZXRlciBkb2VzIG5vdCBsaW1pdCB0aGUgb3BlcmF0aW9uIGJhbmR3 aWR0aDxicj4NCiZndDsgb2YgdGhlIGRldmljZSwgaXQgaXMganVzdCByZWZlcmVuY2UgYmFuZHdp ZHRoIHRvIGRlZmluZSBwZXJtaXNzaWJsZTxicj4NCiZndDsgcG93ZXIgbGV2ZWxzIGFuZCB0aGF0 IGlzIGVxdWl2YWxlbnQgdG8gZGVmaW5lIHNwZWN0cmFsIGRlbnNpdHkuIEk8YnI+DQomZ3Q7IHRo aW5rICZxdW90O21heENvbnRpZ3VvdXNCd0h6JnF1b3Q7IHBhcmFtZXRlcig0LjQuMikgwqBsaW1p dCB0aGUgb3BlcmF0aW9uPGJyPg0KJmd0OyBiYW5kd2lkdGgsIGFuZCAmcXVvdDtiYW5kd2lkdGgm cXVvdDsgcGFyYW1ldGVyIGRvZXMgbm90Ljxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIEkg dW5kZXJzdGFuZCB0aGUgJnF1b3Q7YmFuZHdpZHRoJnF1b3Q7IHBhcmFtZXRlciBmcm9tIGZvbGxv d2luZyBwYXJhZ3JhcGhzLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIDQuNC41LiBTUEVD VFJVTV9VU0VfTk9USUZZLCAmcXVvdDtUaGUgYWN0dWFsIGJhbmR3aWR0aCB0byBiZSB1c2VkIChh czxicj4NCiZndDsgY29tcHV0ZWQgZnJvbSB0aGUgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMp IE1BWSBiZSBkaWZmZXJlbnQgZnJvbTxicj4NCiZndDsgdGhlJnF1b3Q7YmFuZHdpZHRoJnF1b3Q7 IHZhbHVlLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIDUuNC4gRnJlcXVlbmN5UmFuZ2Us ICZxdW90O05PVEU6IChtYXhQb3dlckRCbSAvIGJhbmR3aWR0aCkgZGVmaW5lcyB0aGU8YnI+DQom Z3Q7IG1heGltdW0gcGVybWl0dGVkIEVJUlAgc3BlY3RyYWwgZGVuc2l0eS4mcXVvdDs8YnI+DQom Z3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCA0LjQuMi4gQVZBSUxfU1BFQ1RSVU1fUkVTUCwgJnF1b3Q7 bWF4Q29udGlndW91c0J3SHo6IFRoZSBEYXRhYmFzZSBNQVk8YnI+DQomZ3Q7IHJldHVybiBhIGNv bnN0cmFpbnQgb24gdGhlIG1heGltdW0gY29udGlndW91cyBiYW5kd2lkdGggKGluIEhlcnR6KSBh bGxvd2VkLiZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtdmluY2U8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT24gVGh1LCBKdWwgMTgsIDIw MTMgYXQgOTo0OSBQTSwgU3VuZ2ppbiBZb28gJmx0OzxhIGhyZWY9Im1haWx0bzpzanlvdUBldHJp LnJlLmtyIj5zanlvdUBldHJpLnJlLmtyPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFZpbmNlLDxicj4N CiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIENvbW1lbnQg aXMgaW4gbGluZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgT24gMDcvMTkvMjAxMyAxMDoxNiBBTSwgVmluY2VudCBDaGVuIHdy b3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdW5namluLDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiBNb24s IEp1bCAxNSwgMjAxMyBhdCA2OjAyIFBNLCBTdW5namluICZsdDs8YSBocmVmPSJtYWlsdG86c2p5 b3VAZXRyaS5yZS5rciI+c2p5b3VAZXRyaS5yZS5rcjwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBWaW5jZSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIHVuZGVyc3Rh bmQgJnF1b3Q7YmFuZHdpZHRoJnF1b3Q7IHBhcmFtZXRlciBpcyBqdXN0IGZvciBkZWZpbmluZzxi cj4NCiZndDsgcGVybWlzc2libGUgcG93ZXIgb3Igc3BlY3RyYWwgZGVuc2l0eSBhbmQ8YnI+DQom Z3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIGl0IGRvc2Ugbm90IHJlcHJlc2VudCB0aGUgb3BlcmF0aW9uIGJhbmR3aWR0aC4gKHNlZSA0 LjQuNS48YnI+DQomZ3Q7IFNQRUNUUlVDX1VTRV9OT1RJRlksICYjMzk7c3BlY3RyYSYjMzk7IHBh cmFtZXRlcjxicj4NCiZndDsgZGVzY3JpcHRpb24pPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJZiBJIG1pc3VuZGVyc3Rh bmQsIHBsZWFzZSBjb3JyZWN0IG1lLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgT2gsIEkg dW5kZXJzdGFuZCB3aGF0IHlvdSYjMzk7cmUgc2F5aW5nLiBUaGUgZXhhbXBsZSBkb2VzIG5vdCBt YWtlPGJyPg0KJmd0OyBzdXJlIHRoZSBtYXRoIHdvcmtzIG91dCB0byBiZSBlcXVpdmFsZW50Ljxi cj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgSSB0 aG91Z2h0LCB0aG91Z2gsIHNvbWUgcmVndWxhdG9ycyBhY3R1YWxseSB3YW50cyBkaWZmZXJlbnQg cG93ZXI8YnI+DQomZ3Q7IHNwZWN0cmFsIGRlbnNpdHkgZm9yIG5hcnJvdyBiYW5kLCBzbyBpdCYj Mzk7cyBub3QgYWx3YXlzPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCBndWFyYW50ZWVkIHRvIGJlIHRoZSBzYW1lLjxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg SWYgbWFzdGVyIGRldmljZSByZWNlaXZlIHRoZSBtZXNzYWdlIGluIHRoZSBleGFtcGxlLCBpdCB3 aWxsIGJlPGJyPg0KJmd0OyBjb25mdXNlZC4gQXNzdW1lIHRoZSBtYXN0ZXIgZGV2aWNlIGRlY2lk ZXMgdG8gdXNlIHRoZSBzcGVjdHJ1bSBmcm9tPGJyPg0KJmd0OyA1LjE4ZTggSHogdG8gNS4yNGU4 IEh6KDZNSHogYmFuZHdpZHRoKSBhZnRlciByZWNlaXZpbmcgdGhpcyBtZXNzYWdlLjxicj4NCiZn dDsgVGhlbiB0aGUgbWFzdGVyIGRldmljZSBtYXkgYmUgY29uZnVzZWQgdG8gaW50ZXJwcmV0IHBl cm1pc3NpYmxlPGJyPg0KJmd0OyBtYXhpbXVtIHBvd2VyLiBGaXJzdCBvbmUgaW4gdGhlIGV4YW1w bGUgcmVwcmVzZW50cyAzMC4wIGRCbSwgYnV0PGJyPg0KJmd0OyBzZWNvbmQgb25lIHJlcHJlc2Vu dHMgYWJvdXQgNDQuNzggZEJtKD0yN2RCbSArIDE3Ljc4ZEIpLiBUaGUgbWFzdGVyPGJyPg0KJmd0 OyBkZXZpY2UgZG9uJiMzOTt0IGtub3cgd2hpY2ggb25lIGlzIGNvcnJlY3QuPGJyPg0KJmd0OyDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTbyBJIHRoaW5rIGl0IHdpbGwgYmUgY2xl YXIgaWYgJnF1b3Q7ZnJlcXVlbmN5UmFuZ2VzJnF1b3Q7IGluIHRoZSBzZWNvbmQ8YnI+DQomZ3Q7 IG9uZShmb3IgJnF1b3Q7YmFuZHdpZHRoJnF1b3Q7IDogMWU1KSBpcyBtb2RpZmllZCB0byBkaWZm ZXJlbnQgZnJlcXVlbmN5IGZyb208YnI+DQomZ3Q7IGZpcnN0IG9uZShmb3IgJnF1b3Q7YmFuZHdp ZHRoJnF1b3Q7IDogMWU1KTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg QW5kIEkgZm91bmQgYW5vdGhlciB0eXBvcy48YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICZxdW90O2pzb25ycGMmcXVvdDs6 ICZxdW90OzIuMCZxdW90Oywgc2hvdWxkIGJlIGFkZGVkIHRvIGFsbCBleGFtcGxlcy48YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoYW5rcy4gSSB3aWxsIGluY29ycG9yYXRlIHRoaXMuPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBSZWdhcmRzLDxicj4NCiZndDsg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg U3VuZ2ppbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbiAwNy8xNi8yMDEzIDA2OjU2 IEFNLCBWaW5jZW50IENoZW48YnI+DQomZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCBTdW5namluLDxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIFNvcnJ5IGZvciB0aGUgbG9uZyBkZWxheTxicj4NCiZndDsgKHZhY2F0aW9uKS4gQW5zd2Vy cyBpbmxpbmUuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIE9uIFN1 biwgSnVuIDMwLCAyMDEzIGF0IDEwOjMwIFBNLCDsnKDshLHsp4QgJmx0OzxhIGhyZWY9Im1haWx0 bzpzanlvdUBldHJpLnJlLmtyIj5zanlvdUBldHJpLnJlLmtyPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEhpIEFsbCw8 YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJIGhhdmUgZm91bmQg dHdvIHR5cG9zLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEF0 IGV4YW1wbGUgJnF1b3Q7Z2V0U3BlY3RydW0mcXVvdDs8YnI+DQomZ3Q7IEpTT04tUlBDIGluIDYu NC4xLiA6PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAmcXVv dDtpZCZxdW90OzogJnF1b3Q7eHh4eHh4JnF1b3Q7LCDCoCDCoCAtPGJyPg0KJmd0OyAtJmd0OyBD b21tYSBzaG91bGQgYmUgZGVsZXRlZC48YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IEF0IGV4YW1wbGUgJnF1b3Q7Z2V0U3BlY3RydW1CYXRjaCZxdW90Ozxicj4NCiZndDsgSlNPTi1S UEMgaW4gNi41LjEuIDo8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgICZxdW90O2lkJnF1b3Q7OiAmcXVvdDt4eHh4eHgmcXVvdDssIMKgIMKgIC08YnI+DQomZ3Q7 IC0mZ3Q7IENvbW1hIHNob3VsZCBiZSBkZWxldGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhhbmtzITxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIEkgaGF2 ZSBhIGNvbW1lbnQgYWJvdXQ8YnI+DQomZ3Q7IGV4YW1wbGUgJnF1b3Q7Z2V0U3BlY3RydW0mcXVv dDsgSlNPTi1SUEMgcmVzcG9uc2UgaW4gNi40LjIgYW5kIDYuNS4yLjxicj4NCiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgVGhlcmUgYXJlIHR3byBzcGVjdHJ1bTxicj4NCiZndDsgaW5mb3Jt YXRpb24gcGFyYW1ldGVycyDCoGZvciB0aGUgc2FtZSBmcmVxdWVuY3kgcmFuZ2UuPGJyPg0KJmd0 OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPbmUgaXMgZm9yIGJhbmR3aWR0aCA2ZTYsIGFuZDxi cj4NCiZndDsgdGhlIG90aGVyIGlzIGZvciBiYW5kd2lkdGggMWU1Ljxicj4NCiZndDsgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgQnV0IHNwZWN0cmFsIGRlbnNpdHkgb2YgNmU2PGJyPg0KJmd0OyBp cyBkaWZmZXJlbnQgZnJvbSB0aGF0IG9mIDFlNSBpbiB0aGUgc2FtZSBmcmVxdWVuY3kgcmFuZ2Uu PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBJdCB3aWxsIGJlIG1vcmUgbmljZSBp ZiB0aGU8YnI+DQomZ3Q7IHNwZWN0cmFsIGRlbnNpdHkgb2YgdGhlIHNhbWUgZnJlcXVlbmN5IHJh bmdlIGlzIHNhbWUuPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBPciBpdCB3aWxs IGJlIGFsc28gbmljZSBpZjxicj4NCiZndDsgZnJlcXVlbmN5IHJhbmdlcyBhcmUgbW9kaWZpZWQg dG8gYmUgZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlci48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoaXMgaXMgaW50ZW5kZWQgdG8gcmVwcmVzZW50 IHRoZSBwZXJtaXNzaWJsZSBtYXhpbXVtIHBvd2VyIGluPGJyPg0KJmd0OyB3aGljaCAmcXVvdDt3 aWRlLWJhbmQmcXVvdDsgYW5kICZxdW90O25hcnJvdy1iYW5kJnF1b3Q7PGJyPg0KJmd0OyBvcGVy YXRpb25zIGFyZSBwZXJtaXR0ZWQuPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBUaGUgYXZhaWxhYmxl IGZyZXF1ZW5jaWVzIGRvIG5vdCBjaGFuZ2UgKGhlbmNlLCB0aGUgc2FtZTxicj4NCiZndDsgc3Rh cnQvc3RvcCBmcmVxdWVuY2llcyksIGp1c3QgdGhlIHBlcm1pc3NpYmxlIHBvd2VyLjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBEb2VzIHRoYXQgbWFrZSBzZW5zZT88 YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtdmluY2U8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBU aGFuayB5b3UuPGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQlIs PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBTdW5namluPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLSDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoEZyb206IDxhIGhyZWY9 Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmciPnBhd3MtYm91bmNlc0BpZXRmLm9yZzwvYT48 YnI+DQomZ3Q7IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyI+ cGF3cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIDxhIGhyZWY9Im1haWx0bzpH YWJvci5CYWprb0Bub2tpYS5jb20iPkdhYm9yLkJhamtvQG5va2lhLmNvbTwvYT48YnI+DQomZ3Q7 IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFNlbnQ6IFRodXJzZGF5LCBKdW5lIDIwLCAyMDEzIDI6 MTggQU0gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVG86IDxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3Jn Ij5wYXdzQGlldGYub3JnPC9hPjxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgU3Vi amVjdDogW3Bhd3NdIFdHTEMgb248YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC0wNiIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcGF3cy1wcm90b2NvbC0wNjwvYT48 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgQWxs LDxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZSBFZGl0b3Ig b2YgdGhlIGRvY3VtZW50IHBvc3RlZCBhIG5ldyB2ZXJzaW9uIGFuZCBpbmRpY2F0ZWQ8YnI+DQom Z3Q7IHRoYXQgYWxsIG9wZW4gaXNzdWVzIHJhaXNlZCBvbiB0aGUgbGlzdCB3ZXJlIHJlc29sdmVk LCBhbmQgdGhhdCB0aGVyZTxicj4NCiZndDsgYXJlIG5vIG1vcmUgb3BlbiBpc3N1ZXMgaGUgaXMg YXdhcmUgb2YuIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIFRoZXJlZm9yZSwgSSYjMzk7ZCBsaWtl IHRvPGJyPg0KJmd0OyBpc3N1ZSBhIHdnIGxhc3QgY2FsbCBvbiB0aGUgZG9jdW1lbnQuIFdlIG5l ZWQgcmV2aWV3cyBhbmQgZmVlZGJhY2sgaW48YnI+DQomZ3Q7IG9yZGVyIHRvIGJlIGFibGUgdG8g cHJvZ3Jlc3MgdGhlIGRvY3VtZW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIFBsZWFzZSByZWFkIHRocm91Z2ggdGhlIGRyYWZ0PGJyPg0KJmd0OyBhbmQgc2Vu ZCBhbnkgY29tbWVudHMgeW91IG1heSBoYXZlIHRvIHRoZSBsaXN0IGluIHRoZSBuZXh0IDItMyB3 ZWVrcy48YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIElmIHlvdSByZXZpZXcgdGhl IGRyYWZ0IGFuZDxicj4NCiZndDsgaGF2ZSBubyBjb21tZW50cywgc2VuZCBhIG5vdGUgdG8gdGhl IGxpc3QgdGhhdCB0aGUgZHJhZnQgaXMgZ29vZCBhcyBpdDxicj4NCiZndDsgaXMsIHdlIG5lZWQg dGhlc2Ugbm90ZXMgYXMgbXVjaCBhcyB3ZSBuZWVkIHRoZSBhY3R1YWwgY29tbWVudHMuPGJyPg0K Jmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgVGhhbmtzLCBHYWJvcjxicj4N CiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBwYXdzIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgPGEgaHJlZj0ibWFp bHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsg wqAgwqAgwqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w YXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wYXdzPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCBwYXdzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmciPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtLTxicj4NCiZndDsgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgLXZpbmNlPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIC0tPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCAtdmluY2U8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgUmVnYXJkcyw8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIFN1bmdqaW48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIMKgIMKgIMKgIMKgIMKg IC0tPGJyPg0KJmd0OyDCoCDCoCDCoCDCoCDCoCDCoCDCoCAtdmluY2U8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCjxicj4NCjxicj4NCjxicj4N CjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxkaXY+ PGJyPjwvZGl2Pi0tIDxicj4tdmluY2UNCjwvZGl2Pg0K --001a11c3ce22e748a204e247c44b-- From sajeevmanikkoth@gmail.com Thu Jul 25 07:30:48 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 9C94D21F99E9 for ; Thu, 25 Jul 2013 07:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qXtpF+DJKUZ for ; Thu, 25 Jul 2013 07:30:48 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id E565E21F99E3 for ; Thu, 25 Jul 2013 07:30:47 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so817491pbb.36 for ; Thu, 25 Jul 2013 07:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=mDSNBGpOov8FlD4dP08QCfvpW6LnhKYRUbbr7fjABNw=; b=koaIU49ceLJQjbHZGcj0iz65QrtToJoyoAhyE3UxoJMEno+T2Pog25S7uiOIxlj+78 ki+8W0yJg6/FbZYt3BIIZyxygIDDuIWESh4Whw75LRSFUcIdeYhpGyNUqAK/qxJbtQbM rqJ/XBuEXKpZ7bhjJb0pDCJzb2sU3nZjw8RuNPVl887+SyRpMj+tTILgZCTaLE8bbvu2 Xe3xczXucqaPRh7aXWWzuY4PDzwxm9Xa0ocIfzQMTaVOel3Ds/gTOi/Obv0y+kMG+Cji zaKSmATeI/T3L170JmhkXwp9IwXWzitCo0aGJV/CzVqmS+Ryh436Xm56/1tMrYilRHaf q4xw== X-Received: by 10.66.142.73 with SMTP id ru9mr48830572pab.17.1374762647626; Thu, 25 Jul 2013 07:30:47 -0700 (PDT) Received: from adminPC ([49.249.132.75]) by mx.google.com with ESMTPSA id jf4sm54398321pbb.19.2013.07.25.07.30.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 07:30:46 -0700 (PDT) From: sajeevmanikkoth@gmail.com To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Date: Thu, 25 Jul 2013 20:00:38 +0530 Message-ID: <003601ce8943$8cdc6030$a6952090$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6ECAMrY2kuYF/5TTCJfFOcaTjfbQEbVezgADOBQ1A= Content-Language: en-us Subject: Re: [paws] Reviews requested for http://tools.ietf.org/html/draft-ietf-paws-protocol-06 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, 25 Jul 2013 14:30:48 -0000 Hi, Please find few comments below, based on my reading of the spec. 1. Section 2.2 states Slave device as a device without geolocation capability. I think the phrasing there need to be different. A Slave device may or may not have geolocation capability, but does not directly query the database. Also a mobile Slave device, can it not switch as master device in adhoc? 2. It will be a good thing to include 'timestamp:string | requirted' paramter in all the protocol transactions 3. Section 4.3.2 REGISTRATION_RESP should include 'rulesetInfo:RulesetInfo as required' parameter. 4. Section 4.4.4 AVAIL_SPECTRUM_REQ, Can this also include an optional requirement of minimum usage time? That is a master prefers to use the available spectrum for a minimum duration without interruption, and the database responds accordingly. This will help in ensuring QoS for whitespace transmission. 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database? Thanks and Regards, Sajeev -----Original Message----- From: Sajeev Manikkoth [mailto:sajeevmanikkoth@gmail.com] Sent: Wednesday, July 24, 2013 7:30 PM To: 'Gabor.Bajko@nokia.com'; 'paws@ietf.org' Subject: RE: [paws] Reviews requested for http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Hi, Please find few comments below, based on my reading of the spec. 1. Section 2.2 states Slave device as a device without geolocation capability. I think the phrasing there need to be different. A Slave device may or may not have geolocation capability, but does not directly query the database. Also a mobile Slave device, can it not switch as master device in adhoc? 2. It will be a good thing to include 'timestamp:string | requirted' paramter in all the protocol transactions 3. Section 4.3.2 REGISTRATION_RESP should include 'rulesetInfo:RulesetInfo as required' parameter. 4. Section 4.4.4 AVAIL_SPECTRUM_REQ, Can this also include an optional requirement of minimum usage time? That is a master prefers to use the available spectrum for a minimum duration without interruption, and the database responds accordingly. This will help in ensuring QoS for whitespace transmission. 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database? Thanks and Regards, Sajeev -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Friday, July 19, 2013 4:13 AM To: paws@ietf.org Subject: [paws] Reviews requested for http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Folks, I issued a WGLC on this document 4 weeks ago, and there was no feedback received at all. If you care about this document, you should review it and send your comments to the list. If you review it and you have no comments, then please send a mail to the list stating that you have reviewed the document and have no comments. Without reviews, we cannot make progress with the document. I cannot send it to the IESG requesting publication. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Wednesday, June 19, 2013 10:18 AM To: paws@ietf.org Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 All, The Editor of the document posted a new version and indicated that all open issues raised on the list were resolved, and that there are no more open issues he is aware of. Therefore, I'd like to issue a wg last call on the document. We need reviews and feedback in order to be able to progress the document. Please read through the draft and send any comments you may have to the list in the next 2-3 weeks. If you review the draft and have no comments, send a note to the list that the draft is good as it is, we need these notes as much as we need the actual comments. Thanks, Gabor _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From dharasty@appcomsci.com Thu Jul 25 07:44:53 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 7DC7B21F9AD3 for ; Thu, 25 Jul 2013 07:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 ymDiebbHomzJ for ; Thu, 25 Jul 2013 07:44:47 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA1E21F9A8F for ; Thu, 25 Jul 2013 07:44:45 -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 r6PEiiYh009863; Thu, 25 Jul 2013 10:44:44 -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 r6PEiiAC010582; Thu, 25 Jul 2013 10:44:44 -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, 25 Jul 2013 10:44:44 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: definition of Slave device Thread-Index: AQHOiUWAdd8QP6TL10qXXi3fXNBlBA== Date: Thu, 25 Jul 2013 14:44:44 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> In-Reply-To: <003601ce8943$8cdc6030$a6952090$@org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEEEC8Crrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] definition of Slave device 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, 25 Jul 2013 14:44:53 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEEC8Crrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to comment some of Sanjeev's input. I prefer to send independent replies on each topic, as that way a given ema= il thread is about a single topic (more or less). Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 1. Section 2.2 states Slave device as a device without geolocation capabili= ty. I think the phrasing there need to be different. A Slave device may or = may not have geolocation capability, but does not directly query the databa= se. Also a mobile Slave device, can it not switch as master device in adhoc= ? [...] I agree with the nature of his comment: a Slave device may well have geoloc= ation capabilities; however PAWS does not expect it needs to use them to co= mmunicate with a Master device. I would support an update to the definitio= n of Slave. --_000_EC510C021D06A34C92F5A5A488B5290B0CEEEC8Crrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'd like to comm= ent some of Sanjeev's input.

 =

I prefer to send independent replies on each= topic, as that way a given email thread is about a single topic (more or l= ess).

 

Sanjeev mentioned:

 

From: sajeevmanikko= th@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

1. Section 2.2 states Slave device as a = device without geolocation capability. I think the phrasing there need to b= e different. A Slave device may or may not have geolocation capability, but= does not directly query the database. Also a mobile Slave device, can it n= ot switch as master device in adhoc?

[...]

 

I agree= with the nature of his comment: a Slave device may well have geolocation c= apabilities; however PAWS does not expect it needs to use them to communica= te with a Master device.  I would support an update to the definition = of Slave.

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEEC8Crrcatsexmb2atsa_-- From dharasty@appcomsci.com Thu Jul 25 07:51: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 94EF721F9B11 for ; Thu, 25 Jul 2013 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 68-pq7OeOuUF for ; Thu, 25 Jul 2013 07:51:06 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 29AE221F9AE6 for ; Thu, 25 Jul 2013 07:51:06 -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 r6PEp5fj009963 for ; Thu, 25 Jul 2013 10:51:05 -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 r6PEp5w2010654 for ; Thu, 25 Jul 2013 10:51:05 -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, 25 Jul 2013 10:51:05 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: including a timestamp in every message Thread-Index: Ac6JRmMQgG97LBBWS0S1vipB9JwiFA== Date: Thu, 25 Jul 2013 14:51:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEEECD1rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] including a timestamp in every message 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, 25 Jul 2013 14:51:13 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEECD1rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to comment some of Sanjeev's input. I prefer to send independent replies on each topic, as that way a given ema= il thread is about a single topic (more or less). Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 2. It will be a good thing to include 'timestamp:string requirted' paramter= in all the protocol transactions [...] I don't see the purpose in this. I don't see how the operation of the Data= base - or the way it will respond to any given request - is dependent on it= knowing what time the Device thinks it is. (Or vice versa.) Unless someone can point out a use case for this field, I consider it unnee= ded "chatter" in the protocol. That said, the Database or Device can easil= y ignore it, so I won't push back if others believe this field is generally= useful. Dan --_000_EC510C021D06A34C92F5A5A488B5290B0CEEECD1rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'd like to comm= ent some of Sanjeev's input.

 =

I prefer to send independent replies on each= topic, as that way a given email thread is about a single topic (more or l= ess).

 

Sanjeev mentioned:

 

From: sajeevmanikko= th@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

2. It will be a good thing to include 't= imestamp:string requirted' paramter in all the protocol transactions <= /o:p>

[...]

 

I don’t see the purpose in this.  I don’t= see how the operation of the Database – or the way it will respond t= o any given request – is dependent on it knowing what time the Device= thinks it is.  (Or vice versa.)

 

Unless someone can point out a use = case for this field, I consider it unneeded “chatter” in the pr= otocol.  That said, the Database or Device can easily ignore it, so I = won’t push back if others believe this field is generally useful.

 

D= an

 

 

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEECD1rrcatsexmb2atsa_-- From dharasty@appcomsci.com Thu Jul 25 08:04:47 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 5C85821F9A06 for ; Thu, 25 Jul 2013 08:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 GLbBaTAMYUWe for ; Thu, 25 Jul 2013 08:04:40 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7221621F99D7 for ; Thu, 25 Jul 2013 08:04: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 r6PF4d16010134 for ; Thu, 25 Jul 2013 11:04:40 -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 r6PF4d4a010845 for ; Thu, 25 Jul 2013 11:04:39 -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, 25 Jul 2013 11:04:37 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: response to REGISTRATION_REQ Thread-Index: Ac6JSEc3pBd93CDZSJiynqW1sK69Yw== Date: Thu, 25 Jul 2013 15:04:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEEED40rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] response to REGISTRATION_REQ 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, 25 Jul 2013 15:04:47 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEED40rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repso= nses like accepted/denied by database? [...] As for possible responses to REGISTRATION_REQ, I have been planning to sugg= est this: I think we need a new generic error code "REGISTRATION_FAILED". = Perhaps a value -203, or the next available -200-block code. This should be used by the Database in response to a REGISTRATION_REQ if no= other more specific code is applicable. (For example: if a registration f= ailed due to a missing field in REGISTRATION_REQ, the Database should still= send the REQUIRED error; if a REGISTRATION_REQ failed due to the Device b= eing unauthorized, the Database should still send the UNAUTHORIZED error.) Sanjeev: does that address your need sentiment for "a denied registration"? Dan (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.) --_000_EC510C021D06A34C92F5A5A488B5290B0CEEED40rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sanjeev mentione= d:

 

From: sajeevmanikkoth@gmail.com
Sent: Th= ursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it= have repsonses like accepted/denied by database?

[...]

 

As = for possible responses to REGISTRATION_REQ, I have been planning to suggest= this:  I think we need a new generic error code “REGISTRATION_F= AILED”.  Perhaps a value -203, or the next available -200-block = code. 

 

This should be used by the Database in response to a REGISTR= ATION_REQ if no other more specific code is applicable.  (For example:= if a registration failed due to a missing field in REGISTRATION_REQ, the D= atabase should still send the REQUIRED  error; if a REGISTRATION_REQ f= ailed due to the Device being unauthorized, the Database should still send = the UNAUTHORIZED error.)

 

Sanjeev: does that address your need sentiment f= or “a denied registration”?

=  

Dan

 

(I have a separate comment = about SPECTRUM_USE_NOTIFY, to follow.)

<= o:p> 

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEED40rrcatsexmb2atsa_-- From sajeevmanikkoth@gmail.com Thu Jul 25 08:35:22 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 745D021F9A13 for ; Thu, 25 Jul 2013 08:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHlZuOR9eS99 for ; Thu, 25 Jul 2013 08:35:21 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 174ED21F9AEB for ; Thu, 25 Jul 2013 08:35:21 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so1826441pdd.34 for ; Thu, 25 Jul 2013 08:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=KLm5hHmzhqwn7wqsBrPoZxsdXmK6AsxWQMo6cl8nsuQ=; b=HM9w4MjY3S7ryUnn+L9IYKcELncBND5CH+IqBAatR+Soc49F/z54ainQTZOyielVbl D4A2ia0mBY374OPA81ATAb6Qrr0akl/cchgCj8bpyrGSVKRDy3WiEj50ZGskNxjmiIKq ZHSx4+OzYfkeqwYa1nYnyTt5jK6RS7ewuRn6O3rdwCzOggvKK5XIsKFewHAG8EgHB97v wysIBxpFOQQbfsszy8E8BavR2c2N7tD9otA+JMG/wFgMki5pQIQYBYiuTVuRoUFvXg6a qna9VPfonUpnKYkPo1OFVceURcRudFzkNJhpf2q/5jeU8h00ICNDPEbkd0RmOle8sbIp hhSA== X-Received: by 10.66.216.129 with SMTP id oq1mr7003708pac.75.1374766520784; Thu, 25 Jul 2013 08:35:20 -0700 (PDT) Received: from adminPC ([49.249.116.3]) by mx.google.com with ESMTPSA id ue9sm58400935pab.7.2013.07.25.08.35.17 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jul 2013 08:35:19 -0700 (PDT) From: "Sajeev Manikkoth" To: "'Harasty, Daniel J'" , References: In-Reply-To: Date: Thu, 25 Jul 2013 21:05:10 +0530 Message-ID: <004601ce894c$914b8b10$b3e2a130$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01CE897A.AB03C710" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6JSEc3pBd93CDZSJiynqW1sK69YwAAuk8Q Content-Language: en-us Subject: Re: [paws] response to REGISTRATION_REQ 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, 25 Jul 2013 15:35:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0047_01CE897A.AB03C710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Daniel, First of all thank you very much for streamlining my comments, and splitting it into separate email topics. May be I need to take care of it next time.. Yes, the semantic you suggest here also can be the solution. My point was, an authorized master's request also can fail, because of load at database, or due to request semantic error. As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a generic response accepted/denied. Best Regards, Sajeev From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Harasty, Daniel J Sent: Thursday, July 25, 2013 8:35 PM To: paws@ietf.org Subject: [paws] response to REGISTRATION_REQ Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database? [...] As for possible responses to REGISTRATION_REQ, I have been planning to suggest this: I think we need a new generic error code "REGISTRATION_FAILED". Perhaps a value -203, or the next available -200-block code. This should be used by the Database in response to a REGISTRATION_REQ if no other more specific code is applicable. (For example: if a registration failed due to a missing field in REGISTRATION_REQ, the Database should still send the REQUIRED error; if a REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still send the UNAUTHORIZED error.) Sanjeev: does that address your need sentiment for "a denied registration"? Dan (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.) ------=_NextPart_000_0047_01CE897A.AB03C710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Daniel,

 

First of all thank = you very much for streamlining my comments, and splitting it into separate email = topics. May be I need to take care of it next time..

 

Yes, the semantic you = suggest here also can be the solution. My point was, an authorized = master’s request also can fail, because of load at database, or due to request = semantic error.

As SPECTRUM_USE_NOTIFY also can fall in such a = category, I was suggesting a generic response accepted/denied.

 

Best Regards,

Sajeev

 

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: paws@ietf.org
Subject: [paws] response to = REGISTRATION_REQ

 

Sanjeev mentioned:

 

From: = sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like = accepted/denied by database?

[...]

 

As for possible responses to REGISTRATION_REQ, I = have been planning to suggest this:  I think we need a new generic error code “REGISTRATION_FAILED”.  Perhaps a value -203, or the = next available -200-block code. 

 

This should be used by the Database in response to = a REGISTRATION_REQ if no other more specific code is applicable.  = (For example: if a registration failed due to a missing field in = REGISTRATION_REQ, the Database should still send the REQUIRED  error; if a = REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still = send the UNAUTHORIZED error.)

 

Sanjeev: does that address your need sentiment for = “a denied registration”?

 

Dan

 

(I have a separate comment about = SPECTRUM_USE_NOTIFY, to follow.)

 

------=_NextPart_000_0047_01CE897A.AB03C710-- From vchen@google.com Thu Jul 25 08:43:02 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 2CE2E21F8C93 for ; Thu, 25 Jul 2013 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.297, 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 ye0pJULxwa5K for ; Thu, 25 Jul 2013 08:43:01 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 43B5921F8AF4 for ; Thu, 25 Jul 2013 08:43:01 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so4652852oag.4 for ; Thu, 25 Jul 2013 08:43:00 -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=24xeegkKG1boOSb2SwbwSfre43gJNKmvJUarG1OGHbE=; b=X/XKZ/JV5SBi5pgDio3BV840NGD/an0Ro1xPcuT/wH9pSMsUsC6QYFb/FgnpEB17rm 9SNTXBIMm0qfEm3zhO+h4N2cL/rO/zMK9/lUJi/SEAkd6tD/pfR5rinWOt6TMcsJWKGg ADrpdoyfhILA5HRQxJreSiuyJ3SjuWTUNk14SXwXDoeXSKtBUXAAhp4CwHl/XAbN2QmC O54vb6xfGxO7uF352FgqHytNN05ZZlHkqSr8QORWxjaAptlah8VBW2kYx7CDAaNIIbnB dHkY54ltVGBHaMr0IBe96qJUy1lAYCJTg9mST7gqTXd15AkDBIRTyMnLMs7CeUHYA0AJ ge0g== X-Google-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:x-gm-message-state; bh=24xeegkKG1boOSb2SwbwSfre43gJNKmvJUarG1OGHbE=; b=U56Pmwp51A1cJCmi9YcF0RDxBUjMrS5tm58fm/GamUttmZZnFCwRZkGTSBWerAm1vS Nyorf5UYgnr8fvWflYTO7H6VHC56gFXpZASvgiwuON2/AmhQaY3oMLSGqmKdHLH9eIwU x+8kuEEtkMgcYvdPrsMAZ7xnwfr0ck4TOTu5GYGv/YHxPwID/VlsFKV9jjhy2GfiZx3y IYxRTSvdtEcABfkT5vMqQ2bPci7gPcYEdaH8j+BatqtGFkV5K3QRiQw5OxCQGMdiU4oE Tn1XxjPliT7j5V9SDV0tBLYD+EIdXLlmzXVpegn3B0Hux+lfZFLZUxcAQ2sAxFjUKdJA eNsQ== MIME-Version: 1.0 X-Received: by 10.60.52.16 with SMTP id p16mr43058704oeo.29.1374766980635; Thu, 25 Jul 2013 08:43:00 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 25 Jul 2013 08:43:00 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> Date: Thu, 25 Jul 2013 08:43:00 -0700 Message-ID: From: Vincent Chen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=001a11330b2287d75e04e257e1d7 X-Gm-Message-State: ALoCoQmyniq4hEEcZTphJYR6g3/QpZkTEzxUxQGWL+b2B8BrjIZZ6vQUMALb9N+8NpwDmqYh97Kc+uIc5dGLrqDSRnhaxC4ZNinhg5SSsHkRaPTKYpIJvxu4jv83GqQuM6ZQFuAXub+4dyx/f+38BbTs5k415jjzdDbVUykIl/ZZcxe19GL5cQDMgYu2rav5t/wdwXfotA8r Cc: "paws@ietf.org" Subject: Re: [paws] definition of Slave device 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, 25 Jul 2013 15:43:02 -0000 --001a11330b2287d75e04e257e1d7 Content-Type: text/plain; charset=ISO-8859-1 This sounds reasonable. On Thu, Jul 25, 2013 at 7:44 AM, Harasty, Daniel J wrote: > I'd like to comment some of Sanjeev's input.**** > > ** ** > > I prefer to send independent replies on each topic, as that way a given > email thread is about a single topic (more or less).**** > > ** ** > > Sanjeev mentioned:**** > > ** ** > > From: sajeevmanikkoth@gmail.com > Sent: Thursday, July 25, 2013 10:31 AM**** > > [...]**** > > 1. Section 2.2 states Slave device as a device without geolocation > capability. I think the phrasing there need to be different. A Slave device > may or may not have geolocation capability, but does not directly query the > database. Also a mobile Slave device, can it not switch as master device in > adhoc? **** > > [...]**** > > ** ** > > I agree with the nature of his comment: a Slave device may well have > geolocation capabilities; however PAWS does not expect it needs to use them > to communicate with a Master device. I would support an update to the > definition of Slave.**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > -- -vince --001a11330b2287d75e04e257e1d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This sounds reasonable.

On Thu, Jul 25, 2013 at 7:44 AM, Harasty, = Daniel J <dharasty@appcomsci.com> wrote:

I'd like to comment some of Sanjeev&= #39;s input.

=A0

I prefer= to send independent replies on each topic, as that way a given email threa= d is about a single topic (more or less).

=A0

Sanjeev mentioned:

=A0

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

1. Section 2.2 states Slave device as a device= without geolocation capability. I think the phrasing there need to be diff= erent. A Slave device may or may not have geolocation capability, but does = not directly query the database. Also a mobile Slave device, can it not swi= tch as master device in adhoc?

[...]

=A0

I agree with the nature of his comment: a Slave device may well ha= ve geolocation capabilities; however PAWS does not expect it needs to use t= hem to communicate with a Master device.=A0 I would support an update to th= e definition of Slave.


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




--
-vince
--001a11330b2287d75e04e257e1d7-- From vchen@google.com Thu Jul 25 08:45:42 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 57D6F21F9AC1 for ; Thu, 25 Jul 2013 08:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.255, 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 lUsA-kURg4gT for ; Thu, 25 Jul 2013 08:45:41 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8597B21F9AD3 for ; Thu, 25 Jul 2013 08:45:37 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so4741689oag.33 for ; Thu, 25 Jul 2013 08:45:37 -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=gngj5yN0yYgQm0Kav6XxUxF4qG3syyeu39+oAUJd3Ug=; b=jfs4hVIBLdny7NZl/EDAe8HkgSDeu1VWX6AanzgyCChc7A9+oUuRTChPbPIZ5QH5nl xfY7Y0lCMQw1QdkXYOxUGT0tWhs707aArcLBP4a7a/lVOmQxJGSej6ip1UEcL8nSaehR ugt0FMnQfV6jbT9TM9VNYi9elY5I2cot12+ARhrDBzCSnEr6oLHsp/rN3C4yUafgSgXX AqGm7MOLx2gKVgyET7N9yt8NnO5ssGPVkXURSHpON98YnDt6W+KEX0YJ+/7i3tHzQDch c8+3ZhgNwe5kleZD8D5aFZKYXYRf/Le+ai1IhE592thxJNlQuSxGa7hCBOCd8CnpDV4I Gt0w== X-Google-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:x-gm-message-state; bh=gngj5yN0yYgQm0Kav6XxUxF4qG3syyeu39+oAUJd3Ug=; b=Q0s+muGVzfgo/pXzsXSrxP+aENPETUzYci95nh1PEYP/iZQJyt3U13e87B4kYjcetc XkAbv9IiqRuH42de6rwmVkm21/sbyufkhjeyqBzdebZPMfa5hlmph7yK/S7VOpVjlM/W kv75Cm/ta5Aw9vDHk8bmp7BfYqZ40axmQeGDHhjzhJTOE+XX+TzemCQclZR+yz5Sse5O EO0pwHilFZi8L6BCf9Gt/wSoCd0BdrXqq2wfpVwYBDdxSgIB7Mfcmsfbu31IdX++IS1l +XjTofpWYBTU9OCg+Jev5j+M4q2WhlJpl2XQ1NDvJIf27YaQNJIGJS/8VuruJa9Umg39 YvTw== MIME-Version: 1.0 X-Received: by 10.182.32.4 with SMTP id e4mr36888643obi.16.1374767136910; Thu, 25 Jul 2013 08:45:36 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 25 Jul 2013 08:45:36 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jul 2013 08:45:36 -0700 Message-ID: From: Vincent Chen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=089e013a1238d84e1504e257eab0 X-Gm-Message-State: ALoCoQlxHYEPjCoUYCBUa9WlSYAfFgi0tdZzfZ5HaYeuvmFoHxDfV6AaT42TYxa+6im4PQTqizz7cUMR9Fu5cV5jetzmEFVixga9d+TMemlttf6MJJoIxUJ6Cd246mEblcvGux9H3pYQlpeqL3YPab0dcA70Lffw1DMCmXkrtmkbkkfIC7FeGr2kY3U8ogSBpCc6mPEwEIrx Cc: "paws@ietf.org" Subject: Re: [paws] including a timestamp in every message 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, 25 Jul 2013 15:45:42 -0000 --089e013a1238d84e1504e257eab0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would agree with Dan. Given questionable reliability of time base on devices, the Database should not trust timestamps in the request, even when they are provided. Thus, it does seem like "chatter". -vince On Thu, Jul 25, 2013 at 7:51 AM, Harasty, Daniel J wrote: > I'd like to comment some of Sanjeev's input.**** > > ** ** > > I prefer to send independent replies on each topic, as that way a given > email thread is about a single topic (more or less).**** > > ** ** > > Sanjeev mentioned:**** > > ** ** > > From: sajeevmanikkoth@gmail.com > Sent: Thursday, July 25, 2013 10:31 AM**** > > [...]**** > > 2. It will be a good thing to include 'timestamp:string requirted' > paramter in all the protocol transactions **** > > [...]**** > > ** ** > > I don=92t see the purpose in this. I don=92t see how the operation of th= e > Database =96 or the way it will respond to any given request =96 is depen= dent > on it knowing what time the Device thinks it is. (Or vice versa.)**** > > ** ** > > Unless someone can point out a use case for this field, I consider it > unneeded =93chatter=94 in the protocol. That said, the Database or Devic= e can > easily ignore it, so I won=92t push back if others believe this field is > generally useful.**** > > ** ** > > Dan**** > > ** ** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --089e013a1238d84e1504e257eab0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I would agree with Dan. Given questionable reliability of = time base on devices, the Database should not trust timestamps in the reque= st, even when they are provided.
Thus, it does seem like "chatter&= quot;.

-vince


On Thu, Jul 25, 2013 at 7:51 AM, Harasty, Daniel J= <dharasty@appcomsci.com> wrote:

I'd like to comment some of Sanjeev&= #39;s input.

=A0

I prefer= to send independent replies on each topic, as that way a given email threa= d is about a single topic (more or less).

=A0

Sanjeev mentioned:

=A0

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

2. It will be a good thing to include 'tim= estamp:string requirted' paramter in all the protocol transactions <= /u>

[...]

=A0

I don=92t see the purpose in this.=A0 I don=92t see how th= e operation of the Database =96 or the way it will respond to any given req= uest =96 is dependent on it knowing what time the Device thinks it is.=A0 (= Or vice versa.)

=A0

Unless s= omeone can point out a use case for this field, I consider it unneeded =93c= hatter=94 in the protocol.=A0 That said, the Database or Device can easily = ignore it, so I won=92t push back if others believe this field is generally= useful.

=A0

Dan

=A0

=A0


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




--
-vince
--089e013a1238d84e1504e257eab0-- From vchen@google.com Thu Jul 25 09:00: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 66E0321F95DC for ; Thu, 25 Jul 2013 09:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.223, 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 oW9XeNYdMMub for ; Thu, 25 Jul 2013 09:00:43 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 969CF21F9AA1 for ; Thu, 25 Jul 2013 09:00:32 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so1908206obb.33 for ; Thu, 25 Jul 2013 09:00:31 -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=lIA1yCQ2f4AXbrvqmkz8dRq+1eVz2UYdoXbcltnTiuw=; b=eniMV25kw88JpHzQ/tQLqv1L4dLvs4RfgFs5nWkUuohPZSqUeEOi/bHhxjFkEQOkR8 LLE8LCVgdHnVdpJiVsL+w/ob76LEPZRtXV/BB6V2d84GSIc3d2lIMc710U3PFnIiXF03 VPd411ZbR8MucmXlLQ0DKtESZPNLGz7j90wasiKLRU9/TGr0UuhkG5ZanNM/1eI8hvBi ZeTQfpD23+qzbvCidVaGatscj35nUDA+M+tlkC0MO2H3SrXiYdPns5pLqWmVu2wboCru PE2ytsythWlBnSFEvG0NUQatjeIYPYMzOfDL9Uc9F7KdSiZRZaYMPUAxoRcFO8zyOAJE QWMQ== X-Google-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:x-gm-message-state; bh=lIA1yCQ2f4AXbrvqmkz8dRq+1eVz2UYdoXbcltnTiuw=; b=kkfyWeIrWqLgF/g382dx98zh8o/ayeIwssLg17sOQLtrv3pcPaLmN6ScKn5Qn237+v Teufey5047I9ZpV8MA7ImvOrRFQzYNYAmwRSzZPBdxp2iRsa/eGtfaQmKQOog6EXDCLk Wkt+59n0eW59RQ1Br5cceIEnJJgNMnPboZhXmYqilBsYVgBGCQV+JyNc0br1i2aRSyps BwqqJLeXSUUJ680IeYQb9fLleIvNSDaK0bqsEXE8y9Xf+Fzu3dVTPiWDyiCSAXbXJsSw N/RbIaGJOTHKkPCrVS4hPFtXr8c4ZctU1SscBzbVaW4SVFO9ytBpotiwgpgVA+jFYHgE XS7g== MIME-Version: 1.0 X-Received: by 10.182.225.134 with SMTP id rk6mr36874572obc.40.1374768029945; Thu, 25 Jul 2013 09:00:29 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 25 Jul 2013 09:00:29 -0700 (PDT) In-Reply-To: <004601ce894c$914b8b10$b3e2a130$@com> References: <004601ce894c$914b8b10$b3e2a130$@com> Date: Thu, 25 Jul 2013 09:00:29 -0700 Message-ID: From: Vincent Chen To: Sajeev Manikkoth Content-Type: multipart/alternative; boundary=001a11c2f80012f0d404e25820fa X-Gm-Message-State: ALoCoQmFvXfTrxxsM+XHZvOc4xmOQRC8IDCeTSU0OhPnv8fzG53meSnQowisRsMb87BGaMOMINCwyfGjwev8uWGg8erfsyRN/dNgoOECi9iZL54x+EjplvbtPNGn8KcBhV8TXe+mnvkiPGkciDLh5M516M4oncJ+GMSKkxBmsgwn91M8I7l5CH79b/P1HB9NzCj6vcKXmJty Cc: "paws@ietf.org" Subject: Re: [paws] response to REGISTRATION_REQ 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, 25 Jul 2013 16:00:44 -0000 --001a11c2f80012f0d404e25820fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dan, Sajeev, I was assuming that general "server errors" would be handled at the HTTP layer with 5xx codes. 1. For REGISTRATION_REQ, what error conditions should we be capturing? - Some internal error, but can try again later? 2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did get an error? I was assuming that this is a async notify, fire-and-forget, from the perspective of the device -vince On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth wrote: > Hi Daniel,**** > > ** ** > > First of all thank you very much for streamlining my comments, and > splitting it into separate email topics. May be I need to take care of it > next time..**** > > ** ** > > Yes, the semantic you suggest here also can be the solution. My point was= , > an authorized master=92s request also can fail, because of load at databa= se, > or due to request semantic error. **** > > As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting > a generic response accepted/denied.**** > > ** ** > > Best Regards,**** > > Sajeev**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Harasty, Daniel J > *Sent:* Thursday, July 25, 2013 8:35 PM > *To:* paws@ietf.org > *Subject:* [paws] response to REGISTRATION_REQ**** > > ** ** > > Sanjeev mentioned:**** > > ** ** > > From: sajeevmanikkoth@gmail.com > Sent: Thursday, July 25, 2013 10:31 AM**** > > [...]**** > > 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have > repsonses like accepted/denied by database?**** > > [...]**** > > ** ** > > As for possible responses to REGISTRATION_REQ, I have been planning to > suggest this: I think we need a new generic error code > =93REGISTRATION_FAILED=94. Perhaps a value -203, or the next available > -200-block code. **** > > ** ** > > This should be used by the Database in response to a REGISTRATION_REQ if > no other more specific code is applicable. (For example: if a registrati= on > failed due to a missing field in REGISTRATION_REQ, the Database should > still send the REQUIRED error; if a REGISTRATION_REQ failed due to the > Device being unauthorized, the Database should still send the UNAUTHORIZE= D > error.)**** > > ** ** > > Sanjeev: does that address your need sentiment for =93a denied registrati= on=94? > **** > > ** ** > > Dan**** > > ** ** > > (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.)**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --001a11c2f80012f0d404e25820fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Dan, Sajeev,

I was assuming that genera= l "server errors" would be handled at the HTTP layer with 5xx cod= es.

1. For REGISTRATION_REQ, what error conditions= should we be capturing?
=A0 =A0- Some internal error, but can try again later?

<= /div>
2. SPECTRUM_USE_NOTIFY. What would the device do differently if i= t did get an error?
=A0 I was assuming that this is a async notif= y, fire-and-forget, from the perspective of the device

-vince


On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth = <sajeevmanikkoth@gmail.com> wrote:

Hi Daniel,

=A0

First of all thank you= very much for streamlining my comments, and splitting it into separate email topics. = May be I need to take care of it next time..

=A0

Yes, the semantic you = suggest here also can be the solution. My point was, an authorized master=92s request also can fail, because of load at database, or due to request seman= tic error.

As SPECTRUM_USE_NOTIFY also can fall in such a categ= ory, I was suggesting a generic response accepted/denied.

=A0

Best Regards,

Sajeev

=A0

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: paws@ietf.org=
Subject: [paws] response to REGISTRATION_REQ

=A0

Sanjeev mentioned:

=A0

From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied= by database?

[...]

=A0

As for possible responses to REGISTRATION_REQ, I hav= e been planning to suggest this: =A0I think we need a new generic error code =93REGISTRATION_FAILED=94.=A0 Perhaps a value -203, or the next available -200-block code.=A0

=A0

This should be used by the Database in response to a REGISTRATION_REQ if no other more specific code is applicable.=A0 (For example: if a registration failed due to a missing field in REGISTRATION_RE= Q, the Database should still send the REQUIRED =A0error; if a REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still send= the UNAUTHORIZED error.)

=A0

Sanjeev: does that address your need sentiment for = =93a denied registration=94?

=A0

Dan

=A0

(I have a separate comment about SPECTRUM_USE_NOTIFY= , to follow.)

=A0


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




--
-vince
--001a11c2f80012f0d404e25820fa-- From osianoh.glenn.aliu@fokus.fraunhofer.de Thu Jul 25 09:33:00 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 42E1D21F86BE for ; Thu, 25 Jul 2013 09:33:00 -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 VxZwOGMkiJks for ; Thu, 25 Jul 2013 09:32:53 -0700 (PDT) Received: from mx-relay04-dus.antispameurope.com (mx-relay10-dus.antispameurope.com [94.100.134.210]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7BB21F8618 for ; Thu, 25 Jul 2013 09:32:50 -0700 (PDT) Received: from pluto.fokus.fraunhofer.de ([195.37.77.164]) by mx-gate04-dus.antispameurope.com; Thu, 25 Jul 2013 18:32:46 +0200 Received: from DIRAC.fokus.fraunhofer.de (dirac.fokus.fraunhofer.de [10.147.9.201]) by pluto.fokus.fraunhofer.de (8.14.4/8.14.2) with ESMTP id r6PGWgmD006299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 25 Jul 2013 18:32:43 +0200 (CEST) Received: from CURIE.fokus.fraunhofer.de ([fe80::490a:48a1:1edc:a241]) by DIRAC.fokus.fraunhofer.de ([::1]) with mapi id 14.03.0123.003; Thu, 25 Jul 2013 18:30:43 +0200 From: "Aliu, Osianoh Glenn" To: "Harasty, Daniel J" , "paws@ietf.org" Thread-Topic: [paws] including a timestamp in every message Thread-Index: AQHOiUyaXzQ+l1mTAUegZTKQKnWL8Jl1lH/w Date: Thu, 25 Jul 2013 16:30:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.112.106] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_D8A0D535AD9ECC42A8D92697F56760D1287987FCCURIEfokusfraun_" MIME-Version: 1.0 X-cloud-security-sender: osianoh.glenn.aliu@fokus.fraunhofer.de X-cloud-security-recipient: paws@ietf.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate04-dus with E01AF3880014 X-cloud-security-connect: pluto.fokus.fraunhofer.de[195.37.77.164], TLS=, IP=195.37.77.164 X-cloud-security: scantime:.1688 Subject: Re: [paws] including a timestamp in every message 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, 25 Jul 2013 16:33:00 -0000 --_000_D8A0D535AD9ECC42A8D92697F56760D1287987FCCURIEfokusfraun_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daniel, I would suggest the field be left there as it can be used by the database f= or security and ensuring devices adhere to frequency requirements of queryi= ng the database. Using the timestamp field, I would assume the database can easily detect if= a device is attempting a flooding attack. Kind Regards, Glenn From: Harasty, Daniel J [mailto:dharasty@appcomsci.com] Sent: Thursday, July 25, 2013 4:51 PM To: paws@ietf.org Subject: [paws] including a timestamp in every message I'd like to comment some of Sanjeev's input. I prefer to send independent replies on each topic, as that way a given ema= il thread is about a single topic (more or less). Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 2. It will be a good thing to include 'timestamp:string requirted' paramter= in all the protocol transactions [...] I don't see the purpose in this. I don't see how the operation of the Data= base - or the way it will respond to any given request - is dependent on it= knowing what time the Device thinks it is. (Or vice versa.) Unless someone can point out a use case for this field, I consider it unnee= ded "chatter" in the protocol. That said, the Database or Device can easil= y ignore it, so I won't push back if others believe this field is generally= useful. Dan --_000_D8A0D535AD9ECC42A8D92697F56760D1287987FCCURIEfokusfraun_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daniel,<= /span>

I would suggest the fi= eld be left there as it can be used by the database for security and ensuri= ng devices adhere to frequency requirements of querying the database.<= /o:p>

 

Using the timestamp fi= eld, I would assume the database can easily detect if a device is attemptin= g a flooding attack.

 

Kind Regards,

Glenn

 

From: Harasty, Daniel J [mailto:dharasty@appc= omsci.com]
Sent: Thursday, July 25, 2013 4:51 PM
To: paws@ietf.org
Subject: [paws] including a timestamp in every message

 

I'd like to comment some of Sanjeev's input.

 

I prefer to send independent replies on each topic, = as that way a given email thread is about a single topic (more or less).

 

Sanjeev mentioned:

 

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

2. It will be a good thin= g to include 'timestamp:string requirted' paramter in all the protocol tran= sactions

[...]

 

I don’t see the purpose in this.  I don&#= 8217;t see how the operation of the Database – or the way it will res= pond to any given request – is dependent on it knowing what time the = Device thinks it is.  (Or vice versa.)

 

Unless someone can point out a use case for this fie= ld, I consider it unneeded “chatter” in the protocol.  Tha= t said, the Database or Device can easily ignore it, so I won’t push = back if others believe this field is generally useful.

 

Dan

 

 

--_000_D8A0D535AD9ECC42A8D92697F56760D1287987FCCURIEfokusfraun_-- From dharasty@appcomsci.com Thu Jul 25 12:09:02 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 66F4A21F9476 for ; Thu, 25 Jul 2013 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 UmOzNiUgpO9C for ; Thu, 25 Jul 2013 12:08:57 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1367921F93BF for ; Thu, 25 Jul 2013 12:08:55 -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 r6PJ8s78013048 for ; Thu, 25 Jul 2013 15:08:54 -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 r6PJ8srg012875 for ; Thu, 25 Jul 2013 15:08:54 -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, 25 Jul 2013 15:08:54 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: [paws] including a timestamp in every message Thread-Index: AQHOiVSc9EDxhQZ4AEahdC9AATK9AJl1r84w Date: Thu, 25 Jul 2013 19:08:53 +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_EC510C021D06A34C92F5A5A488B5290B0CEEF13Drrcatsexmb2atsa_" MIME-Version: 1.0 Subject: Re: [paws] including a timestamp in every message 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, 25 Jul 2013 19:09:02 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF13Drrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glenn, Thank you for the input. But I'm still confused. It sounds like what you = are calling a "flooding attack" might be where the device is sending many m= any requests at once, attempting (what I would call) a denial of service at= tack. I don't understand how a timestamp helps a database detect/avoid this. For= one: if a Device is purposely misbehaving (by attempting a "flooding" atta= ck), and it "knows" that the server will observe the timestamp and some alg= orithm to detect such an attack, then why do we trust that it will send acc= urate timestamps? In other words" requiring an accurate "timestamp" field is likely to be as = effective as the spec simply stating "Devices MUST NOT perform flooding att= acks". Unless PAWS introduces a unique, new attack vector or vulnerability, then I= think the means to detect/avoid a generic denial of service-type attack is= to rely on previously well-known methods, such as discussed in http://en.w= ikipedia.org/wiki/Denial-of-service_attack#Handling. -- Dan From: Aliu, Osianoh Glenn [mailto:osianoh.glenn.aliu@fokus.fraunhofer.de] Sent: Thursday, July 25, 2013 12:31 PM To: Harasty, Daniel J; paws@ietf.org Subject: RE: [paws] including a timestamp in every message Hi Daniel, I would suggest the field be left there as it can be used by the database f= or security and ensuring devices adhere to frequency requirements of queryi= ng the database. Using the timestamp field, I would assume the database can easily detect if= a device is attempting a flooding attack. Kind Regards, Glenn From: Harasty, Daniel J [mailto:dharasty@appcomsci.com] Sent: Thursday, July 25, 2013 4:51 PM To: paws@ietf.org Subject: [paws] including a timestamp in every message I'd like to comment some of Sanjeev's input. I prefer to send independent replies on each topic, as that way a given ema= il thread is about a single topic (more or less). Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 2. It will be a good thing to include 'timestamp:string requirted' paramter= in all the protocol transactions [...] I don't see the purpose in this. I don't see how the operation of the Data= base - or the way it will respond to any given request - is dependent on it= knowing what time the Device thinks it is. (Or vice versa.) Unless someone can point out a use case for this field, I consider it unnee= ded "chatter" in the protocol. That said, the Database or Device can easil= y ignore it, so I won't push back if others believe this field is generally= useful. Dan --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF13Drrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glenn,

 

Thank you for the input.  But I’m still c= onfused.  It sounds like what you are calling a “flooding attack= ” might be where the device is sending many many requests at once, at= tempting (what I would call) a denial of service attack.<= /p>

 

I don’t und= erstand how a timestamp helps a database detect/avoid this.  For one: = if a Device is purposely misbehaving (by attempting a “flooding”= ; attack), and it “knows” that the server will observe the time= stamp and some algorithm to detect such an attack, then why do we trust tha= t it will send accurate timestamps?

 

In other words” requiring an acc= urate “timestamp” field is likely to be as effective as the spe= c simply stating “Devices MUST NOT perform flooding attacks”.

 

= Unless PAWS introduces a unique, new attack vector or vulnerability, then I= think the means to detect/avoid a generic denial of service-type attack is= to rely on previously well-known methods, such as discussed in http= ://en.wikipedia.org/wiki/Denial-of-service_attack#Handling.

 

-- Dan

 

 

<= p class=3DMsoNormal>From: Aliu, Osianoh Glenn [mailto:osianoh.glenn.aliu@foku= s.fraunhofer.de]
Sent: Thursday, July 25, 2013 12:31 PM
To= : Harasty, Daniel J; paws@ietf.org
Subject: RE: [paws] includ= ing a timestamp in every message

 

Hi Daniel,

I would suggest the field be left there as it can be use= d by the database for security and ensuring devices adhere to frequency req= uirements of querying the database.

 

Using the timestamp field, I would ass= ume the database can easily detect if a device is attempting a flooding att= ack.

 

Kind Regards,

Glenn

 

From: Harasty, Daniel J [mailto:dharasty@appcomsci.com]
Sent: Thursday, J= uly 25, 2013 4:51 PM
To: paws@ie= tf.org
Subject: [paws] including a timestamp in every message=

 

I'd like to comment some of Sanjeev's input.

<= p class=3DMsoNormal> 

I prefer to s= end independent replies on each topic, as that way a given email thread is = about a single topic (more or less).

 

Sanjeev mentioned:

 

From: sajeevmanikk= oth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

<= p class=3DMsoNormal style=3D'margin-left:.5in'>[...]

2. It will be a good thing to inclu= de 'timestamp:string requirted' paramter in all the protocol transactions <= o:p>

[...]

 

I don’t see the purpose in this.  I don= 217;t see how the operation of the Database – or the way it will resp= ond to any given request – is dependent on it knowing what time the D= evice thinks it is.  (Or vice versa.)

 

Unless someone can point out a= use case for this field, I consider it unneeded “chatter” in t= he protocol.  That said, the Database or Device can easily ignore it, = so I won’t push back if others believe this field is generally useful= .

 

Dan

 

 

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF13Drrcatsexmb2atsa_-- From dharasty@appcomsci.com Thu Jul 25 12:24:30 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 8FCEE21F9133 for ; Thu, 25 Jul 2013 12:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, 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 SvHNJQIUiSZf for ; Thu, 25 Jul 2013 12:24:25 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 933A221F90A7 for ; Thu, 25 Jul 2013 12:24:25 -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 r6PJON23013196; Thu, 25 Jul 2013 15:24:23 -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 r6PJON1N012960; Thu, 25 Jul 2013 15:24:23 -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, 25 Jul 2013 15:24:23 -0400 From: "Harasty, Daniel J" To: Vincent Chen , Sajeev Manikkoth Thread-Topic: [paws] response to REGISTRATION_REQ Thread-Index: AQHOiUyZwfgC+JHDyUqaANXSQyM5iZl10J+A///y34A= Date: Thu, 25 Jul 2013 19:24:22 +0000 Message-ID: References: <004601ce894c$914b8b10$b3e2a130$@com> 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_EC510C021D06A34C92F5A5A488B5290B0CEEF193rrcatsexmb2atsa_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] response to REGISTRATION_REQ 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, 25 Jul 2013 19:24:30 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF193rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, On your "point 1", I thought I had some good examples in mind. But, now th= at you ask, I can't yet make the case that my proposed PAWS "REGISTRATION_E= RROR" is any better than other existing PAWS error codes, or a generic "ser= ver error". While the Devices certainly must deal with the possible HTTP 5xx error, I s= uggest the server should attempt to send a JSONRPC "SERVER ERROR" (-32000).= See: http://www.jsonrpc.org/specification#error_object. I'd like to reco= mmend that the PAWS spec reference these "standard JSONRPC error codes", an= d add a statement to the effect of this: When an error condition exists, a Database SHOULD attempt to use the most s= pecific applicable PAWS error. When an accurate one is not available, it S= HOULD fallback to standard JSONRPC error codes as defined in JSONRPC specif= ications. As a last result, the Database MAY send a suitable HTTP 5xx resp= onse. Dan From: Vincent Chen [mailto:vchen@google.com] Sent: Thursday, July 25, 2013 12:00 PM To: Sajeev Manikkoth Cc: Harasty, Daniel J; paws@ietf.org Subject: Re: [paws] response to REGISTRATION_REQ Dan, Sajeev, I was assuming that general "server errors" would be handled at the HTTP la= yer with 5xx codes. 1. For REGISTRATION_REQ, what error conditions should we be capturing? - Some internal error, but can try again later? 2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did get = an error? I was assuming that this is a async notify, fire-and-forget, from the per= spective of the device -vince On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth > wrote: Hi Daniel, First of all thank you very much for streamlining my comments, and splittin= g it into separate email topics. May be I need to take care of it next time= .. Yes, the semantic you suggest here also can be the solution. My point was, = an authorized master's request also can fail, because of load at database, = or due to request semantic error. As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a= generic response accepted/denied. Best Regards, Sajeev From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Harasty, Daniel J Sent: Thursday, July 25, 2013 8:35 PM To: paws@ietf.org Subject: [paws] response to REGISTRATION_REQ Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repso= nses like accepted/denied by database? [...] As for possible responses to REGISTRATION_REQ, I have been planning to sugg= est this: I think we need a new generic error code "REGISTRATION_FAILED". = Perhaps a value -203, or the next available -200-block code. This should be used by the Database in response to a REGISTRATION_REQ if no= other more specific code is applicable. (For example: if a registration f= ailed due to a missing field in REGISTRATION_REQ, the Database should still= send the REQUIRED error; if a REGISTRATION_REQ failed due to the Device b= eing unauthorized, the Database should still send the UNAUTHORIZED error.) Sanjeev: does that address your need sentiment for "a denied registration"? Dan (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.) _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF193rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,

 

=

On your “point 1”, I thought I had = some good examples in mind.  But, now that you ask, I can’t yet = make the case that my proposed PAWS “REGISTRATION_ERROR” is any= better than other existing PAWS error codes, or a generic “server er= ror”.

 

While the Devices certainly must = deal with the possible HTTP 5xx error, I suggest the server should attempt = to send a JSONRPC “SERVER ERROR” (-32000).  See: http://www.jsonrpc.o= rg/specification#error_object.  I’d like to recommend that t= he PAWS spec reference these “standard JSONRPC error codes”, an= d add a statement to the effect of this:

 

When an error condition exists, a Database SHOULD at= tempt to use the most specific applicable PAWS error.  When an accurat= e one is not available, it SHOULD fallback to standard JSONRPC error codes = as defined in JSONRPC specifications.  As a last result, the Database = MAY send a suitable HTTP 5xx response.

 

Dan<= o:p>

 

 

From: Vincent Chen [mailto:vchen@google.com]
Sent: Th= ursday, July 25, 2013 12:00 PM
To: Sajeev Manikkoth
Cc:= Harasty, Daniel J; paws@ietf.org
Subject: Re: [paws] response to= REGISTRATION_REQ

&nbs= p;

Dan, Sajeev,

 

I was = assuming that general "server errors" would be handled at the HTT= P layer with 5xx codes.

=  

1. For REGISTRATION_REQ, wh= at error conditions should we be capturing?

   - Some internal error, but can try again later?=

 

<= div>

2. SPECTRUM_USE_NOTIFY. What would the device do d= ifferently if it did get an error?

  I was assuming that this is a async notify, fire-and-forget, f= rom the perspective of the device

 

-vince=

 

On Thu, Jul 25, 2013 at 8:35 A= M, Sajeev Manikkoth <sajeevmanikkoth@gmail.com> wrote:

Hi Daniel,

 

First of all thank you very much for streamlining my= comments, and splitting it into separate email topics. May be I need to ta= ke care of it next time..

 

Yes, the semantic you suggest here also can be the solution. My point was,= an authorized master’s request also can fail, because of load at dat= abase, or due to request semantic error.

As SP= ECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a gene= ric response accepted/denied.

 

Best Regards,

Sajeev

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of Harasty, Daniel J
Se= nt: Thursday, July 25, 2013 8:35 PM
To: paws@ietf.org
Subject: [paws] r= esponse to REGISTRATION_REQ

 

Sanjeev mentioned:

&nbs= p;

From: sajeevmanikkoth@gmail.com
Sent: T= hursday, July 25, 2013 10:31 AM

[...]=

5. REGISTRATION_REQ, and SPECTRUM_US= E_NOTIFY transctions; can it have repsonses like accepted/denied by databas= e?

[...]

 

As for possible responses to REGISTRA= TION_REQ, I have been planning to suggest this:  I think we need a new= generic error code “REGISTRATION_FAILED”.  Perhaps a valu= e -203, or the next available -200-block code. 

=  

This should be used by the Database in response= to a REGISTRATION_REQ if no other more specific code is applicable.  = (For example: if a registration failed due to a missing field in REGISTRATI= ON_REQ, the Database should still send the REQUIRED  error; if a REGIS= TRATION_REQ failed due to the Device being unauthorized, the Database shoul= d still send the UNAUTHORIZED error.)

 

Sanjeev: does that address your need sentiment for “a den= ied registration”?

 

D= an

 

(I have a separate comm= ent about SPECTRUM_USE_NOTIFY, to follow.)

 =


_______________________________________________
paws mail= ing list
paws@ietf.org
https://w= ww.ietf.org/mailman/listinfo/paws



 = ;

--
-vince

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF193rrcatsexmb2atsa_-- From dharasty@appcomsci.com Thu Jul 25 13:06:38 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 EC76C21F9377 for ; Thu, 25 Jul 2013 13:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AHQ6giUO9PK for ; Thu, 25 Jul 2013 13:06:33 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 817D721F9344 for ; Thu, 25 Jul 2013 13:06:30 -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 r6PK6RfH013672 for ; Thu, 25 Jul 2013 16:06:29 -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 r6PK6R38013302 for ; Thu, 25 Jul 2013 16:06:27 -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, 25 Jul 2013 16:06:26 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: SPECTRUM_USE_NOTIFY: nomenclature and response Thread-Index: Ac6JcnEannpwjoqiRdOtljZ3jG31TQ== Date: Thu, 25 Jul 2013 20:06:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEEF266rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 25 Jul 2013 20:06:39 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF266rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repso= nses like accepted/denied by database? [...] The JSONRPC spec defines a "notification" as a type of request that needs n= o response; in fact a response is not even allowed. Since the PAWS SPECTRUM_USE_NOTIFY is "this kind of message" semantically (= note that SPECTRUM_USE_RESP is empty), I propose we: * State that the SPECTRUM_USE_NOTIFY uses the JSONRPC "Notification= " Request object (see: http://www.jsonrpc.org/specification#notification), = and * That we eliminate the SPECTRUM_USE_RESP from the PAWS spec. This is consistent with Vince's characterization that SPECTRUM_USE_NOTIFY i= s an "async notify, fire-and-forget, from the perspective of the device". Thoughts? Dan Harasty --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF266rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sanjeev mentione= d:

 

From: sajeevmanikkoth@gmail.com
Sent: Th= ursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it= have repsonses like accepted/denied by database?

[...]

 

The= JSONRPC spec defines a “notification” as a type of request tha= t needs no response; in fact a response is not even allowed.

=

 

Since the PA= WS SPECTRUM_USE_NOTIFY is “this kind of message” semantically (= note that SPECTRUM_USE_RESP is empty), I propose we:

 

·       &n= bsp; State that the SPECTRUM_USE_NOTIFY uses= the JSONRPC “Notification” Request object (see: http://www.jsonrpc.org/spec= ification#notification), and

= ·=      =     That we eliminate the SPE= CTRUM_USE_RESP from the PAWS spec.

=  

This is consistent with Vince’s = characterization that SPECTRUM_USE_NOTIFY is an  “async notify, = fire-and-forget, from the perspective of the device”.

<= p class=3DMsoNormal> 

Thoughts?

 

D= an Harasty

 

 

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF266rrcatsexmb2atsa_-- From vchen@google.com Thu Jul 25 13:26: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 DD6F021F8887 for ; Thu, 25 Jul 2013 13:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.779 X-Spam-Level: X-Spam-Status: No, score=-1.779 tagged_above=-999 required=5 tests=[AWL=0.198, 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 bI3+Gt7x5kgy for ; Thu, 25 Jul 2013 13:26:29 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB7521F847C for ; Thu, 25 Jul 2013 13:26:29 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id er7so2562060obc.18 for ; Thu, 25 Jul 2013 13:26:28 -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=UJgS2pjD4tLEvi1SktDWVwHZawJXlZze7AVzCDl4M9M=; b=lREXPeXzTMn6Z5kLwQYZFTD9pMFPqSd4MrjaZC9/b4bZjtp9XiVyG659To0Ab8NJXx invzWHdcyEwmNiP8QQ8UEbjZ/U4Q42agIN1X1O/5QSlgAoKv/Ke/AkPlvt1zjmGPiuY7 b+sc7ggUbijHZ0xGF8zrdUvII2WzIRU3v77r/AfXyQDtBuFZwRC43sRpG3XUeBL2Rs8S a786azl2egIHQsRLhEUam/6UkVyKr1ey31uRbMrMbqpYjQxqdcDDeSowVDaqINwueluf WZNA7coouaIlUXmYQwx67FvqUNNK1vsJtzvsMy6m+mSGILlVwYQhB+CQuKGubYs6tGKc tZ5Q== X-Google-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 :x-gm-message-state; bh=UJgS2pjD4tLEvi1SktDWVwHZawJXlZze7AVzCDl4M9M=; b=YWO7JXhRFzlsedAd2DssAb9Nl7XNTuf5orPUyHN3fVpTPncUmtW4gd/hCrqEzgLXzE wWn8zn5POUanI4CBD6hvCC6FY9KJKGVpdDhyBn3Du60Qlk1Z8xw1M4WUDqCdAoSa1ilR yNM2up9gGn9mZpPujbD18sjT19TnV63axRbmuLQzlUfG9O8FtavFPz7GpmEZs8eTfTag UVH+pgtRW9aigOeylLtZoI0+2+utH3FJMJRTJ40xPW06YrtkL+pW2FnlUFtXcdYZvLan qcNKaEke4qyRcaIS+lZW7jMiRSbLw4bdSyfkTArg8o/5ZIQvdgvTg9QVt+ysuhbR7Wr+ p8HA== MIME-Version: 1.0 X-Received: by 10.60.131.171 with SMTP id on11mr44303587oeb.71.1374783988823; Thu, 25 Jul 2013 13:26:28 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 25 Jul 2013 13:26:28 -0700 (PDT) Date: Thu, 25 Jul 2013 13:26:28 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" , Sung-jin Yoo Content-Type: multipart/alternative; boundary=047d7b471da44c183804e25bd72a X-Gm-Message-State: ALoCoQkStet/y0m9ZwR7LymJVIhzXsYCgVqN9ndRL6wxrbkgeNtJqmXFNFDPIHaYpdX5fAIOl7liHRLA5fVnbJgH8MhW1iWv/+tVAqIze3UQvzvUC6/TUQy/JpGQ7B9pK8ly6VRQl9ep4xjzBKsSbdXYgMHvA5gHnQC+L5YdqJoVWXWUyX8xi+QAX54gRb74KWr9iziAEYsn Subject: [paws] Proposal: Rename maxPowerDBm in Available-spectrum response 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, 25 Jul 2013 20:26:30 -0000 --047d7b471da44c183804e25bd72a Content-Type: text/plain; charset=ISO-8859-1 Sungjin, All, Part of the confusion of how to interpret the available-spectrum response, perhaps, is in the naming of the "maxPowerDBm" variable. E.g., "spectra": [ { "bandwidth": 6e6, "frequencyRanges": [ {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, ... ] }, { "bandwidth": 1e5, "frequencyRanges": [ {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, ... ] } Given that this power really represents "power spectral density" over the specified bandwidth (e.g., 6e6 or 1e5), should we rename it to something like the following? maxPsdDbmPerBandwidth Where "bandwidth" refers to the bandwidth specified for that spectrum profile. -- -vince --047d7b471da44c183804e25bd72a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --001a11c2e128fef96104e26d39f3-- From vchen@google.com Fri Jul 26 10:13:08 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 C299121F9928 for ; Fri, 26 Jul 2013 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.127, 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 Kk6ojPRH+gz4 for ; Fri, 26 Jul 2013 10:13:08 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 18F2421F979E for ; Fri, 26 Jul 2013 10:13:07 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i10so2849064oag.2 for ; Fri, 26 Jul 2013 10:13:07 -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=jHl1v8FScHPxmLqHGogMmeClaF9atBWxn5AlxDinDYY=; b=oNMJ1ZNgYkfFQScD0hxk6KkoO0kL8UQ2tFUgMxeIhBIpWryYXdnol/Dlj6/EJLiURN 38jc36MR4tOfk8CrXqizqJY4RIkBWyCLQNqgrJoLr7mcAGcneG4RYNVvR5fCxfJ15yJ/ ggdildP2kGfNFdK6gwJ1uLRj5A84itcj2M868dJzGhccHE2ITHrsAiR5iEQjwbiay4eR QfYCZxB+PSMdzfBu2arlqJ8nzAgpJKgDx5doQppxx1kA84EejjOGm+VlqEpAwrxnHuTh fV2AfNi10CkV+Jp5uHSsqqXEnGsl4B+BRo0YBOzNalDgPB+Vqr/7/tHOU8wyKEN3KDl1 poQw== X-Google-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:x-gm-message-state; bh=jHl1v8FScHPxmLqHGogMmeClaF9atBWxn5AlxDinDYY=; b=akANL6diEMtJKwPi24IBgEh58RrVRxRDbV6nO6+RolBXZq/++560yj487tApi0BqcG i6DwqEL4kkTxg9CnjlwzcyllfUmQGDJq+NBoeGDZMqJaPUvC1bw64wxgT1Rn/JLQcesM k+/2SSQnfw3ZzhSLoiUrxvVl+VTDSUarFAVGcqpNoIiQukVMAk8UubbooBBHF1GI0yH8 FEN0IP/2FGrY3DBD0MxrH+vtXnvSChvtrZdv9jnb5k2KjNMNB7oM1M3WeCVddeuYyIGa 6T5IqmnWb8u5jC3QTo2YEqDHzrycxBADg8X1KmUAnhgBkvKXC59g5AHuZy2Zug63gxTB F+Og== MIME-Version: 1.0 X-Received: by 10.60.83.116 with SMTP id p20mr48252002oey.83.1374858787199; Fri, 26 Jul 2013 10:13:07 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Fri, 26 Jul 2013 10:13:07 -0700 (PDT) In-Reply-To: <1374858474.1735.73.camel@localhost> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991@wds-exc1.okna.nominet.org.uk> <1374858474.1735.73.camel@localhost> Date: Fri, 26 Jul 2013 10:13:07 -0700 Message-ID: From: Vincent Chen To: Rex Buddenberg Content-Type: multipart/alternative; boundary=089e0118266aa0b4b004e26d417e X-Gm-Message-State: ALoCoQnfpbDewCJn3Ih5g/F/imWIOwI1OA9Sa0xEprE9R0H2okBRozKL1FHSungiCeTHDNJu7Gfy98WCrySEJGiwkcEW3vy0CuF4cHoJf3zQeNIvn3lNP8B45K6f/WCSKLbMcRJ6V3t5OHtEqmdVDhcbRuFrITfPueELvdO9FFwgZU/LYU61nYWeYWzJb6UbslunXoK56QtL Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 17:13:08 -0000 --089e0118266aa0b4b004e26d417e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Rex, This is a requirement of capability, but it does not require that it be done through the use of SPECTRUM_NOTIFY. It could be easily satisfied if the Device were to use AVAIL_SPECTRUM_GET periodically to refresh its list, which could result in 0 spectrum. -vince On Fri, Jul 26, 2013 at 10:07 AM, Rex Buddenberg wro= te: > On Fri, 2013-07-26 at 15:41 +0000, Harasty, Daniel J wrote: > > somehow =93rescind=94 a channel previously stated as available -- provi= ded > > if there is a widely accepted use case based on regulatory guidelines. > > > Dan, > > The use case has already been stated. Consider an emergency that > requires a public safety mobilization type of response -- earthquake or > hurricane or somebody flying airliners into buildings ... any will do. > Emergency services needs to mobilize and they need more spectrum (or > access to spectrum ... contention-free MACs are time-share): > - to accommodate a quickly accelerated operations tempo > - to replace wired connectivity that has been interrupted by the > disaster. > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --=20 -vince --089e0118266aa0b4b004e26d417e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Rex,

This is a requirement of capabilit= y, but it does not require that it be done through the use of SPECTRUM_NOTI= FY.
It could be easily satisfied if the Device were to use AVAIL_= SPECTRUM_GET periodically to refresh its list, which could
result in 0 spectrum.

-vince


On Fri, Jul 26, 20= 13 at 10:07 AM, Rex Buddenberg <buddenbergr@gmail.com> w= rote:
On Fri, 2013-07-26 at 15:4= 1 +0000, Harasty, Daniel J wrote:
> somehow =93rescind=94 a channel previously stated as available -- prov= ided
> if there is a widely accepted use case based on regulatory guidelines.=


Dan,

The use case has already been stated. =A0Consider an emergency that
requires a public safety mobilization type of response -- earthquake or
hurricane or somebody flying airliners into buildings ... any will do.
Emergency services needs to mobilize and they need more spectrum (or
access to spectrum ... contention-free MACs are time-share):
=A0 - to accommodate a quickly accelerated operations tempo
=A0 - to replace wired connectivity that has been interrupted by the
disaster.



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



--
-vince
--089e0118266aa0b4b004e26d417e-- From buddenbergr@gmail.com Fri Jul 26 10:19:27 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 C52EA21F9A80 for ; Fri, 26 Jul 2013 10:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsZqMbLcXcvO for ; Fri, 26 Jul 2013 10:19:27 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCB621F9AC9 for ; Fri, 26 Jul 2013 10:19:26 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so3134759pdj.3 for ; Fri, 26 Jul 2013 10:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=QmpY/Aobq4Mp0ZhKyB1RhErdLPagP2mtZ3lvMMGYdDs=; b=fusBOHeRb9/7ZrDskG/dPezgX980ZOoCV8RYVnST6JSOyJvMwKzlceqgkJkTOte73i wSKckVShghxyMAzPKfbMJX3KLbCsE8hXpa/4OWIH3aGobPPIwZZRgLYc8CglcYWDl+CS JnPlg/tvheVYGhjLAyCsD86oMqNLs6wJ/dOmhOuXuZvEUD+r68DThedvIRWep/PLAfhj 1k7LkLxUWpjND+HedoR4e8AMfzDzwNfjlsEIQ0lAf/zjXUfoTO9GL8D/kFkzC5Q+AZvo Y05oU7ve4kopVswdTT2Z1fHd0k6X9Qg0l5aGbezyKccPRuHp9M06q/Jc8spJNRZBwHiS fzGA== X-Received: by 10.68.98.33 with SMTP id ef1mr55134313pbb.59.1374859166707; Fri, 26 Jul 2013 10:19:26 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id ts6sm9037228pbc.12.2013.07.26.10.19.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 10:19:26 -0700 (PDT) Message-ID: <1374859164.1735.76.camel@localhost> From: Rex Buddenberg To: Vincent Chen Date: Fri, 26 Jul 2013 10:19:24 -0700 In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991@wds-exc1.okna.nominet.org.uk> <1374858474.1735.73.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 17:19:27 -0000 Agreed. I was carefully avoiding the 'how'. On Fri, 2013-07-26 at 10:13 -0700, Vincent Chen wrote: > Rex, > > > This is a requirement of capability, but it does not require that it > be done through the use of SPECTRUM_NOTIFY. > It could be easily satisfied if the Device were to use > AVAIL_SPECTRUM_GET periodically to refresh its list, which could > result in 0 spectrum. > > > -vince > > > On Fri, Jul 26, 2013 at 10:07 AM, Rex Buddenberg > wrote: > On Fri, 2013-07-26 at 15:41 +0000, Harasty, Daniel J wrote: > > somehow “rescind” a channel previously stated as available > -- provided > > if there is a widely accepted use case based on regulatory > guidelines. > > > > Dan, > > The use case has already been stated. Consider an emergency > that > requires a public safety mobilization type of response -- > earthquake or > hurricane or somebody flying airliners into buildings ... any > will do. > Emergency services needs to mobilize and they need more > spectrum (or > access to spectrum ... contention-free MACs are time-share): > - to accommodate a quickly accelerated operations tempo > - to replace wired connectivity that has been interrupted by > the > disaster. > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > -- > -vince From Patrick.Tarpey@ofcom.org.uk Sun Jul 28 23:59: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 2B46A21F9C19 for ; Sun, 28 Jul 2013 23:59:25 -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, 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 Wrw005ZnaNwQ for ; Sun, 28 Jul 2013 23:59:20 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2521F9C13 for ; Sun, 28 Jul 2013 23:59:20 -0700 (PDT) Received: from [85.158.139.211:23911] by server-1.bemta-5.messagelabs.com id 66/B6-21460-6C216F15; Mon, 29 Jul 2013 06:59:18 +0000 X-Env-Sender: Patrick.Tarpey@ofcom.org.uk X-Msg-Ref: server-3.tower-206.messagelabs.com!1375081158!205054!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.9.11; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26596 invoked from network); 29 Jul 2013 06:59:18 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jul 2013 06:59:18 -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; Mon, 29 Jul 2013 07:59:18 +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; Mon, 29 Jul 2013 07:59:17 +0100 From: Patrick Tarpey To: "paws@ietf.org" Thread-Topic: Message Non repudiation mechanism Thread-Index: AQHOjCkkYqAN6wMMvUyGZ7ZG/JBjJQ== Date: Mon, 29 Jul 2013 06:58:58 +0000 Message-ID: <2FD4C4C86AF9F24AB55FEEA59BCD435E99FA76D7@WOK-INTRA-EXC01.intra.ofcom.local> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.239.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Message Non repudiation mechanism X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 06:59:25 -0000 Hi All, is there an opportunity to consider a mechanism to allow non-repudiation of= certain messages? The work contained within the JSON Web Signature (JWS) is interesting. http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-13 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. ***************************************************************************= *************************************** From Gabor.Bajko@nokia.com Mon Jul 29 03:43:00 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 9FBA421F9FE5 for ; Mon, 29 Jul 2013 03:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.509 X-Spam-Level: X-Spam-Status: No, score=-4.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, 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 f+fmL+o8ZmyS for ; Mon, 29 Jul 2013 03:42:54 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 12E9921F994B for ; Mon, 29 Jul 2013 03:42:53 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r6TAgpNu003263 for ; Mon, 29 Jul 2013 13:42:51 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jul 2013 13:42:50 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.173]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.03.0136.001; Mon, 29 Jul 2013 10:42:50 +0000 From: To: Thread-Topic: remote participation in the berlin F2F Thread-Index: Ac6MR7+F/A/4+2aOTz2J6VS/NBapOA== Date: Mon, 29 Jul 2013 10:42:49 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760230D842@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.194.78.58] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230D842008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jul 2013 10:42:50.0988 (UTC) FILETIME=[5F9B72C0:01CE8C48] X-Nokia-AV: Clean Subject: [paws] remote participation 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: Mon, 29 Jul 2013 10:43:00 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230D842008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you would like to remotely participate to the PAWS session today afterno= on 15:10-17:20 CET, then please use skype and call the id ietf.paws 5-10 mi= n before the meeting. One of the presenter will also call in using skype to present. We will use skype for screen sharing as well, as Meetecho will not be avail= able to assist us. - gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230D842008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you would like to remotely participate to the PAW= S session today afternoon 15:10-17:20 CET, then please use skype and call t= he id ietf.paws 5-10 min before the meeting.

One of the presenter will also call in using skype t= o present.

We will use skype for screen sharing as well, as Mee= techo will not be available to assist us.

 

-     &= nbsp;    gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E4760230D842008AM1MPN1006mg_-- From presnick@qti.qualcomm.com Mon Jul 29 06:04:03 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 CBDAE21F9BF0 for ; Mon, 29 Jul 2013 06:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.103 X-Spam-Level: X-Spam-Status: No, score=-102.103 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6MzpcQSgQpb for ; Mon, 29 Jul 2013 06:03:58 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id F415121F8F24 for ; Mon, 29 Jul 2013 06:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1375103034; x=1406639034; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Kt4V2+G4cC9Yr0qRHuHjYkX86i7oQGL53MlyeKMr7Rc=; b=wkE4ylveJGERiVmO9N3rRej8JDAKQcmKIz2uGPJIl7guYOmJr7kBp73K o9sraKOu6mJyDvJZ5BfTrUU4Md2uvPnGSPSBF2Ws2G0KreyOXP+RO1dhv bhhxR2uynePa17xMCW/ApBR7xtLzmXoznpAaVLviHe7fvlnOrR/iwvCRK w=; X-IronPort-AV: E=Sophos;i="4.89,769,1367996400"; d="scan'208,217";a="48480638" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 29 Jul 2013 06:03:54 -0700 X-IronPort-AV: E=Sophos;i="4.89,769,1367996400"; d="scan'208,217";a="512187214" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Jul 2013 06:03:54 -0700 Received: from dhcp-203a.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 29 Jul 2013 06:03:53 -0700 Message-ID: <51F66834.7090905@qti.qualcomm.com> Date: Mon, 29 Jul 2013 15:03:48 +0200 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Vincent Chen References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE14132@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE161E9@wds-exc1.okna.nominet.org.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020500020104070101080801" X-Originating-IP: [172.30.48.1] Cc: "paws@ietf.org" Subject: Re: [paws] definition of Slave device X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:04:03 -0000 --------------020500020104070101080801 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Speaking as simply a document reviewer, not as an AD: On 7/26/13 5:31 PM, Vincent Chen wrote: > In that case, I believe the PAWS document should refer to Slave and > Master as roles, and I should not include the last sentence in the > proposed text. Indeed, that is what RFC 6953 already says: Master Device: A device that queries the database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information. Slave Device: A device that queries the database through a master device. It is probably worth a "scrub" of the document to make sure the wording agrees with 6953. > We probably also need to add: > > Whether a single device is allowed to serve both Slave and Master > roles depends on regulatory rules. I think simply saying, "A device can server as a Master, as a Slave, or both; Slave and Master are simply roles indicating whether or not the device communicates with the WSDB." is sufficient. As always, I think there is no need to mention regulatory rules in discussion of protocol use, except by way of examples. pr > On Fri, Jul 26, 2013 at 7:34 AM, Ray Bellis > wrote: > > > On 26 Jul 2013, at 15:25, Vincent Chen > wrote: > > > In the ETSI / OFCOM model, is Slave a "role" or a static / > certified property of the device? > > I would tend towards the latter. The ETSI draft standard contains > this definition: > > "slave WSD: WSD that is only able to communicate with other WSDs, > when under the control of a master WSD" > > and this: > > "master WSD: geo-located WSD that is able to communicate directly > with a TVWSDB and with WSDs" > > > Consider the use case: > > - A portable device has location capability, but is not yet on > a network > > - It acts like a Slave in this phase to contact a Master in > order to get spectrum > > - It now can establish network connection to the Database > directly using the spectrum > > > > In the ETSI / OFCOM model: > > 1. Can it now ask the Database directly for spectrum? because > it may be able to operate at higher power? > > I believe that this is *not* permitted. A slave device that has > geolocation capability MAY ask for device specific RF parameters, > but MUST do so through its Master. > > OFCOM's specification explicitly prohibits a (master) WSD from > talking to the WSDB over the managed UHF spectrum, it needs to use > some other form of link. > > kind regards, > > Ray > > > > > > -- > -vince > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------020500020104070101080801 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Speaking as simply a document reviewer, not as an AD:

On 7/26/13 5:31 PM, Vincent Chen wrote:
In that case, I believe the PAWS document should refer to Slave and Master as roles, and I should not include the last sentence in the proposed text.

Indeed, that is what RFC 6953 already says:

   Master Device:  A device that queries the database, on its own behalf
      and/or on behalf of a slave device, to obtain available spectrum
      information.

   Slave Device:  A device that queries the database through a master
      device.

It is probably worth a "scrub" of the document to make sure the wording agrees with 6953.

We probably also need to add:

  Whether a single device is allowed to serve both Slave and Master roles depends on regulatory rules.

I think simply saying, "A device can server as a Master, as a Slave, or both; Slave and Master are simply roles indicating whether or not the device communicates with the WSDB." is sufficient. As always, I think there is no need to mention regulatory rules in discussion of protocol use, except by way of examples.

pr

On Fri, Jul 26, 2013 at 7:34 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:

On 26 Jul 2013, at 15:25, Vincent Chen <vchen@google.com> wrote:

> In the ETSI / OFCOM model, is Slave a "role" or a static / certified property of the device?

I would tend towards the latter.  The ETSI draft standard contains this definition:

"slave WSD: WSD that is only able to communicate with other WSDs, when under the control of a master WSD"

and this:

"master WSD: geo-located WSD that is able to communicate directly with a TVWSDB and with WSDs"

> Consider  the use case:
>  -  A portable device has location capability, but is not yet on a network
>  - It acts like a Slave in this phase to contact a Master in order to get spectrum
>  - It now can establish network connection to the Database directly using the spectrum
>
> In the ETSI / OFCOM model:
>  1. Can it now ask the Database directly for spectrum? because it may be able to operate at higher power?

I believe that this is *not* permitted.  A slave device that has geolocation capability MAY ask for device specific RF parameters, but MUST do so through its Master.

OFCOM's specification explicitly prohibits a (master) WSD from talking to the WSDB over the managed UHF spectrum, it needs to use some other form of link.

kind regards,

Ray





--
-vince 

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

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------020500020104070101080801-- From Ray.Bellis@nominet.org.uk Mon Jul 29 07:16:12 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 9670921F8934 for ; Mon, 29 Jul 2013 07:16:12 -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=[AWL=0.000, 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 aFhJ5-lqMRSm for ; Mon, 29 Jul 2013 07:16:06 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id E3DEC21F9FDA for ; Mon, 29 Jul 2013 07:16:04 -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=4Y5vcCigl8nD2zVELJcYYhpGU6yeTIxOkOu1ljlh0lD3g76FBmzOvzDl mP5SeoWIE06PNfLCGlGY30DiXOyHY6huGk5bpENK0f5FFZz3yTrzjN7Ty XEO+w3tvvkP1txU; 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=1375107365; x=1406643365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kRRSZS2O0YOMcGgK3xQsH8gly23HGJfe6xSqZKdI0Fk=; b=d0hIMMG+57ma2tSjcSjH6a+05SiLopPLDMvfhJpFf2o2yvKQGIFAkrGc rbtqQPn2rY1w7c/wnC3nObpMvQdfohZY4qflqBiBkR0ZdFQJQSdbdVG9D scHSotUbHauoNC7; X-IronPort-AV: E=Sophos;i="4.89,769,1367967600"; d="scan'208";a="2327026" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 29 Jul 2013 15:16:03 +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; Mon, 29 Jul 2013 15:16:02 +0100 From: Ray Bellis To: Michael Head Thread-Topic: [paws] EIRP vs. total power and bandwidth? Thread-Index: AQHOh8f9vIVHRjXOMkWpVy6OSDxSv5l7q/yA Date: Mon, 29 Jul 2013 14:16:01 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1BC2F@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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [paws] EIRP vs. total power and bandwidth? X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:16:12 -0000 On 23 Jul 2013, at 19:13, Michael Head wrote: > As I understand it, PAWS spectrum is described in terms of total power ou= tput over a bandwidth of frequencies (typically these are 6mhz-wide channel= s in the US, I guess?). This seems to assume that the devices will all use = the same sized chunks of the available spectrum and precomputes the total p= ower over those chunks.=20 >=20 > I believe some devices could use shorter bandwidth chunks (say 100khz) fo= r various purposes. From what I can tell, they'll need to convert the "maxP= owerDBm" value (for the given "bandwidth" size) down to an appropriate valu= e for 100khz. >=20 > Wouldn't it be more general to just give the per-hertz spectral density v= alue here and let the device decide how much spectrum it wants to use and c= ompute the appropriate power output over that range? I've no view in terms of narrowband vs wideband usage, but I'd note that th= e current "Spectrum" block is an inefficient way of specifying both a total= EIRP and a maximum permitted spectral density. The example given for OFCOM / ETSI usage of providing separate tables for 8= MHz vs 0.1 MHz where the only difference is the power level results in a _= lot_ of duplication in the spectrum-related messages. Ray
Sungjin, All,

Part of the confusion of = how to interpret the available-spectrum response, perhaps,
is in = the naming of the "maxPowerDBm" variable. E.g.,

       "spectra": =
[
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":27.0},
            ...
          ]
         }

Given that this power really represen= ts "power spectral density" over the specified
bandwidt= h (e.g., 6e6 or 1e5), should we rename it to something like the following?<= /div>

=A0 maxPsdDbmPerBandwidth

Wher= e "bandwidth" refers to the bandwidth specified for that spectrum= profile.

--=A0
-vince
--047d7b471da44c183804e25bd72a-- From vchen@google.com Thu Jul 25 13:33: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 7C03C21F8F63 for ; Thu, 25 Jul 2013 13:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.178, 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 fewOCCGHf7Ep for ; Thu, 25 Jul 2013 13:33:17 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EB5C921F8618 for ; Thu, 25 Jul 2013 13:33:12 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so2612882obb.1 for ; Thu, 25 Jul 2013 13:33:12 -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=vekD0It/zkWZMPc1yIja0Tk0eF0dhL66cYaVdRc5vKI=; b=OcVTEnH4434KURwXdu1Ap8MmPLpRA16R06BKrGt+ClJGvNH55vpuEfDYgJ4YHJdH6J oZKX6iWRpYuguWLdEdgrfIYQttI4ugtoO/TTFrzPQ4S01YtEgeDINc5iMOOkxyhg20yZ 4vPZpIVPmRxK40n0XN2Eh3eZqgsfs4VHoLKcY+PumuuQCd1MLFZL0GfXfe937hgzatnB hHX0jLTMhKjMbdDe+DBn9dwYMupu9Q11a+NuE7HZQAOOSrs9g0xYDbgll9DbAWCYbvgU gLCAnhXiKFGKcULRR3IHeZPSwIdkz+w8/eOwtzkIY8pRDDf2RCJQB0tiZtJUxfFFoh4U +vJQ== X-Google-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:x-gm-message-state; bh=vekD0It/zkWZMPc1yIja0Tk0eF0dhL66cYaVdRc5vKI=; b=EsfvjFa0ERJ4/eDV8K3UmTFhBZx6v99sVxXbHAlXL1x/NysqCTPhIHOY9cubTNncBz 4Sq1XCvgAL8EgAn74jKZkDT5HQxLPPwAG7k0SBpSQeyPkw/NMrvpGDnVMCFGun/t+LCm 6ZEBEQhczwd8IJm3b2Yq3pJdW09xI3YcR+uPfw5C+/LBJlQWRbpTJuqq24ghkXevPsr0 Qyxyutx2RIpnsY4cljlio7dT47svLjiG25k7lR13i++V9xYJj2z2x6AHsHKa9pcuS+Zz POPLJY03Fwc8Fad4o/UcAje4pNx9kLCE5G+BFkNYILFE+HfYmgpx1HmGoCeSgld3lbGK cPTQ== MIME-Version: 1.0 X-Received: by 10.182.225.134 with SMTP id rk6mr38233983obc.40.1374784392337; Thu, 25 Jul 2013 13:33:12 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 25 Jul 2013 13:33:12 -0700 (PDT) In-Reply-To: References: <004601ce894c$914b8b10$b3e2a130$@com> Date: Thu, 25 Jul 2013 13:33:12 -0700 Message-ID: From: Vincent Chen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=001a11c2f800593d2504e25bef1b X-Gm-Message-State: ALoCoQn8gYousH9/m2J0+8K6KCZoNRHDA04EX0D6roAMsK5dnLTAKD+uBilUj9pwlRgaidCg5D5ch8d8HG4NHNeSaEBLrDHpqwxt/8X1aTAHmJRlqVwM+MeCfyj3xq0pPiUMmbnPoX4PKMGbNJcocsP/WR2hyOwniGoL/XvfkanSNlg/u7XXPciRaJa3ctMfNDFZrYaSjpwc Cc: "paws@ietf.org" Subject: Re: [paws] response to REGISTRATION_REQ 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, 25 Jul 2013 20:33:18 -0000 --001a11c2f800593d2504e25bef1b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dan, Great suggestion. I was also about to propose -32000. I will update the draft if there are no objects. -vince On Thu, Jul 25, 2013 at 12:24 PM, Harasty, Daniel J wrote: > Vince,**** > > ** ** > > On your =93point 1=94, I thought I had some good examples in mind. But, = now > that you ask, I can=92t yet make the case that my proposed PAWS > =93REGISTRATION_ERROR=94 is any better than other existing PAWS error cod= es, or > a generic =93server error=94.**** > > ** ** > > While the Devices certainly must deal with the possible HTTP 5xx error, I > suggest the server should attempt to send a JSONRPC =93SERVER ERROR=94 > (-32000). See: http://www.jsonrpc.org/specification#error_object. I=92d > like to recommend that the PAWS spec reference these =93standard JSONRPC > error codes=94, and add a statement to the effect of this:**** > > ** ** > > When an error condition exists, a Database SHOULD attempt to use the most > specific applicable PAWS error. When an accurate one is not available, i= t > SHOULD fallback to standard JSONRPC error codes as defined in JSONRPC > specifications. As a last result, the Database MAY send a suitable HTTP > 5xx response.**** > > ** ** > > Dan**** > > ** ** > > ** ** > > *From:* Vincent Chen [mailto:vchen@google.com] > *Sent:* Thursday, July 25, 2013 12:00 PM > *To:* Sajeev Manikkoth > *Cc:* Harasty, Daniel J; paws@ietf.org > *Subject:* Re: [paws] response to REGISTRATION_REQ**** > > ** ** > > Dan, Sajeev,**** > > ** ** > > I was assuming that general "server errors" would be handled at the HTTP > layer with 5xx codes.**** > > ** ** > > 1. For REGISTRATION_REQ, what error conditions should we be capturing?***= * > > - Some internal error, but can try again later?**** > > ** ** > > 2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did ge= t > an error?**** > > I was assuming that this is a async notify, fire-and-forget, from the > perspective of the device**** > > ** ** > > -vince**** > > ** ** > > On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth < > sajeevmanikkoth@gmail.com> wrote:**** > > Hi Daniel,**** > > **** > > First of all thank you very much for streamlining my comments, and > splitting it into separate email topics. May be I need to take care of it > next time..**** > > **** > > Yes, the semantic you suggest here also can be the solution. My point was= , > an authorized master=92s request also can fail, because of load at databa= se, > or due to request semantic error. **** > > As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting > a generic response accepted/denied.**** > > **** > > Best Regards,**** > > Sajeev**** > > **** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Harasty, Daniel J > *Sent:* Thursday, July 25, 2013 8:35 PM > *To:* paws@ietf.org > *Subject:* [paws] response to REGISTRATION_REQ**** > > **** > > Sanjeev mentioned:**** > > **** > > From: sajeevmanikkoth@gmail.com > Sent: Thursday, July 25, 2013 10:31 AM**** > > [...]**** > > 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have > repsonses like accepted/denied by database?**** > > [...]**** > > **** > > As for possible responses to REGISTRATION_REQ, I have been planning to > suggest this: I think we need a new generic error code > =93REGISTRATION_FAILED=94. Perhaps a value -203, or the next available > -200-block code. **** > > **** > > This should be used by the Database in response to a REGISTRATION_REQ if > no other more specific code is applicable. (For example: if a registrati= on > failed due to a missing field in REGISTRATION_REQ, the Database should > still send the REQUIRED error; if a REGISTRATION_REQ failed due to the > Device being unauthorized, the Database should still send the UNAUTHORIZE= D > error.)**** > > **** > > Sanjeev: does that address your need sentiment for =93a denied registrati= on=94? > **** > > **** > > Dan**** > > **** > > (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.)**** > > **** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > > > **** > > ** ** > > -- > -vince **** > --=20 -vince --001a11c2f800593d2504e25bef1b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Dan,

Great suggestion. I was also about= to propose -32000.

I will update the draft if the= re are no objects.

-vince


On Thu, Jul 25, 2013 at 12:24 PM, Harast= y, Daniel J <dharasty@appcomsci.com> wrote:

Vince,

=A0

On your =93point 1=94, I thought I had some g= ood examples in mind.=A0 But, now that you ask, I can=92t yet make the case= that my proposed PAWS =93REGISTRATION_ERROR=94 is any better than other ex= isting PAWS error codes, or a generic =93server error=94.

=A0<= /p>

While the Devices cert= ainly must deal with the possible HTTP 5xx error, I suggest the server shou= ld attempt to send a JSONRPC =93SERVER ERROR=94 (-32000).=A0 See: ht= tp://www.jsonrpc.org/specification#error_object.=A0 I=92d like to recom= mend that the PAWS spec reference these =93standard JSONRPC error codes=94,= and add a statement to the effect of this:

=A0<= /p>

When an error condition exists, a Database SHOULD attempt to use the m= ost specific applicable PAWS error.=A0 When an accurate one is not availabl= e, it SHOULD fallback to standard JSONRPC error codes as defined in JSONRPC= specifications.=A0 As a last result, the Database MAY send a suitable HTTP= 5xx response.

=A0<= /p>

Dan

=A0<= /p>

=A0

From: Vincent Chen [mailto:vchen@google.com]
Sent: Thursday, July 25, 2013 12:00 PM
To: Sajeev Manikkot= h
Cc: Harasty, Daniel J; paws@ietf.org
Subject: Re: [paws] response to REG= ISTRATION_REQ

=A0

Dan, Sajeev,

=A0

I was assum= ing that general "server errors" would be handled at the HTTP lay= er with 5xx codes.

=A0

1. For REGISTRATION_REQ, what error conditions should we be = capturing?

=A0 =A0- Some= internal error, but can try again later?

=A0

2. SPECTRUM_USE_NOTIFY. What would the device do differently= if it did get an error?

=A0 I was assuming that this is a async notify, fire-and-forget, from the = perspective of the device

=A0

-vince

=A0

On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth <sajeevmanikkoth@gmail.co= m> wrote:

Hi Daniel,

=A0

First of all thank you very much for streamlining my comments, and s= plitting it into separate email topics. May be I need to take care of it ne= xt time..

=A0

Yes, the semanti= c you suggest here also can be the solution. My point was, an authorized ma= ster=92s request also can fail, because of load at database, or due to requ= est semantic error.

As SPECTRUM_USE_NOTIFY also can fall in such a categ= ory, I was suggesting a generic response accepted/denied.

=

=A0

Best Reg= ards,

Sajeev

=A0

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: paws@ietf.org
Subject: [pa= ws] response to REGISTRATION_REQ

<= div>

=A0

Sanjeev = mentioned:

=A0

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY t= ransctions; can it have repsonses like accepted/denied by database?<= u>

[...]

=A0

As for possible responses to REGISTRATION_REQ, I have been= planning to suggest this: =A0I think we need a new generic error code =93R= EGISTRATION_FAILED=94.=A0 Perhaps a value -203, or the next available -200-= block code.=A0

=A0

This sho= uld be used by the Database in response to a REGISTRATION_REQ if no other m= ore specific code is applicable.=A0 (For example: if a registration failed = due to a missing field in REGISTRATION_REQ, the Database should still send = the REQUIRED =A0error; if a REGISTRATION_REQ failed due to the Device being= unauthorized, the Database should still send the UNAUTHORIZED error.)

=A0

Sanjeev:= does that address your need sentiment for =93a denied registration=94?<= /u>

=A0

Dan

=A0

(I have = a separate comment about SPECTRUM_USE_NOTIFY, to follow.)

=

=A0


_______________________________________________
paws mailing listpaws@ietf.org
http= s://www.ietf.org/mailman/listinfo/paws



<= p class=3D"MsoNormal">=A0

-- =
-vince




--
-vince
--001a11c2f800593d2504e25bef1b-- From vchen@google.com Thu Jul 25 19:16:56 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 51D6D21F8EEA for ; Thu, 25 Jul 2013 19:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[AWL=0.162, 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 horzTQds6f1A for ; Thu, 25 Jul 2013 19:16:48 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3C021F8EDF for ; Thu, 25 Jul 2013 19:16:47 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id f8so3179657obp.17 for ; Thu, 25 Jul 2013 19:16:46 -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=wjViiSF/AAhMvCr/Cs8fMotUVOUiENfz6FE/nW9ciPQ=; b=RrOwLul5MxUC2v9hVYbfv1bId+THokvNeBlhXV7F3acL3JuPkOn1ICwOg4fn8nloaT WGza42Z4QkRJ38nHR+RI5nJTrpfKYKsfOFAv/aHC/L4GxlL5OV1Mj6HpxxhsXKiF1WLK 5cvZlFHwTGt6kAqIyuNEPxSiyYxJO1rV0HRVUlOG+ZwPt+maouD7pz2GiDy2gyokwJl+ QHLJ2+0n9pWPgvQVDbzu/WzcLW2629O7Lito3LN6z0syqL/+BgcXQsNMK8Im7A8o5XUp 4KN1B0UpgCCTMR6s6J9SdGxUrGtB2ao7RxTSmUUho6LvJV72rBMRj+yJVnM82lpEEglz NXUw== X-Google-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:x-gm-message-state; bh=wjViiSF/AAhMvCr/Cs8fMotUVOUiENfz6FE/nW9ciPQ=; b=nNX72HKFIF7BKDrBIwG4H1lWk43xFGp0F7dvU4z5oilSdSchIX3C1L5cGz4wh6li85 ZeJiGZsmzbtpbJe6ro7nLSUk4sJA2H9XMHGeJ64unHFqGpVUNcJN3+jNLLy1/ZPAoemv k3APMNLlNLKGBczoRX35kydfKn5s9wBP4il2AtSORbRh0Q56HlE3IbJ8uk5sMwIv6YpX 56lAnQMuN85wM+pnRpFSBhpkajtSmO9OVFqcRJbt4c94VIZN5eTLw0uxEMBfx1ugBfva 3sjQo2ZVhnOqM1wF8WsUNabxfumkadZKyuVmVOs+jwrdmU7xRaIArvHb+s4dXmYMUWAP C8QQ== MIME-Version: 1.0 X-Received: by 10.60.45.138 with SMTP id n10mr44996492oem.101.1374805005997; Thu, 25 Jul 2013 19:16:45 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Thu, 25 Jul 2013 19:16:45 -0700 (PDT) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> Date: Thu, 25 Jul 2013 19:16:45 -0700 Message-ID: From: Vincent Chen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=001a11c245e404b6c404e260bc22 X-Gm-Message-State: ALoCoQkhH8JgK0sB8eAmSGhblJ5DcFDZkdGolI/1r4kyNETNzvMR1lpKrjWhP7FQoeEOMAgMHXNtEI+81S3nm+Yhg5yGwfPsxdZwImyojuyXICAPeAstG+V5349klWgb8xMaEs3oc4rJlUL+GI4AFfEdbXxsLjJgfYt0dbkyw1jXdgTYRNMjYTslZtc8SQYGM+gZL3MotNA8 Cc: "paws@ietf.org" Subject: Re: [paws] definition of Slave device 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, 26 Jul 2013 02:16:57 -0000 --001a11c245e404b6c404e260bc22 Content-Type: text/plain; charset=ISO-8859-1 How about the following wording? Slave Device: A device that uses a Master Device to query a Spectrum Database on its behalf to find available spectrum. The slave device may or may not have geo-location capability. A slave device that does not have geo-location capability MUST get available spectrum via a Master Device. On Thu, Jul 25, 2013 at 8:43 AM, Vincent Chen wrote: > This sounds reasonable. > > > On Thu, Jul 25, 2013 at 7:44 AM, Harasty, Daniel J > wrote: > >> I'd like to comment some of Sanjeev's input.**** >> >> ** ** >> >> I prefer to send independent replies on each topic, as that way a given >> email thread is about a single topic (more or less).**** >> >> ** ** >> >> Sanjeev mentioned:**** >> >> ** ** >> >> From: sajeevmanikkoth@gmail.com >> Sent: Thursday, July 25, 2013 10:31 AM**** >> >> [...]**** >> >> 1. Section 2.2 states Slave device as a device without geolocation >> capability. I think the phrasing there need to be different. A Slave device >> may or may not have geolocation capability, but does not directly query the >> database. Also a mobile Slave device, can it not switch as master device in >> adhoc? **** >> >> [...]**** >> >> ** ** >> >> I agree with the nature of his comment: a Slave device may well have >> geolocation capabilities; however PAWS does not expect it needs to use them >> to communicate with a Master device. I would support an update to the >> definition of Slave.**** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > -- -vince --001a11c245e404b6c404e260bc22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How about the following wording?

Slave = Device: A device that uses a Master Device to query a Spectrum Database on = its behalf to find available spectrum. The slave device may or may not have= geo-location capability. A slave device that does not have geo-location ca= pability MUST get available spectrum via a Master Device.


O= n Thu, Jul 25, 2013 at 8:43 AM, Vincent Chen <vchen@google.com> wrote:
This sounds reasonable.


On Thu, Jul 25, 2013 at 7:44 AM, Harasty, Daniel J <dharasty@appcomsc= i.com> wrote:

I'= ;d like to comment some of Sanjeev's input.

=A0

I prefer= to send independent replies on each topic, as that way a given email threa= d is about a single topic (more or less).

=A0

Sanjeev mentioned:

=A0

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

1. Section 2.2 states Slave device as a device= without geolocation capability. I think the phrasing there need to be diff= erent. A Slave device may or may not have geolocation capability, but does = not directly query the database. Also a mobile Slave device, can it not swi= tch as master device in adhoc?

[...]

=A0

I agree with the nature of his comment: a Slave device may well have geo= location capabilities; however PAWS does not expect it needs to use them to= communicate with a Master device.=A0 I would support an update to the defi= nition of Slave.


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


<= br clear=3D"all">

--
-vince



--
-vince
--001a11c245e404b6c404e260bc22-- From mrhead@google.com Thu Jul 25 22:11:42 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 AE9AD21F8517 for ; Thu, 25 Jul 2013 22:11:42 -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 T2I3eW8nWQ-w for ; Thu, 25 Jul 2013 22:11:41 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 137FD21F84F9 for ; Thu, 25 Jul 2013 22:11:36 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so3371696obc.6 for ; Thu, 25 Jul 2013 22:11:32 -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=EgWDiRvpSVl2F6C9vEaLIoqiKcp5E9eL6WpKEsS0ELM=; b=Vl73VFmkTqk5ja24vE6bIcSd2oSIdenzVHWUrhzXr6DVAQQjJoLWlmOWIdG4JlF0u1 yB52crugT987e2c8+7Ymi+4hI9bKkKcW+9RyU7S9ytDkdVHhAoPH2QVxTxTA0p6IHyAm byClRRHcEd20uW1JlpkwyyEU44lLDyB/eUEVjfI9YLnSSIz8Lu0ZphIuTrPC+9G0Ewfn fPBwbip3cE35FXZoIH9zukyFq9bu56hwfvslgbIyZOJNGc7nmB6XOOl+R+T4rLFn7t/s awLAbaSNQMI+0L8HFEvyNHfp7R32drlzoSf4p+oULZqUIT6dpL5xrHOjsPQaisRHVRuK ruCQ== X-Google-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:x-gm-message-state; bh=EgWDiRvpSVl2F6C9vEaLIoqiKcp5E9eL6WpKEsS0ELM=; b=R7tev72rIa9Jby7wgDWVc3H4ZWmY/Opuf765LaBvGtmp9lESnkHkhOWra5ISQannq+ kvXTvmSpRAPTC2SWZZdc+SujWfdAOnnHzJ/5XRC9b9v6F44VGvR1o89Zm6UBy7VervEF 9+IOsOklJxKDLuVdgC0ewxVtZG5ngF4kn4R4hNACO4LfP/hVA/D5lCg0ntZwwAvbbk2K FkNA9b5e1K+y9SAeOxF5EF5hll87lEXVRQKsdZT5+JhUTgZolhzEF919NKgHtBqHNLE0 SerbOwN7+uzxEEQL8dmlB5sk++flR91+2r2/nvoyHaB/OUkzumI+RLR1FoSNkzvvIecP Ye6w== MIME-Version: 1.0 X-Received: by 10.43.87.136 with SMTP id aw8mr19582631icc.77.1374815492640; Thu, 25 Jul 2013 22:11:32 -0700 (PDT) Received: by 10.64.245.204 with HTTP; Thu, 25 Jul 2013 22:11:32 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Jul 2013 06:11:32 +0100 Message-ID: From: Michael Head To: Vincent Chen Content-Type: multipart/alternative; boundary=001a11c1f84012694404e2632d7f X-Gm-Message-State: ALoCoQmBdFVqkQ6hin48QSMfYGWhLNYU4nBHjd5IqQn7ASGgKOumoDw2lkG2EuvTDP56LcP4VRtSZFkv3P2R4svZ8LW5KQ06RV+tEE5JC9SA4wjJq+y3TfOOc0/W08eyP3AZ1dl3T3mQDOkydq8/QJfDEB/W2KDh8tTfaQFxlrcws8043bLrW48wZsrTWzsYEJPVFKzCUCba Cc: "paws@ietf.org" Subject: Re: [paws] Proposal: Rename maxPowerDBm in Available-spectrum response 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, 26 Jul 2013 05:11:42 -0000 --001a11c1f84012694404e2632d7f Content-Type: text/plain; charset=ISO-8859-1 This sounds like a good clarification to me. On Thu, Jul 25, 2013 at 9:26 PM, Vincent Chen wrote: > Sungjin, All, > > Part of the confusion of how to interpret the available-spectrum response, > perhaps, > is in the naming of the "maxPowerDBm" variable. E.g., > > "spectra": [ > { > "bandwidth": 6e6, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, > ... > ] > }, > { > "bandwidth": 1e5, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, > ... > ] > } > > > Given that this power really represents "power spectral density" over the > specified > bandwidth (e.g., 6e6 or 1e5), should we rename it to something like the > following? > > maxPsdDbmPerBandwidth > > Where "bandwidth" refers to the bandwidth specified for that spectrum > profile. > > -- > -vince > > _______________________________________________ > 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 --001a11c1f84012694404e2632d7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This sounds like a good clarification to me.


On Thu, Jul 25, 2013 = at 9:26 PM, Vincent Chen <vchen@google.com> wrote:
Sungjin, All,

Part of the confusion of how to interpret the available-spectrum resp= onse, perhaps,
is in the naming of the "maxPowerDBm" variable. E.g.,
<= div>
       "spectra": =
[
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "m=
axPowerDBm":27.0},
            ...
          ]
         }

Given that this power really represen= ts "power spectral density" over the specified
bandwidt= h (e.g., 6e6 or 1e5), should we rename it to something like the following?<= /div>

=A0 maxPsdDbmPerBandwidth

Wher= e "bandwidth" refers to the bandwidth specified for that spectrum= profile.

--=A0
-vince

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




--
= ----------------------------------
Michael R Head <mrhead@google.com>
+1-201-BLISTER
--001a11c1f84012694404e2632d7f-- From sjyou@etri.re.kr Thu Jul 25 22:27: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 E50C011E80D2 for ; Thu, 25 Jul 2013 22:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.856 X-Spam-Level: X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv3yRTrL4pAp for ; Thu, 25 Jul 2013 22:27:39 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id D4FC711E80C5 for ; Thu, 25 Jul 2013 22:27:38 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 26 Jul 2013 14:27:34 +0900 Received: from [129.254.65.147] (129.254.65.147) by SMTP4.etri.info (129.254.28.74) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 26 Jul 2013 14:27:31 +0900 Message-ID: <51F208C3.1040900@etri.re.kr> Date: Fri, 26 Jul 2013 14:27:31 +0900 From: Sungjin Yoo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Head References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080909010309080305040000" X-Originating-IP: [129.254.65.147] Cc: "paws@ietf.org" Subject: Re: [paws] Proposal: Rename maxPowerDBm in Available-spectrum response 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, 26 Jul 2013 05:27:44 -0000 --------------080909010309080305040000 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Vince, It looks better to understand. Regards, Sungjin On 07/26/2013 02:11 PM, Michael Head wrote: > This sounds like a good clarification to me. > > > On Thu, Jul 25, 2013 at 9:26 PM, Vincent Chen > wrote: > > Sungjin, All, > > Part of the confusion of how to interpret the available-spectrum > response, perhaps, > is in the naming of the "maxPowerDBm" variable. E.g., > > "spectra": [ > { > "bandwidth": 6e6, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0}, > ... > ] > }, > { > "bandwidth": 1e5, > "frequencyRanges": [ > {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0}, > ... > ] > } > > > Given that this power really represents "power spectral density" > over the specified > bandwidth (e.g., 6e6 or 1e5), should we rename it to something > like the following? > > maxPsdDbmPerBandwidth > > Where "bandwidth" refers to the bandwidth specified for that > spectrum profile. > > -- > -vince > > _______________________________________________ > 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 --------------080909010309080305040000 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Vince,

It looks better to understand.

Regards,
Sungjin

On 07/26/2013 02:11 PM, Michael Head wrote:
This sounds like a good clarification to me.


On Thu, Jul 25, 2013 at 9:26 PM, Vincent Chen <vchen@google.com> wrote:
Sungjin, All,

Part of the confusion of how to interpret the available-spectrum response, perhaps,
is in the naming of the "maxPowerDBm" variable. E.g.,

       "spectra": [
         {
          "bandwidth": 6e6,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":30.0},
            ...
          ]
         },
         {
          "bandwidth": 1e5,
          "frequencyRanges": [
            {"startHz":5.18e8, "stopHz":5.36e8, "maxPowerDBm":27.0},
            ...
          ]
         }

Given that this power really represents "power spectral density" over the specified
bandwidth (e.g., 6e6 or 1e5), should we rename it to something like the following?

  maxPsdDbmPerBandwidth

Where "bandwidth" refers to the bandwidth specified for that spectrum profile.

-- 
-vince

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




--
----------------------------------
Michael R Head <mrhead@google.com>
+1-201-BLISTER

--------------080909010309080305040000-- From sjyou@etri.re.kr Fri Jul 26 00:33:16 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 DFE5721F8445 for ; Fri, 26 Jul 2013 00:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k8UCR0pOCTw for ; Fri, 26 Jul 2013 00:33:11 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id EE49321F8449 for ; Fri, 26 Jul 2013 00:33:10 -0700 (PDT) Received: from SMTP4.etri.info (129.254.28.74) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 26 Jul 2013 16:33:06 +0900 Received: from [129.254.65.147] (129.254.65.147) by SMTP4.etri.info (129.254.28.74) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 26 Jul 2013 16:33:07 +0900 Message-ID: <51F22633.7080904@etri.re.kr> Date: Fri, 26 Jul 2013 16:33:07 +0900 From: Sungjin Yoo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080208000100090203020504" X-Originating-IP: [129.254.65.147] Subject: Re: [paws] definition of Slave device 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, 26 Jul 2013 07:33:17 -0000 --------------080208000100090203020504 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Vince and all, I think "location" in AVAIL_SPECTRUM_REQ may be the location of Slave device when the request is made by the Master device on behalf of a slave device. See following in RFC6953 5.3. Operational Requirements O.5 A master device MUST be able to query the database for the available spectrum on behalf of a slave device at a specified location before the slave device starts radio transmission in white space at that location. 6. Security Considerations PAWS is a protocol whereby a master device requests a schedule of available spectrum at its location (or the location of its slave devices) before it (or they) can operate using those frequencies. --Sungjin On 07/26/2013 11:16 AM, Vincent Chen wrote: > How about the following wording? > > Slave Device: A device that uses a Master Device to query a Spectrum > Database on its behalf to find available spectrum. The slave device > may or may not have geo-location capability. A slave device that does > not have geo-location capability MUST get available spectrum via a > Master Device. > > > On Thu, Jul 25, 2013 at 8:43 AM, Vincent Chen > wrote: > > This sounds reasonable. > > > On Thu, Jul 25, 2013 at 7:44 AM, Harasty, Daniel J > > wrote: > > I'd like to comment some of Sanjeev's input. > > I prefer to send independent replies on each topic, as that > way a given email thread is about a single topic (more or less). > > Sanjeev mentioned: > > From: sajeevmanikkoth@gmail.com > Sent: Thursday, July 25, 2013 10:31 AM > > [...] > > 1. Section 2.2 states Slave device as a device without > geolocation capability. I think the phrasing there need to be > different. A Slave device may or may not have geolocation > capability, but does not directly query the database. Also a > mobile Slave device, can it not switch as master device in adhoc? > > [...] > > I agree with the nature of his comment: a Slave device may > well have geolocation capabilities; however PAWS does not > expect it needs to use them to communicate with a Master > device. I would support an update to the definition of Slave. > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > > > -- > -vince > > > > > -- > -vince --------------080208000100090203020504 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Vince and all,

I think "location" in AVAIL_SPECTRUM_REQ may be the location of Slave device when the request is made by the Master device on behalf of a slave device. 

See following in RFC6953

5.3.  Operational Requirements

   O.5  A master device MUST be able to query the database for the
        available spectrum on behalf of a slave device at a specified
        location before the slave device starts radio transmission in
        white space at that location.


6.  Security Considerations
   PAWS is a protocol whereby a master device requests a schedule of
   available spectrum at its location (or the location of its slave
   devices) before it (or they) can operate using those frequencies.


--Sungjin



On 07/26/2013 11:16 AM, Vincent Chen wrote:
How about the following wording?

Slave Device: A device that uses a Master Device to query a Spectrum Database on its behalf to find available spectrum. The slave device may or may not have geo-location capability. A slave device that does not have geo-location capability MUST get available spectrum via a Master Device.


On Thu, Jul 25, 2013 at 8:43 AM, Vincent Chen <vchen@google.com> wrote:
This sounds reasonable.


On Thu, Jul 25, 2013 at 7:44 AM, Harasty, Daniel J <dharasty@appcomsci.com> wrote:

I'd like to comment some of Sanjeev's input.

 

I prefer to send independent replies on each topic, as that way a given email thread is about a single topic (more or less).

 

Sanjeev mentioned:

 

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

1. Section 2.2 states Slave device as a device without geolocation capability. I think the phrasing there need to be different. A Slave device may or may not have geolocation capability, but does not directly query the database. Also a mobile Slave device, can it not switch as master device in adhoc?

[...]

 

I agree with the nature of his comment: a Slave device may well have geolocation capabilities; however PAWS does not expect it needs to use them to communicate with a Master device.  I would support an update to the definition of Slave.


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




--
-vince



--
-vince

--------------080208000100090203020504-- From Ray.Bellis@nominet.org.uk Fri Jul 26 00:33: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 10BF621F8445 for ; Fri, 26 Jul 2013 00:33:18 -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 ORTv0jcBkRMs for ; Fri, 26 Jul 2013 00:33:13 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8E0221F8438 for ; Fri, 26 Jul 2013 00:33:12 -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=b8vkUrkKc6dNSN6cWRDOwkDftHHhKYnEBM8wbFqzexNtAMA1SUDoABFC 3CRJZVrnrZxQ++XDRrnXBSAQzcKAAEYnLispjscW4kDm3ym897z1C6HGg iGyarBbzCexbcvS; 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=1374823993; x=1406359993; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=f0kWqceGmpxD3ukCqXWPXjO0OfhO+06Uk2a170UVOok=; b=hKZThRwE+qhOs7PNkLdK9e3mRUZU1tIWpgnzUc6PQtijr4QCujnq4ZD9 bZ8gXk742GBzaHyCaVyoyuTBaXuUm6+lcvLtIPumAh4FTF+yOe2eJDi/u KpSXeG5bG2FfrYy; X-IronPort-AV: E=Sophos;i="4.89,749,1367967600"; d="scan'208";a="1966766" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 26 Jul 2013 08:33:11 +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, 26 Jul 2013 08:33:10 +0100 From: Ray Bellis To: Vincent Chen Thread-Topic: [paws] definition of Slave device Thread-Index: AQHOiUWKnLV87tOKrE2oRwahCfbUl5l1d/kAgACxEoCAAFhnAA== Date: Fri, 26 Jul 2013 07:33:10 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE14132@wds-exc1.okna.nominet.org.uk> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> 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: <76C6E167BDC5E849AE9F7FC73E4A5610@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] definition of Slave device 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, 26 Jul 2013 07:33:18 -0000 On 26 Jul 2013, at 03:16, Vincent Chen wrote: > How about the following wording? >=20 > Slave Device: A device that uses a Master Device to query a Spectrum Data= base on its behalf to find available spectrum. The slave device may or may = not have geo-location capability. A slave device that does not have geo-loc= ation capability MUST get available spectrum via a Master Device. That's fine apart from the last sentence. In the ETSI / OFCOM model, a slave MUST _always_ get available spectrum via= a Master Device whether the slave has geolocation capability or not. If i= t gets spectrum directly from the WSDB, by definition it's not a slave. Ray From Ray.Bellis@nominet.org.uk Fri Jul 26 00:41:26 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 1BFD821F9133 for ; Fri, 26 Jul 2013 00:41:20 -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 U9etiJBiTR0M for ; Fri, 26 Jul 2013 00:41:13 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A321F8E2D for ; Fri, 26 Jul 2013 00:41:11 -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=HmMfXRrZuJN74jY2gQ8sPVXxkH2n8QK3QT5IOk6KtAKFqF1h95eWCJhn cLqUQY3L+J9s7o7oj1+k5lUdZ6m9oy//QcyG7zWgK7POI4WiG5OTQlOEg g7NRbfPLQVW60y3; 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=1374824473; x=1406360473; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x6M4eyeHeid/tpDYct5PhNEUKn0AMaYwV4FcPqDdKO0=; b=cwSessAfzz412Hn4PMXV1ZCHJBIbcOGqm/t8CsjFJ4dBNpogeIPp+GHm 2CPN/MyGvbXTWNDN4ez59t+JnnTaWYn21BY4fZ4h0sq98p5dcIxYGqy7d kR2mNE3kMJDhpWe; X-IronPort-AV: E=Sophos;i="4.89,749,1367967600"; d="scan'208,217";a="1966803" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 26 Jul 2013 08:41:10 +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, 26 Jul 2013 08:41:10 +0100 From: Ray Bellis To: "Harasty, Daniel J" Thread-Topic: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response Thread-Index: Ac6JcnEannpwjoqiRdOtljZ3jG31TQAWKtqA Date: Fri, 26 Jul 2013 07:41:09 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@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: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422Ewdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 07:41:26 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422Ewdsexc1oknanomi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 25 Jul 2013, at 21:06, "Harasty, Daniel J" > wrote: The JSONRPC spec defines a =93notification=94 as a type of request that nee= ds no response; in fact a response is not even allowed. Since the PAWS SPECTRUM_USE_NOTIFY is =93this kind of message=94 semantical= ly (note that SPECTRUM_USE_RESP is empty), I propose we: =95 State that the SPECTRUM_USE_NOTIFY uses the JSONRPC =93Notifica= tion=94 Request object (see: http://www.jsonrpc.org/specification#notificat= ion), and =95 That we eliminate the SPECTRUM_USE_RESP from the PAWS spec. This is consistent with Vince=92s characterization that SPECTRUM_USE_NOTIFY= is an =93async notify, fire-and-forget, from the perspective of the devic= e=94. The UK pilot spec requires that the WSDB tell the device to stop transmitti= ng if the channel usage parameters are inconsistent with those that the WSD= B issued, i.e. it is not merely "informational". I note however that there appears to be no such specific requirement in the= ETSI draft. In my (non PAWS) implementation I was expecting to return an immediate erro= r in these circumstances, rather than wait for the device's next 15 minute = poll. Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422Ewdsexc1oknanomi_ Content-Type: text/html; charset="Windows-1252" Content-ID: <62873B517902B24DB3492D89639F44FD@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable
On 25 Jul 2013, at 21:06, "Harasty, Daniel J" <dharasty@appcomsci.com> wrote:

The JSONRPC spec defines a =93notificatio= n=94 as a type of request that needs no response; in fact a response is not= even allowed.
 
Since the PAWS SPECTRUM_USE_NOTIFY is =93this kind of message=94 semantical= ly (note that SPECTRUM_USE_RESP is empty), I propose we:
 
=B7     = ;    State that the SPECTRUM_USE_NOTIFY uses the JSONRPC =93Notification=94 Request o= bject (see: http://www.jsonrpc.org/specification#notificati= on), and
=B7     = ;    That we eliminate the SPECTRUM_USE_RESP from the PAWS spec.
 
This is consistent with Vince=92s characterization that SPECTRUM_USE_NOTIFY= is an  =93async notify, fire-and-forget, from the perspective of the = device=94.

The UK pilot spec requires that the WSDB tell the device to stop trans= mitting if the channel usage parameters are inconsistent with those that th= e WSDB issued, i.e. it is not merely "informational".

I note however that there appears to be no such specific requirement i= n the ETSI draft.

In my (non PAWS) implementation I was expecting to return an immediate= error in these circumstances, rather than wait for the device's next 15 mi= nute poll.

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422Ewdsexc1oknanomi_-- From dharasty@appcomsci.com Fri Jul 26 05:52:56 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 0AF4C21F860B for ; Fri, 26 Jul 2013 05:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 JAvefSjlB-70 for ; Fri, 26 Jul 2013 05:52:50 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 58AC921F963F for ; Fri, 26 Jul 2013 05:52:50 -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 r6QCqlcT019305; Fri, 26 Jul 2013 08:52:49 -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 r6QCqilG015976; Fri, 26 Jul 2013 08:52:44 -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; Fri, 26 Jul 2013 08:52:44 -0400 From: "Harasty, Daniel J" To: Ray Bellis Thread-Topic: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response Thread-Index: AQHOidOFq/a9qPEX8UCpvsJheVb3Tpl221kw Date: Fri, 26 Jul 2013 12:52:43 +0000 Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEEF970rrcatsexmb2atsa_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 12:52:56 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF970rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray: I'm less familiar with the UK use cases. Is this the case you are contempl= ating?: 1. Device requests AVAIL_SPECTRUM_REQ 2. Database sends AVAIL_SPECTRUM_RESP with a list of available channe= ls and max power values 3. Device picks one that is either not available, or picks a power th= at exceeds the limit on an available channel 4. Device reports its [non-conforming] selection via the [optional] S= PECTRUM_USE_NOTIFY 5. Database "rejects" that notification 6. Device stops transmitting on the frequency it selected due to the = "rejection" If the Device is willing to conform to the "rejection", why did it pick - a= nd report - a non-conforming value to start with? The one possible case I can see some use for a "rejection" is this: a subst= antial amount of time passes between the AVAIL_SPECTRUM_RESP and the Device= 's selection/notification, and the selected channel is - contrary to the or= iginal AVAIL_SPECTRUM_RESP - no longer available. I propose that the better way to handle that possibility is: the Device sho= uld simply send its AVAIL_SPECTRUM_RESP just before its selection. That wa= y, it will have the most accurate info: it can avoid the then-unavailable/u= ndesirable channels - and thus obviate the need for any sort of "rejection"= . Furthermore, it may find that there are additional/somewhat-better then-= available channels. Is this a viable approach under UK (and similar) rules? Dan Harasty From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] Sent: Friday, July 26, 2013 3:41 AM To: Harasty, Daniel J Cc: paws@ietf.org Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response On 25 Jul 2013, at 21:06, "Harasty, Daniel J" > wrote: The JSONRPC spec defines a "notification" as a type of request that needs n= o response; in fact a response is not even allowed. Since the PAWS SPECTRUM_USE_NOTIFY is "this kind of message" semantically (= note that SPECTRUM_USE_RESP is empty), I propose we: * State that the SPECTRUM_USE_NOTIFY uses the JSONRPC "Notification= " Request object (see: http://www.jsonrpc.org/specification#notification), = and * That we eliminate the SPECTRUM_USE_RESP from the PAWS spec. This is consistent with Vince's characterization that SPECTRUM_USE_NOTIFY i= s an "async notify, fire-and-forget, from the perspective of the device". The UK pilot spec requires that the WSDB tell the device to stop transmitti= ng if the channel usage parameters are inconsistent with those that the WSD= B issued, i.e. it is not merely "informational". I note however that there appears to be no such specific requirement in the= ETSI draft. In my (non PAWS) implementation I was expecting to return an immediate erro= r in these circumstances, rather than wait for the device's next 15 minute = poll. Ray --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF970rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray:=

 

I’m less familiar with the UK use cases.&nb= sp; Is this the case you are contemplating?:

 

= 1.       Device requests AVAIL_SPECTRUM_REQ

2.       <= /span>Database sends AVAIL_SPECTRUM_RESP with a lis= t of available channels and max power values

3.       <= /span>Device picks one that is either not available= , or picks a power that exceeds the limit on an available channel

4.    &= nbsp;  Device reports its [non-c= onforming] selection via the [optional] SPECTRUM_USE_NOTIFY

5.<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp; Database “rejects” = that notification

6.&nbs= p;

If the Device is willing to = conform to the “rejection”, why did it pick – and report = – a non-conforming value to start with?

 

The one possible case I can see some use for a “rejection” is = this: a substantial amount of time passes between the AVAIL_SPECTRUM_RESP a= nd the Device’s selection/notification, and the selected channel is &= #8211; contrary to the original AVAIL_SPECTRUM_RESP – no longer avail= able.

 

I propose that the better way to handle= that possibility is: the Device should simply send its AVAIL_SPECTRUM_RESP= just before its selection.  That way, it will have the most accurate = info: it can avoid the then-unavailable/undesirable channels – and th= us obviate the need for any sort of “rejection”.  Furtherm= ore, it may find that there are additional/somewhat-better then-available c= hannels.

 =

Is this a viable approach under UK (= and similar) rules?

 

Dan Harasty<= /span>

 

 

From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk]
Sent: = Friday, July 26, 2013 3:41 AM
To: Harasty, Daniel J
Cc:= paws@ietf.org
Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclat= ure and response

 

 

On 25 Jul 2013, at 21:06, "Harasty, Daniel J" <= dharasty@appcomsci.com> wr= ote:



<= div>

The JSONRPC spec defines a “notification” as = a type of request that needs no response; in fact a response is not even al= lowed.

 

Since the PAWS SPECTRUM_USE_NOTIFY is “= ;this kind of message” semantically (note that SPECTRUM_USE_RESP is e= mpty), I propose we:

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

·   =       State that the SPECTRUM_USE_NOTIFY uses the JSONRPC “Notification= ” Request object (see: http://www.jsonrpc.org/specification#notification<= /a>), and

I note however that there appears to be no such spec= ific requirement in the ETSI draft.

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEF970rrcatsexmb2atsa_-- From Ray.Bellis@nominet.org.uk Fri Jul 26 05:58:59 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 AC15321F979E for ; Fri, 26 Jul 2013 05:58:59 -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 3327tPoKaAME for ; Fri, 26 Jul 2013 05:58:54 -0700 (PDT) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1505D21F97C7 for ; Fri, 26 Jul 2013 05:58:53 -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=NNrqB3xjwxa+zYwAUB1t5BY01gvqb5wFtdEm0v/GNOxnG1NDHumw5wYi BVPga5aaKpEDtQreJ8Jt7Z7cOXytZhAtJYmNPJ+9+oWj0kQWcLkfEWuh/ ZbSWmvxaSu2MoKH; 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=1374843534; x=1406379534; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=61A1vPwUHCl0lAi4v4QpfUNrfX4Zc91+QFnwOMBBPD4=; b=uMzGm7q/vybJxv/NDce/20RASS3xMyFUPmkGswtOqVjP+EH31ItQqfrR FRiVYVMwviSfCp/Dh5RmkBTrJnnOqW/vtmXCrMyuC7J4tvdF6O4iJsRp3 cloCmJ8P4El5HOB; X-IronPort-AV: E=Sophos;i="4.89,751,1367967600"; d="scan'208,217";a="1977480" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 26 Jul 2013 13:58:51 +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, 26 Jul 2013 13:58:51 +0100 From: Ray Bellis To: "Harasty, Daniel J" Thread-Topic: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response Thread-Index: Ac6JcnEannpwjoqiRdOtljZ3jG31TQAWKtqAAArhn4AAADbWgA== Date: Fri, 26 Jul 2013 12:58:50 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991@wds-exc1.okna.nominet.org.uk> References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@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_53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991wdsexc1oknanomi_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 12:58:59 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991wdsexc1oknanomi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 26 Jul 2013, at 13:52, "Harasty, Daniel J" > wrote: Ray: I=92m less familiar with the UK use cases. Is this the case you are contem= plating?: 1. Device requests AVAIL_SPECTRUM_REQ 2. Database sends AVAIL_SPECTRUM_RESP with a list of available channe= ls and max power values 3. Device picks one that is either not available, or picks a power th= at exceeds the limit on an available channel 4. Device reports its [non-conforming] selection via the [optional] S= PECTRUM_USE_NOTIFY 5. Database =93rejects=94 that notification 6. Device stops transmitting on the frequency it selected due to the = =93rejection=94 If the Device is willing to conform to the =93rejection=94, why did it pick= =96 and report =96 a non-conforming value to start with? Well, quite :) In theory of course a device shouldn't do that, but this is in effect the O= FCOM requirement. I'll suggest to the OFCOM folks that the SPECTRUM_USE_NOTIFY should become = "informational only", and not require any positive action other than loggin= g those values. kind regards, Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991wdsexc1oknanomi_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
 wrote:

Ray:
 
I=92m less familiar with the UK use cases.  Is this = the case you are contemplating?:
 
1.       Device requests AVAIL_SPECTRUM_REQ
2.       Database sends AVAIL_SPECTRUM_RESP with a list of available channels and max power = values
3.       Device picks one that is either not available, or picks a power that exceeds the = limit on an available channel
4.       Device reports its [non-conforming] selection via the [optional] SPECTRUM_USE_NOT= IFY
5.       Database =93rejects=94 that notification
6.       Device stops transmitting on the frequency it selected due to the =93rejection=94=
 
If the Device is willing to conform to the =93rejection= =94, why did it pick =96 and report =96 a non-conforming value to start wit= h? 

Well, quite :)

In theory of course a device shouldn't do that, but this is in ef= fect the OFCOM requirement.

I'll suggest to the OFCOM folks that the SPECTRUM_USE_NOTIFY should be= come "informational only", and not require any positive action ot= her than logging those values.

kind regards,

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991wdsexc1oknanomi_-- From Ray.Bellis@nominet.org.uk Fri Jul 26 07:35:01 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 A7D3E21F99EB for ; Fri, 26 Jul 2013 07:35:01 -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=[AWL=0.000, 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 EAfv27Zu2MHl for ; Fri, 26 Jul 2013 07:34:56 -0700 (PDT) Received: from mx1.nominet.org.uk (mx1.nominet.org.uk [213.248.242.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5B41921F99E1 for ; Fri, 26 Jul 2013 07:34:55 -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=lBtejL+itFlNG8/rqk9KMrUF9XuvRaFB4tmJpi8DgEjF8QX9nJUrjnwb +nZjCLDUEbvCqZqNzXHy9cTz8amXA4QCcKxvqqRB6L27qAp0127i7v2Oc ZafjXEkVbRngnJT; 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=1374849296; x=1406385296; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TtLT3iVbmvjRArYfGqP9KsaqomxvhELBZreoOZX8Q2A=; b=mgYZ4tUP+qOwl38+ifQgySHOIe+BV2LEYrtjDz0beh0DdE/yJS5klem+ +fd2Y/i5Ygy31OHAz8DzSisOvmbttWbONavqGqCHantn9z6w+USwnKRzT heFRc7bArmUyaSV; X-IronPort-AV: E=Sophos;i="4.89,751,1367967600"; d="scan'208";a="2284454" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx1.nominet.org.uk with ESMTP; 26 Jul 2013 15:34:53 +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, 26 Jul 2013 15:34:53 +0100 From: Ray Bellis To: Vincent Chen Thread-Topic: [paws] definition of Slave device Thread-Index: AQHOiUWKnLV87tOKrE2oRwahCfbUl5l1d/kAgACxEoCAAFhnAIAAczAAgAACpIA= Date: Fri, 26 Jul 2013 14:34:52 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE161E9@wds-exc1.okna.nominet.org.uk> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE14132@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: text/plain; charset="iso-8859-1" Content-ID: <0D82A3996FC8F84A9E24260F3C65C756@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] definition of Slave device 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, 26 Jul 2013 14:35:01 -0000 On 26 Jul 2013, at 15:25, Vincent Chen wrote: > In the ETSI / OFCOM model, is Slave a "role" or a static / certified prop= erty of the device? I would tend towards the latter. The ETSI draft standard contains this def= inition: "slave WSD: WSD that is only able to communicate with other WSDs, when unde= r the control of a master WSD" and this: "master WSD: geo-located WSD that is able to communicate directly with a TV= WSDB and with WSDs" > Consider the use case: > - A portable device has location capability, but is not yet on a networ= k > - It acts like a Slave in this phase to contact a Master in order to get= spectrum > - It now can establish network connection to the Database directly using= the spectrum >=20 > In the ETSI / OFCOM model: > 1. Can it now ask the Database directly for spectrum? because it may be = able to operate at higher power? I believe that this is *not* permitted. A slave device that has geolocatio= n capability MAY ask for device specific RF parameters, but MUST do so thro= ugh its Master. OFCOM's specification explicitly prohibits a (master) WSD from talking to t= he WSDB over the managed UHF spectrum, it needs to use some other form of l= ink. kind regards, Ray From vchen@google.com Fri Jul 26 08:31:12 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 3FE6021F9A17 for ; Fri, 26 Jul 2013 08:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.149, 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 Re4q43okzZpF for ; Fri, 26 Jul 2013 08:31:11 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 79D7621F99E8 for ; Fri, 26 Jul 2013 08:31:11 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id m6so905819oag.20 for ; Fri, 26 Jul 2013 08:31:10 -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=WSJtDEAzST6SBk4m+5HeZGI6IOk6KphJ1QFgOujIEhw=; b=Z2hQQ/ueNTW9d6mp2aqD5w5on5goNCj6ztLM/S3y+XbzC3aSskA7MfkCHemoR4g8k8 j89grTxHioQKHTYLfPFWQKL12I8+mi2dNvA15CpQD8exfOcLVmo1jnHTAubEYmLKrwSk EcpW9uWx42dZaAW/8c26L1pzscSEr5VEw5zUBGOJT1FQO2vEhLkS3fqq96q4L+iIrU43 CvuiGoe3LsUgwB3b7jtcVIreUszMXywnZzKvK4WCm9EPK7pfrr2YoV5W7Gw+Z+oK83S6 bD+C4mxRx1OfZo8dfUQkyYs8zzAhidRcfvsOIOUki6caKRLxuz9vaRrUn318W1pLz5F1 SyXQ== X-Google-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:x-gm-message-state; bh=WSJtDEAzST6SBk4m+5HeZGI6IOk6KphJ1QFgOujIEhw=; b=HV32sM5jCeb9aGnadm2MeRZveBgVdkx07XWhPXXTyhrfi3lpmprQbbDIY1UNn1tkq0 yXpL8CpIaLTv8rIL/xIMjrrzEBMx+GHy+eC4LffE7il62o84Y49hstgoV5wg8vYlPUmK 3SYTnEUYc+OHS6/eJ8aiHjL/rUQbtrWmyTPNP91Umjd1mOjQRsySYGG8yQ5/8U6PBAlP wKCUfwOoYfHYbUBHCPJmvnxs8dyIZznnbmMaS9xYTFEoNNJ0gl1Azlnv0M0sjCqpnY7N ELneMlGKLKRiiOi8SC8HS5jghmArYW2Y+xobsXrwK15m3roD9xVXYOAetL4pMTq7Fs27 LwhQ== MIME-Version: 1.0 X-Received: by 10.182.128.42 with SMTP id nl10mr41542409obb.41.1374852669509; Fri, 26 Jul 2013 08:31:09 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Fri, 26 Jul 2013 08:31:09 -0700 (PDT) In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE161E9@wds-exc1.okna.nominet.org.uk> References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE14132@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE161E9@wds-exc1.okna.nominet.org.uk> Date: Fri, 26 Jul 2013 08:31:09 -0700 Message-ID: From: Vincent Chen To: Ray Bellis Content-Type: multipart/alternative; boundary=e89a8ff1cc9efc33f504e26bd494 X-Gm-Message-State: ALoCoQnyIc1kcg5EOwZW47I6McOH++j8orS1PbS4JfGzb8uZTdMpDJGdtxa4mBMnzwTCS5a7ENgFTXZV+2JWgzn0+lkL6EheZLhWCB+SOucstx29XfcR9+XQ6upn09k6fS/wTw4Hm6Tb9MVBOBdHftpGIS692Yglq/kqOr4uDg8EoNUh/JcOgeojX5tfHIauq7vMZeijErEs Cc: "paws@ietf.org" Subject: Re: [paws] definition of Slave device 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, 26 Jul 2013 15:31:12 -0000 --e89a8ff1cc9efc33f504e26bd494 Content-Type: text/plain; charset=ISO-8859-1 In that case, I believe the PAWS document should refer to Slave and Master as roles, and I should not include the last sentence in the proposed text. We probably also need to add: Whether a single device is allowed to serve both Slave and Master roles depends on regulatory rules. -vince On Fri, Jul 26, 2013 at 7:34 AM, Ray Bellis wrote: > > On 26 Jul 2013, at 15:25, Vincent Chen wrote: > > > In the ETSI / OFCOM model, is Slave a "role" or a static / certified > property of the device? > > I would tend towards the latter. The ETSI draft standard contains this > definition: > > "slave WSD: WSD that is only able to communicate with other WSDs, when > under the control of a master WSD" > > and this: > > "master WSD: geo-located WSD that is able to communicate directly with a > TVWSDB and with WSDs" > > > Consider the use case: > > - A portable device has location capability, but is not yet on a > network > > - It acts like a Slave in this phase to contact a Master in order to > get spectrum > > - It now can establish network connection to the Database directly > using the spectrum > > > > In the ETSI / OFCOM model: > > 1. Can it now ask the Database directly for spectrum? because it may be > able to operate at higher power? > > I believe that this is *not* permitted. A slave device that has > geolocation capability MAY ask for device specific RF parameters, but MUST > do so through its Master. > > OFCOM's specification explicitly prohibits a (master) WSD from talking to > the WSDB over the managed UHF spectrum, it needs to use some other form of > link. > > kind regards, > > Ray > > > -- -vince --e89a8ff1cc9efc33f504e26bd494 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In that case, I believe the PAWS document should refer to = Slave and Master as roles, and I should not include the last sentence in th= e proposed text.

We probably also need to add:

=A0 Whether a single device is allowed to serve both Slave a= nd Master roles depends on regulatory rules.

-vinc= e


On Fri, Jul 26, 2013 at 7:34 AM, Ray Bellis <Ray.Bellis@nominet.= org.uk> wrote:

On 26 Jul 2013, at 15:25, Vincent Chen <vchen@google.com> wrote:

> In the ETSI / OFCOM model, is Slave a "role" or a static / c= ertified property of the device?

I would tend towards the latter. =A0The ETSI draft standard contains = this definition:

"slave WSD: WSD that is only able to communicate with other WSDs, when= under the control of a master WSD"

and this:

"master WSD: geo-located WSD that is able to communicate directly with= a TVWSDB and with WSDs"

> Consider =A0the use case:
> =A0- =A0A portable device has location capability, but is not yet on a= network
> =A0- It acts like a Slave in this phase to contact a Master in order t= o get spectrum
> =A0- It now can establish network connection to the Database directly = using the spectrum
>
> In the ETSI / OFCOM model:
> =A01. Can it now ask the Database directly for spectrum? because it ma= y be able to operate at higher power?

I believe that this is *not* permitted. =A0A slave device that has ge= olocation capability MAY ask for device specific RF parameters, but MUST do= so through its Master.

OFCOM's specification explicitly prohibits a (master) WSD from talking = to the WSDB over the managed UHF spectrum, it needs to use some other form = of link.

kind regards,

Ray





--
-vince
--e89a8ff1cc9efc33f504e26bd494-- From dharasty@appcomsci.com Fri Jul 26 08:41:47 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 1599F11E80F4 for ; Fri, 26 Jul 2013 08:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 M30aXBLZmLEA for ; Fri, 26 Jul 2013 08:41:40 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id AB85221F99AB for ; Fri, 26 Jul 2013 08:41: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 r6QFfeXR021498; Fri, 26 Jul 2013 11:41:40 -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 r6QFfdIj017300; Fri, 26 Jul 2013 11:41:39 -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; Fri, 26 Jul 2013 11:41:39 -0400 From: "Harasty, Daniel J" To: Ray Bellis Thread-Topic: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response Thread-Index: AQHOidOFq/a9qPEX8UCpvsJheVb3Tpl221kwgABTzQD//+cvcA== Date: Fri, 26 Jul 2013 15:41:18 +0000 Message-ID: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991@wds-exc1.okna.nominet.org.uk> In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991@wds-exc1.okna.nominet.org.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEEFB56rrcatsexmb2atsa_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 15:41:47 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEEFB56rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, Thanks for considering my input. I want to make clear that I'm not opposed to the notion of the ability for = the Database to "reject" a Device's selection, or somehow "rescind" a chann= el previously stated as available -- provided if there is a widely accepted= use case based on regulatory guidelines. My original proposal is more about nomenclature than use case. Just to be c= lear about my input: * If SPECTRUM_USE_NOTIFY is a "true notification", let's use the JS= ONRPC "notification" message type for SPECTRUM_USE_NOTIFY, and strike the [= empty] SPECTRUM_USE_RESP from PAWS. * If there is a bonafide use case for the Database to "reject" or "= rescind", let's define an appropriate pair of messages, such as SPECTRUM_US= E_REQ and [a non-empty] SPECTRUM_USE_RESP. * If necessary, update ruleset definitions to clarify which is used= when/where. Kindest regards, Dan From: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk] Sent: Friday, July 26, 2013 8:59 AM To: Harasty, Daniel J Cc: paws@ietf.org Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response > If the Device is willing to conform to the "rejection", why did it pick = - and report - a non-conforming value to start with? Well, quite :) In theory of course a device shouldn't do that, but this is in effect the O= FCOM requirement. I'll suggest to the OFCOM folks that the SPECTRUM_USE_NOTIFY should become = "informational only", and not require any positive action other than loggin= g those values. kind regards, Ray --_000_EC510C021D06A34C92F5A5A488B5290B0CEEFB56rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,=

 

Thanks for considering my input.

 

I want to make clear that I’m not opposed to the notion= of the ability for the Database to “reject” a Device’s s= election, or somehow “rescind” a channel previously stated as a= vailable -- provided if there is a widely accepted use case based on regula= tory guidelines.

&nbs= p;

My original proposal is more= about nomenclature than use case. Just to be clear about my input:

·     &nb= sp;   If SPECTRUM_USE_NOTIF= Y is a “true notification”, let’s use the JSONRPC “= notification” message type for SPECTRUM_USE_NOTIFY, and strike the [e= mpty] SPECTRUM_USE_RESP from PAWS.

<= span style=3D'mso-list:Ignore'>·         If there is a bonafide use case for the Database to &#= 8220;reject” or “rescind”, let’s define an appropri= ate pair of messages, such as SPECTRUM_USE_REQ and [a non-empty] SPECTRUM_U= SE_RESP.

·   = ;      If n= ecessary, update ruleset definitions to clarify which is used when/where.

 

Kindest regards,

 

Dan

 

 

 

F= rom: Ray Bellis [mailto:Ray.Bellis@nominet.org.uk]
Sent: Frid= ay, July 26, 2013 8:59 AM
To: Harasty, Daniel J
Cc: paw= s@ietf.org
Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature = and response

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>>  If the Device is willing to conform to the &= #8220;rejection”, why did it pick – and report – a non-co= nforming value to start with? 

<= p class=3DMsoNormal> 

Well, q= uite :)

 

=

In theory of course a device shouldn't do t= hat, but this is in effect the OFCOM requirement.

=

 

I'll suggest to the OFCOM folks that the SPECTRUM_USE_NOTIFY should bec= ome "informational only", and not require any positive action oth= er than logging those values.

 

kind regards,

 

Ray

&nb= sp;

= --_000_EC510C021D06A34C92F5A5A488B5290B0CEEFB56rrcatsexmb2atsa_-- From sajeevmanikkoth@gmail.com Fri Jul 26 08:56:55 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 9D2BD21F9256 for ; Fri, 26 Jul 2013 08:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.691 X-Spam-Level: X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-0.093, 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 2ih0cvYyFQ0Z for ; Fri, 26 Jul 2013 08:56:53 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A02C021F9130 for ; Fri, 26 Jul 2013 08:56:53 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md4so2176773pbc.35 for ; Fri, 26 Jul 2013 08:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=uCzLvNuF9NppagX45b5sV1gufCIaH1FNEh7URJxtkAE=; b=IHuCd1Q9cW/25LN+gMnXpxeViioWSwTSsaOVMwpe7ji0k5yyUi17HFVVVyKWBJzGqg 9UmQtK+7DU8zHfq1pLdj4vcfauUVKvavQ4Wfgc8SKeofBB0KoiIP643Byu4gbtBkwVKa NkTlzHmr/+RzX7ykINoC6ddFIEsydgyXVimVQm6tMKuZ83FCq3aQtrIuh0rF32pOngpG v7t2VMUa+eLQX2avxG1EsTfXKOwpgaaogY0KGe7vO25aCQF8S/OSu31T5rkMQwc3JCZR vsnVbUt3Pye+q8Q0XIJMoILV4bQ7CRVh5tlIzscxW0CK87MOG/DCBgHHMlWo1KrqyAMW M5gw== X-Received: by 10.66.122.5 with SMTP id lo5mr11485807pab.175.1374854213186; Fri, 26 Jul 2013 08:56:53 -0700 (PDT) Received: from adminPC ([49.249.34.47]) by mx.google.com with ESMTPSA id il4sm60804805pbb.36.2013.07.26.08.56.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 08:56:51 -0700 (PDT) From: sajeevmanikkoth@gmail.com To: "'Vincent Chen'" , "'Ray Bellis'" References: <1ECAFF543A2FED4EA2BEB6CACE08E476022EBEBB@008-AM1MPN1-006.mgdnok.nokia.com> <003601ce8943$8cdc6030$a6952090$@org> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE14132@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE161E9@wds-exc1.okna.nominet.org.uk> In-Reply-To: Date: Fri, 26 Jul 2013 21:26:42 +0530 Message-ID: <009c01ce8a18$bdce5fb0$396b1f10$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009D_01CE8A46.D7869BB0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6KFSr1y5+FEnuPR1uFcgQJmU0e2AAAhrsQ Content-Language: en-us Cc: paws@ietf.org Subject: Re: [paws] definition of Slave device 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, 26 Jul 2013 15:56:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009D_01CE8A46.D7869BB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Even I would understand Slave/Master as roles which devices can play. Slave device as: "A device which does not directly communicate with WSDB, and uses services of Master to communicate with other WSDs." Geo-location and other capabilities whether it can have or not is not really in scope of the definition. Yes, the device should have whitespace radio capabilities, and a way to communicate with Master for sure. Regards, Sajeev From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen Sent: Friday, July 26, 2013 9:01 PM To: Ray Bellis Cc: paws@ietf.org Subject: Re: [paws] definition of Slave device In that case, I believe the PAWS document should refer to Slave and Master as roles, and I should not include the last sentence in the proposed text. We probably also need to add: Whether a single device is allowed to serve both Slave and Master roles depends on regulatory rules. -vince On Fri, Jul 26, 2013 at 7:34 AM, Ray Bellis wrote: On 26 Jul 2013, at 15:25, Vincent Chen wrote: > In the ETSI / OFCOM model, is Slave a "role" or a static / certified property of the device? I would tend towards the latter. The ETSI draft standard contains this definition: "slave WSD: WSD that is only able to communicate with other WSDs, when under the control of a master WSD" and this: "master WSD: geo-located WSD that is able to communicate directly with a TVWSDB and with WSDs" > Consider the use case: > - A portable device has location capability, but is not yet on a network > - It acts like a Slave in this phase to contact a Master in order to get spectrum > - It now can establish network connection to the Database directly using the spectrum > > In the ETSI / OFCOM model: > 1. Can it now ask the Database directly for spectrum? because it may be able to operate at higher power? I believe that this is *not* permitted. A slave device that has geolocation capability MAY ask for device specific RF parameters, but MUST do so through its Master. OFCOM's specification explicitly prohibits a (master) WSD from talking to the WSDB over the managed UHF spectrum, it needs to use some other form of link. kind regards, Ray -- -vince ------=_NextPart_000_009D_01CE8A46.D7869BB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Even I would understand Slave/Master as roles which = devices can play. Slave device as:  “A device which does not directly communicate with WSDB, and uses services of Master to communicate with = other WSDs.” Geo-location and  other capabilities whether it can = have or not is not really in scope of the definition. Yes, the device should have = whitespace radio capabilities, and a way to communicate with Master for = sure.

 

Regards,

Sajeev

 

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Vincent Chen
Sent: Friday, July 26, 2013 9:01 PM
To: Ray Bellis
Cc: paws@ietf.org
Subject: Re: [paws] definition of Slave = device

 

In that case, I believe the PAWS document should = refer to Slave and Master as roles, and I should not include the last sentence in = the proposed text.

 

We probably also need to add:

 

  Whether a single device is allowed to serve = both Slave and Master roles depends on regulatory rules.

 

-vince

 

On Fri, Jul 26, 2013 at 7:34 AM, Ray Bellis <Ray.Bellis@nominet.org.uk> wrote:


On 26 Jul 2013, at 15:25, Vincent Chen <vchen@google.com> wrote:

> In the ETSI / OFCOM model, is Slave a "role" or a static = / certified property of the device?

I would tend towards the latter.  The ETSI = draft standard contains this definition:

"slave WSD: WSD that is only able to communicate with other WSDs, = when under the control of a master WSD"

and this:

"master WSD: geo-located WSD that is able to communicate directly = with a TVWSDB and with WSDs"


> Consider  the use case:
>  -  A portable device has location capability, but is not = yet on a network
>  - It acts like a Slave in this phase to contact a Master in = order to get spectrum
>  - It now can establish network connection to the Database = directly using the spectrum
>
> In the ETSI / OFCOM model:
>  1. Can it now ask the Database directly for spectrum? because = it may be able to operate at higher power?

I believe that this = is *not* permitted.  A slave device that has geolocation capability MAY ask = for device specific RF parameters, but MUST do so through its Master.

OFCOM's specification explicitly prohibits a (master) WSD from talking = to the WSDB over the managed UHF spectrum, it needs to use some other form of = link.

kind regards,

Ray



 

--
-vince

------=_NextPart_000_009D_01CE8A46.D7869BB0-- From sajeevmanikkoth@gmail.com Fri Jul 26 09:09:08 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 36C9621F9546 for ; Fri, 26 Jul 2013 09:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 GErNv5MiN9FE for ; Fri, 26 Jul 2013 09:09:06 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9D23A21F92C2 for ; Fri, 26 Jul 2013 09:09:06 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so3088633pdj.0 for ; Fri, 26 Jul 2013 09:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=/7KaHc6HOpOTSLToX7bNb6IZYiSC4g+u8V0aoydmiDU=; b=y7BMbmCgx4TSu82Y2r0VdVvdV01lekc2XlSOS1jt6I+37SSOhRBn3dAHj16Dsm0JJQ oXchZJ3MU5fSfZxdivZXl5VftpO23ciNENwMft9My6lnHyDZ4ZqjJOQ143XyqmnDD1xi EBrStd7rPYvhfpDr+LmoKabcYu0AoaqUYIDbiiKrqZCpEg0KaxRCnZmhxCX+my9uIgeX WtZaLrPhchecW9TfovQkyTBAK8WSw8/FIbe2tzNQWO0qagEgoXY4piZTrVfjXBV6K0uk 1hu6ZjrVTkEQx+j8lMr9WPJeTkwfSfP1QULa6L+INcWeD86cQtvEiFkPDvHqAEujedY5 1HfQ== X-Received: by 10.68.107.226 with SMTP id hf2mr55066256pbb.28.1374854946228; Fri, 26 Jul 2013 09:09:06 -0700 (PDT) Received: from adminPC ([49.249.34.47]) by mx.google.com with ESMTPSA id br1sm60953958pbb.4.2013.07.26.09.09.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 09:09:05 -0700 (PDT) From: sajeevmanikkoth@gmail.com To: "'Vincent Chen'" , "'Harasty, Daniel J'" References: In-Reply-To: Date: Fri, 26 Jul 2013 21:38:51 +0530 Message-ID: <00a101ce8a1a$7288bdf0$579a39d0$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01CE8A48.8C40F9F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6JTgoW3Olw+S1nSYiiI5tuUH4b+QAy0xMQ Content-Language: en-us Cc: paws@ietf.org Subject: Re: [paws] including a timestamp in every message 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, 26 Jul 2013 16:09:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01CE8A48.8C40F9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, In the PAWS working, geo-location(latitude/longitude), and timestamp are the 2 key parameters which affects the spectrum availability and use. That way I would like to see even these 2 values to be embedded in all the protocol transactions. Perhaps these 2 values, together with device id gives a whitespace context too. Also as seen in this mail chain which may help in identifying, and rejecting security threats. Thanks and Regards, Sajeev From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen Sent: Thursday, July 25, 2013 9:16 PM To: Harasty, Daniel J Cc: paws@ietf.org Subject: Re: [paws] including a timestamp in every message I would agree with Dan. Given questionable reliability of time base on devices, the Database should not trust timestamps in the request, even when they are provided. Thus, it does seem like "chatter". -vince On Thu, Jul 25, 2013 at 7:51 AM, Harasty, Daniel J wrote: I'd like to comment some of Sanjeev's input. I prefer to send independent replies on each topic, as that way a given email thread is about a single topic (more or less). Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 2. It will be a good thing to include 'timestamp:string requirted' paramter in all the protocol transactions [...] I don't see the purpose in this. I don't see how the operation of the Database - or the way it will respond to any given request - is dependent on it knowing what time the Device thinks it is. (Or vice versa.) Unless someone can point out a use case for this field, I consider it unneeded "chatter" in the protocol. That said, the Database or Device can easily ignore it, so I won't push back if others believe this field is generally useful. Dan _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince ------=_NextPart_000_00A2_01CE8A48.8C40F9F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In the PAWS working, geo-location(latitude/longitude), = and timestamp are the 2 key parameters which affects the spectrum = availability and use. That way I would like to see even these 2 values to be embedded in = all the protocol transactions. Perhaps these 2 values, together with device id = gives a whitespace context too. Also as seen in this mail chain which may help = in identifying, and rejecting security threats.

 

Thanks and Regards,

Sajeev

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
Sent: Thursday, July 25, 2013 9:16 PM
To: Harasty, Daniel J
Cc: paws@ietf.org
Subject: Re: [paws] including a timestamp in every = message

 

I would agree with Dan. Given questionable = reliability of time base on devices, the Database should not trust timestamps in the = request, even when they are provided.

Thus, it does seem like = "chatter".

 

-vince

 

On Thu, Jul 25, 2013 at 7:51 AM, Harasty, Daniel J = <dharasty@appcomsci.com> wrote:

I'd like to comment some of Sanjeev's input.

 <= /o:p>

I prefer to send independent replies on each topic, as that way a given = email thread is about a single topic (more or less).

 <= /o:p>

Sanjeev mentioned:

 <= /o:p>

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

2. It will be a good thing to include = 'timestamp:string requirted' paramter in all the protocol transactions

[...]

 

I don’t see the purpose in this.  I don’t see how the = operation of the Database – or the way it will respond to any given request = – is dependent on it knowing what time the Device thinks it is.  (Or = vice versa.)

 <= /o:p>

Unless someone can point out a use case for this field, I consider it unneeded “chatter” in the protocol.  That said, the Database or = Device can easily ignore it, so I won’t push back if others believe this = field is generally useful.

 <= /o:p>

Dan

 <= /o:p>

 <= /o:p>


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



 

--
-vince

------=_NextPart_000_00A2_01CE8A48.8C40F9F0-- From sajeevmanikkoth@gmail.com Fri Jul 26 09:33:27 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 36C6321F9A8E for ; Fri, 26 Jul 2013 09:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.062, 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 38wrgRmp6ARr for ; Fri, 26 Jul 2013 09:33:24 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 877E521F99C7 for ; Fri, 26 Jul 2013 09:33:24 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so2925939pde.10 for ; Fri, 26 Jul 2013 09:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=1QDAMS8IvDFvCs5melusAmAZVPSh5Jyk92CDKGc6aGU=; b=gGZ41YkaPCBUlxVxHp+JwsEre7NMqSR4fS9arAqRBhIE3ESH9IkDhz74nppHCZvPOW H+9IhZegdrj9tdbO+XJx8/Zk0Lg6lSclaMtodxglkpNVjCXTXPdfaYTldRwDT0Agu8bx /X4FIKo5plYJfEXgVGEpHSkjcO4z/4O+Z/AXeUPtJF92ArQfvg5Y4v1RnWifHwEya9C8 Dl0BfaibpMj6MVaXhUFQlaCYV1z3VAnbwdD+/Dxmx3cSgQpdN6GBYciGlfrf/S4aMpSo uNLJYQ1ow/lb0+rJSO3A3gAoHkyvJfl2L7B5T29iv+z7Q8G2JLhCZMZFoI7TkR1N7fiW /7yA== X-Received: by 10.68.198.101 with SMTP id jb5mr37841081pbc.127.1374856404185; Fri, 26 Jul 2013 09:33:24 -0700 (PDT) Received: from adminPC ([49.249.34.47]) by mx.google.com with ESMTPSA id 4sm60975345pbw.32.2013.07.26.09.33.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 09:33:23 -0700 (PDT) From: sajeevmanikkoth@gmail.com To: "'Vincent Chen'" References: <004601ce894c$914b8b10$b3e2a130$@com> In-Reply-To: Date: Fri, 26 Jul 2013 22:03:08 +0530 Message-ID: <00a601ce8a1d$d776b9d0$86642d70$@org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01CE8A4B.F12EF5D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6JUBabNptw/jx0QvKvgudqM16HkwAyRaBA Content-Language: en-us Cc: paws@ietf.org Subject: Re: [paws] response to REGISTRATION_REQ 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, 26 Jul 2013 16:33:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A7_01CE8A4B.F12EF5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vince, My point was not HTTP server errors, but errors which arises out of the PAWS semantics scope. 1. For REGISTRATION_REQ, I have 2 points. One its response should also include 'rulesetInfo:RulesetInfo as required' parameter. Second, its response can have accepted/not accepted kind of semantics. It may add some complexity, if we want to process all the different error conditions, but a binary semantics may help the Master in its operation. 2. . SPECTRUM_USE_NOTIFY is not mere a fire and forget notification, instead a request/response transaction was my understanding. A possible case where a DB can reject the SPECTRU_USE request is: the spectrum which the Master device intend to use is no longer been available, as the Primary spectrum user is back on to operation, and DB wanted to mark it as no longer available. May be rare but it can happen. And if the Master device gets such an error from DB, it should pick any other available spectrum, and notify again or sent a fresh AVAIL_SPECTRUM request to the DB. Thanks and Regards, Sajeev From: Vincent Chen [mailto:vchen@google.com] Sent: Thursday, July 25, 2013 9:30 PM To: Sajeev Manikkoth Cc: Harasty, Daniel J; paws@ietf.org Subject: Re: [paws] response to REGISTRATION_REQ Dan, Sajeev, I was assuming that general "server errors" would be handled at the HTTP layer with 5xx codes. 1. For REGISTRATION_REQ, what error conditions should we be capturing? - Some internal error, but can try again later? 2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did get an error? I was assuming that this is a async notify, fire-and-forget, from the perspective of the device -vince On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth wrote: Hi Daniel, First of all thank you very much for streamlining my comments, and splitting it into separate email topics. May be I need to take care of it next time.. Yes, the semantic you suggest here also can be the solution. My point was, an authorized master's request also can fail, because of load at database, or due to request semantic error. As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a generic response accepted/denied. Best Regards, Sajeev From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Harasty, Daniel J Sent: Thursday, July 25, 2013 8:35 PM To: paws@ietf.org Subject: [paws] response to REGISTRATION_REQ Sanjeev mentioned: From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM [...] 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database? [...] As for possible responses to REGISTRATION_REQ, I have been planning to suggest this: I think we need a new generic error code "REGISTRATION_FAILED". Perhaps a value -203, or the next available -200-block code. This should be used by the Database in response to a REGISTRATION_REQ if no other more specific code is applicable. (For example: if a registration failed due to a missing field in REGISTRATION_REQ, the Database should still send the REQUIRED error; if a REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still send the UNAUTHORIZED error.) Sanjeev: does that address your need sentiment for "a denied registration"? Dan (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.) _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince ------=_NextPart_000_00A7_01CE8A4B.F12EF5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vince,

 

My point was not HTTP server errors, but errors which = arises out of the PAWS semantics scope.

 

1.  For REGISTRATION_REQ, I have 2 points. One its = response should also include = 'rulesetInfo:RulesetInfo     as  required' parameter. Second, its response can have accepted/not accepted kind of semantics. It may add some complexity, if = we want to process all the different error conditions, but a binary semantics = may help the Master in its operation.

 

2. . SPECTRUM_USE_NOTIFY is not mere a fire and forget notification, instead a request/response transaction was my = understanding. A possible case where a DB can reject the SPECTRU_USE request is: the = spectrum which the Master device intend to use is no longer been available, as the = Primary spectrum user is back on to operation, and DB wanted to mark it as no longer = available. May be rare but it can happen. And if the Master device gets such an = error from DB, it should pick any other available spectrum, and notify again or = sent a fresh AVAIL_SPECTRUM request to the DB.

 

Thanks and Regards,

Sajeev

 

From:= Vincent = Chen [mailto:vchen@google.com]
Sent: Thursday, July 25, 2013 9:30 PM
To: Sajeev Manikkoth
Cc: Harasty, Daniel J; paws@ietf.org
Subject: Re: [paws] response to = REGISTRATION_REQ

 

Dan, Sajeev,

 

I was assuming that general "server = errors" would be handled at the HTTP layer with 5xx codes.

 

1. For REGISTRATION_REQ, what error conditions = should we be capturing?

   - Some internal error, but can try = again later?

 

2. SPECTRUM_USE_NOTIFY. What would the device do = differently if it did get an error?

  I was assuming that this is a async notify, fire-and-forget, from the perspective of the device

 

-vince

 

On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth = <sajeevmanikkoth@gmail.com> wrote:

Hi Daniel,

 

First of all thank you very much for = streamlining my comments, and splitting it into separate email topics. May be I need to = take care of it next time..

 

Yes, the semantic you suggest here also can be = the solution. My point was, an authorized master’s request also can = fail, because of load at database, or due to request semantic error. =

As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a generic response accepted/denied.

 <= /o:p>

Best Regards,

Sajeev<= /o:p>

 

From:= paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: paws@ietf.org
Subject: [paws] response to = REGISTRATION_REQ

 <= /o:p>

Sanjeev mentioned:

 <= /o:p>

From: sajeevmanikkoth@gmail.com
Sent: Thursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY = transctions; can it have repsonses like accepted/denied by database?

[...]

 

As for possible responses to REGISTRATION_REQ, I have been planning to = suggest this:  I think we need a new generic error code “REGISTRATION_FAILED”.  Perhaps a value -203, or the = next available -200-block code. 

 <= /o:p>

This should be used by the Database in response to a REGISTRATION_REQ if no = other more specific code is applicable.  (For example: if a registration = failed due to a missing field in REGISTRATION_REQ, the Database should still = send the REQUIRED  error; if a REGISTRATION_REQ failed due to the Device = being unauthorized, the Database should still send the UNAUTHORIZED = error.)

 <= /o:p>

Sanjeev: does that address your need sentiment for “a denied = registration”?

 <= /o:p>

Dan

 <= /o:p>

(I have a separate comment about SPECTRUM_USE_NOTIFY, to = follow.)

 <= /o:p>


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



 

--
-vince

------=_NextPart_000_00A7_01CE8A4B.F12EF5D0-- From buddenbergr@gmail.com Fri Jul 26 10:07:57 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 83B1C21F91B7 for ; Fri, 26 Jul 2013 10:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noYfM556uC0u for ; Fri, 26 Jul 2013 10:07:57 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4BB21F918F for ; Fri, 26 Jul 2013 10:07:57 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 4so3096348pdd.20 for ; Fri, 26 Jul 2013 10:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:mime-version:content-transfer-encoding; bh=6HHFxY7NlrYeKu5Fb3YtkzGMKYV9KnxawT8sBKiaFsU=; b=pnEeFMs5bJb0GFF79aN3PFv94jQlH6gh0+iIr29s7iAbeSXAN42lrG3VvAMP9glKhh LDBJbGS4QXMKDfATMjLa1PM6TL6PzdCm93HLxrWlI2hJieaSu8sEM//KtERoCKtHjyPa slgGAQPwjXrW1sJyXqe7OOJfgs3sWE9DaEsqlWSto7WxPAnfHyghFV5Y1Qchw+XVQTlv OCh8UNzUX9KttxDkBTru4LfT2JSObo9iHyGyMBqyqQh+YEPCEYJk0btELnKEKC8bJJl/ M9yYKFypdmmlFRA8bVi5QDWFWODbGIgn1tMUyVN2s6OJNL+IIfan8PhbdewvJau0SLt2 0K/g== X-Received: by 10.68.131.133 with SMTP id om5mr55025094pbb.148.1374858476836; Fri, 26 Jul 2013 10:07:56 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPSA id iq6sm61216059pbc.1.2013.07.26.10.07.55 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jul 2013 10:07:56 -0700 (PDT) Message-ID: <1374858474.1735.73.camel@localhost> From: Rex Buddenberg To: "Harasty, Daniel J" Date: Fri, 26 Jul 2013 10:07:54 -0700 In-Reply-To: References: <53F00E5CD8B2E34C81C0C89EB0B4FE732DE1422E@wds-exc1.okna.nominet.org.uk> <53F00E5CD8B2E34C81C0C89EB0B4FE732DE15991@wds-exc1.okna.nominet.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: "paws@ietf.org" Subject: Re: [paws] SPECTRUM_USE_NOTIFY: nomenclature and response 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, 26 Jul 2013 17:07:57 -0000 On Fri, 2013-07-26 at 15:41 +0000, Harasty, Daniel J wrote: > somehow “rescind” a channel previously stated as available -- provided > if there is a widely accepted use case based on regulatory guidelines. Dan, The use case has already been stated. Consider an emergency that requires a public safety mobilization type of response -- earthquake or hurricane or somebody flying airliners into buildings ... any will do. Emergency services needs to mobilize and they need more spectrum (or access to spectrum ... contention-free MACs are time-share): - to accommodate a quickly accelerated operations tempo - to replace wired connectivity that has been interrupted by the disaster. From vchen@google.com Fri Jul 26 10:11:00 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 C5D1921F9A57 for ; Fri, 26 Jul 2013 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.137, 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 AbcBKn8GxAep for ; Fri, 26 Jul 2013 10:10:59 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BB9B121F918F for ; Fri, 26 Jul 2013 10:10:59 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j6so8219382oag.29 for ; Fri, 26 Jul 2013 10:10:59 -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=YFCKH+IM5e+BwHi9EIbCE2gQHAg6f0bHTordY1uaJRY=; b=P5Xf9tTQZbitZb3z0QjZ413oPTvB9n4q1lBh8ubaQQPrYBqt+6+QLmW0yb/x1NnRfQ ZCkXGJRQ/CS14n1FRYg5dccE22NyJh0farfH6HUoLips+th06TcqKrPeG4mCLMgdIu8E 6Nr5AlVTM5xdk8M66R0tC3eqNRRKACmJNXgQxYF14JMX6xL6IyDzgiBR3AGUtf5OWCAq XNBciacFlM/ze7+Qox3XtQWqAlM6FCWC/Tq9zQj0mOZZBy5JM+N+i7Dw/MOia1CB6bKm lZ3PsGgtTRSGHD/a3sLrxipT0D+h7WX+BIRKjuVbUkseivUgBy3HEFXb1Id9EvuVixv4 ZYNQ== X-Google-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:x-gm-message-state; bh=YFCKH+IM5e+BwHi9EIbCE2gQHAg6f0bHTordY1uaJRY=; b=RS0mAwTnXIxO1QVwtfOUiPiqnWc3pWc7UdB0zSPnWbNq02ujVZTaxCEvpPYNvvV1Ts aKXSLd+WJHJ+tA+e1+Eq1rkN+2mE3l6joEoWbbkC1c4q9P645TXCFTeAN+xaUCf48ByL JG5Al/p8RmmlkL4tGsOw/DJjGndueccb0nd/Zg8rtg0YPtr/qe6L5NQXLnLoooQTtUbJ nUc3XzWii1CpsVP5UhCUSPxOMCoNAwVHAB4BijNdwbrpXBYKCU7fNlFPlbJ/62XwxkEx 0LyynCehnjP2p90RKHsFvaUjL/tAN03H3huQa200vriMcRMu6Tz6tYnASBngrWXHtC62 Dqyw== MIME-Version: 1.0 X-Received: by 10.182.142.66 with SMTP id ru2mr28196843obb.4.1374858659158; Fri, 26 Jul 2013 10:10:59 -0700 (PDT) Received: by 10.182.52.193 with HTTP; Fri, 26 Jul 2013 10:10:59 -0700 (PDT) In-Reply-To: <00a601ce8a1d$d776b9d0$86642d70$@org> References: <004601ce894c$914b8b10$b3e2a130$@com> <00a601ce8a1d$d776b9d0$86642d70$@org> Date: Fri, 26 Jul 2013 10:10:59 -0700 Message-ID: From: Vincent Chen To: Sajeev Manikkoth Content-Type: multipart/alternative; boundary=001a11c2e128fef96104e26d39f3 X-Gm-Message-State: ALoCoQnwDn03v3UPgRfA3HvQfNMLq1yoJX+Uu3occX5JJs1JXN+ucPG58lHlF1gHkICdbfXlL9wBSd303y3elhB8PBW0kbzEq2Xi+BrNHdD8knkow+64rs5DZyTZJZ7J3aIexEg47OokzUW6VJbZUHJ9zpCuotncA+a/CQap9W88mgDrXalBkpAJSByRpxaBpCip+AVNhQxx Cc: "paws@ietf.org" Subject: Re: [paws] response to REGISTRATION_REQ 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, 26 Jul 2013 17:11:00 -0000 --001a11c2e128fef96104e26d39f3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sajeev, On Fri, Jul 26, 2013 at 9:33 AM, wrote: > Hi Vince,**** > > ** ** > > My point was not HTTP server errors, but errors which arises out of the > PAWS semantics scope.**** > > ** ** > > 1. For REGISTRATION_REQ, I have 2 points. One its response should also > include 'rulesetInfo:RulesetInfo as required' parameter. Second, its > response can have accepted/not accepted kind of semantics. It may add som= e > complexity, if we want to process all the different error conditions, but= a > binary semantics may help the Master in its operation.**** > > ** ** > > 2. . SPECTRUM_USE_NOTIFY is not mere a fire and forget notification, > instead a request/response transaction was my understanding. A possible > case where a DB can reject the SPECTRU_USE request is: the spectrum which > the Master device intend to use is no longer been available, as the Prima= ry > spectrum user is back on to operation, and DB wanted to mark it as no > longer available. May be rare but it can happen. And if the Master device > gets such an error from DB, it should pick any other available spectrum, > and notify again or sent a fresh AVAIL_SPECTRUM request to the DB. > The issue is that if the Device picks any other spectrum and notifies again, it can still get a negative response. It seems easier for the Device to just have one set of logic that it implements periodically: - Ask for available spectrum, pick one - Pick one and Notify Rather than: - Ask for available spectrum - Pick one and notify ... some time later .. - Notify, get negative response - Pick another, get negative response ... - No more to pick, ask for available spectrum -vince > **** > > ** ** > > Thanks and Regards,**** > > Sajeev**** > > ** ** > > *From:* Vincent Chen [mailto:vchen@google.com] > *Sent:* Thursday, July 25, 2013 9:30 PM > > *To:* Sajeev Manikkoth > *Cc:* Harasty, Daniel J; paws@ietf.org > *Subject:* Re: [paws] response to REGISTRATION_REQ**** > > ** ** > > Dan, Sajeev,**** > > ** ** > > I was assuming that general "server errors" would be handled at the HTTP > layer with 5xx codes.**** > > ** ** > > 1. For REGISTRATION_REQ, what error conditions should we be capturing?***= * > > - Some internal error, but can try again later?**** > > ** ** > > 2. SPECTRUM_USE_NOTIFY. What would the device do differently if it did ge= t > an error?**** > > I was assuming that this is a async notify, fire-and-forget, from the > perspective of the device**** > > ** ** > > -vince**** > > ** ** > > On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth < > sajeevmanikkoth@gmail.com> wrote:**** > > Hi Daniel,**** > > **** > > First of all thank you very much for streamlining my comments, and > splitting it into separate email topics. May be I need to take care of it > next time..**** > > **** > > Yes, the semantic you suggest here also can be the solution. My point was= , > an authorized master=92s request also can fail, because of load at databa= se, > or due to request semantic error. **** > > As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting > a generic response accepted/denied.**** > > **** > > Best Regards,**** > > Sajeev**** > > **** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *Harasty, Daniel J > *Sent:* Thursday, July 25, 2013 8:35 PM > *To:* paws@ietf.org > *Subject:* [paws] response to REGISTRATION_REQ**** > > **** > > Sanjeev mentioned:**** > > **** > > From: sajeevmanikkoth@gmail.com > Sent: Thursday, July 25, 2013 10:31 AM**** > > [...]**** > > 5. REGISTRATION_REQ, and SPECTRUM_USE_NOTIFY transctions; can it have > repsonses like accepted/denied by database?**** > > [...]**** > > **** > > As for possible responses to REGISTRATION_REQ, I have been planning to > suggest this: I think we need a new generic error code > =93REGISTRATION_FAILED=94. Perhaps a value -203, or the next available > -200-block code. **** > > **** > > This should be used by the Database in response to a REGISTRATION_REQ if > no other more specific code is applicable. (For example: if a registrati= on > failed due to a missing field in REGISTRATION_REQ, the Database should > still send the REQUIRED error; if a REGISTRATION_REQ failed due to the > Device being unauthorized, the Database should still send the UNAUTHORIZE= D > error.)**** > > **** > > Sanjeev: does that address your need sentiment for =93a denied registrati= on=94? > **** > > **** > > Dan**** > > **** > > (I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.)**** > > **** > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > > > **** > > ** ** > > -- > -vince **** > --=20 -vince --001a11c2e128fef96104e26d39f3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Sajeev,


On Fri, Jul 26, 2013 at 9:33 AM, &= lt;sajeevman= ikkoth@gmail.com> wrote:

Hi Vince,

=A0<= /p>

My point was not HTTP ser= ver errors, but errors which arises out of the PAWS semantics scope.

=A0<= /p>

1.=A0 For REGISTRATION_REQ, I have 2 points. = One its response should also include 'rulesetInfo:RulesetInfo=A0=A0=A0=A0 as=A0 required' parameter. Second, its response can have accepted/not accepted kind of semantics. It may add some complexity, if we = want to process all the different error conditions, but a binary semantics may h= elp the Master in its operation.

=A0<= /p>

2. . SPECTRUM_USE_NOTIFY = is not mere a fire and forget notification, instead a request/response transaction was my understanding. = A possible case where a DB can reject the SPECTRU_USE request is: the spectru= m which the Master device intend to use is no longer been available, as the Primary= spectrum user is back on to operation, and DB wanted to mark it as no longer availab= le. May be rare but it can happen. And if the Master device gets such an error = from DB, it should pick any other available spectrum, and notify again or sent a= fresh AVAIL_SPECTRUM request to the DB.

<= br>
The issue is that if the Device picks any other spectrum and = notifies again, it can still get a negative response.

It seems easier for the Device to just have one set of logic that it i= mplements periodically:

=A0- Ask for available spe= ctrum, pick one
=A0- Pick one and Notify

Rather than:

=A0- Ask for available spectrum
=
=A0- Pick one and notify
=A0... some time later ..
=A0- Notify, get negative response
=A0- Pick another, get negati= ve response
=A0...
=A0- No more to pick, ask for available spectrum

-vince
=A0

=A0

Thanks and Regards,

Sajeev

=A0<= /p>

From: Vincent = Chen [mailto:vchen@google.= com]
Sent: Thursday, July 25, 2013 9:30 PM

To: Sajeev Manikkoth
Cc: Harasty, Daniel J; paws@ietf.org
Subject: Re: [paws] response to REGISTRATION_REQ
=

=A0

Dan, Sajeev,

=A0

I was assuming that general "server errors"= ; would be handled at the HTTP layer with 5xx codes.

=A0

1. For REGISTRATION_REQ, what error conditions shoul= d we be capturing?

=A0 =A0- Some internal error, but can try again late= r?

=A0

2. SPECTRUM_USE_NOTIFY. What would the device do dif= ferently if it did get an error?

=A0 I was assuming that this is a async notify, fire-and-forget, from the perspective of the device

=A0

-vince

=A0

On Thu, Jul 25, 2013 at 8:35 AM, Sajeev Manikkoth &l= t;sajeevmani= kkoth@gmail.com> wrote:

Hi Daniel,

=A0

First of all thank you= very much for streamlining my comments, and splitting it into separate email topics. May be I need to tak= e care of it next time..

=A0

Yes, the semantic you = suggest here also can be the solution. My point was, an authorized master=92s request also can fail, because of load at database, or due to request semantic error.

As SPECTRUM_USE_NOTIFY also can fall in such a category, I was suggesting a generic response accepted/denied.

=A0

Best Regards,

Sajeev

=A0

From: paws-bounces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of Harasty, Daniel J
Sent: Thursday, July 25, 2013 8:35 PM
To: paws@ietf.org=
Subject: [paws] response to REGISTRATION_REQ

=A0

Sanjeev mentioned:

=A0

From: sajeevmanikkoth@gmail.com Sent: Thursday, July 25, 2013 10:31 AM

[...]

5. REGISTRATION_REQ, and = SPECTRUM_USE_NOTIFY transctions; can it have repsonses like accepted/denied by database?

[...]

=A0

As for possible responses to REGISTRATION_REQ, I have been planning to suggest this: =A0I think we need a new generic error code =93REGISTRATION_FAILED=94.=A0 Perhaps a value -203, or the next available -200-block code.=A0

=A0

This should be used by the Database in response to a REGISTRATION_REQ if no othe= r more specific code is applicable.=A0 (For example: if a registration failed due to a missing field in REGISTRATION_REQ, the Database should still send = the REQUIRED =A0error; if a REGISTRATION_REQ failed due to the Device being unauthorized, the Database should still send the UNAUTHORIZED error.)

=A0

Sanjeev: does that address your need sentiment for =93a denied registration=94?

=A0

Dan

=A0

(I have a separate comment about SPECTRUM_USE_NOTIFY, to follow.)

=A0


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



=A0

--
-vince




--
-vince