From Peter.McCann@huawei.com Mon Jun 4 06:55:05 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0373521F85AA for ; Mon, 4 Jun 2012 06:55:05 -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=[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 vjqsKucXruUU for ; Mon, 4 Jun 2012 06:55:04 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id DC17B21F85A3 for ; Mon, 4 Jun 2012 06:55:03 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGV54652; Mon, 04 Jun 2012 09:55:03 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 4 Jun 2012 06:52:42 -0700 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.156]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Mon, 4 Jun 2012 06:52:41 -0700 From: Peter McCann To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: timeslots for PAWS in the upcoming Vancouver F2F Thread-Index: Ac0+kEJUhbpEW4ySQWiSgjjLjSbmoQDyPsvQ Date: Mon, 4 Jun 2012 13:52:41 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716E05DA6@dfweml512-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601F11872@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F11872@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.92] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] timeslots for PAWS in the upcoming Vancouver 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, 04 Jun 2012 13:55:05 -0000 Hi, Gabor, We anticipate bringing an updated protocol framework draft. (hope this note isn't too late). -Pete Gabor.Bajko@nokia.com wrote: > Folks, >=20 >=20 >=20 > I need to request a timeslot for PAWS at the upcoming Vancouver F2F=20 > meeting. >=20 > But in order to do that, I will need to know what drafts are coming up=20 > before the deadline. As a reminder, the use case and requirements=20 > document is being finalized, I do not expect the need for that to be=20 > presented in the F2F; is there going to be any documents on db=20 > discovery, any potential updates or new documents to the data model=20 > and protocol framework? >=20 > Please let me know *during this week*, as the deadline to request for=20 > a WG timeslot is on Monday. >=20 >=20 >=20 > Thanks, Gabor From Gabor.Bajko@nokia.com Thu Jun 7 08:39:57 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6718B21F86A3 for ; Thu, 7 Jun 2012 08:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dLF2IPjHYOn for ; Thu, 7 Jun 2012 08:39:55 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2059721F869C for ; Thu, 7 Jun 2012 08:39:50 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q57Fdn9s003299 for ; Thu, 7 Jun 2012 18:39:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 18:39:49 +0300 Received: from 008-AM1MPN1-001.mgdnok.nokia.com ([169.254.1.49]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.02.0283.004; Thu, 7 Jun 2012 17:39:48 +0200 From: To: Thread-Topic: 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQ Date: Thu, 7 Jun 2012 15:39:47 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601ED6676@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601ED6676@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374008AM1MPN1001mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jun 2012 15:39:49.0132 (UTC) FILETIME=[C5CAB4C0:01CD44C3] X-Nokia-AV: Clean Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 07 Jun 2012 15:39:57 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374008AM1MPN1001mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don't get reviews, we can't make progress. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let's hav= e another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Probasco = Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374008AM1MPN1001mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,<= /p>

 <= /p>

I issued the below 2= nd wglc on http://www.ietf.o= rg/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.txt

and I only got one review= with a comment which is easy to address.

 <= /p>

We really need more revie= ws in order to be able to progress the draft. If you care about the use cas= es and requirements related to White Space Database Access, please read the draft and send your comments to the list. If you do not ha= ve comments, then 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.=

 <= /p>

I cannot send the draft t= o the IESG without a minimum number of reviews. Ie, if we don’t get r= eviews, we can’t make progress.

 <= /p>

Thanks, Gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts

 

Since there were quite a = few changes made to the new version -04, let’s have another WGLC for = this document.

 <= /p>

Therefore, I'd like to in= itiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

 <= /p>

Please review the draft a= nd send your comments to the list by June 1st, 2012.

 <= /p>

If you review the draft a= nd have no comments, send a note to the list that the draft is good as it i= s, we need these notes as much as we need the actual comments.

 <= /p>

Thanks, Gabor<= /span>

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Probasco Scott (Noki= a-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: paws@ietf.org
Subject: [paws] UC&R document

 

Hello All,

 

A new version of the Use Cases & Requirements draft has b= een uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.<= o:p>

 

Kind Regards,

Raj & Scott

 

 

 

Abstract:

   Portions of the radio spectrum that are assigned= to a particular use

   but are unused or unoccupied at specific locatio= ns and times are

   defined as "white space".  T= he concept of allowing additional

   transmissions (which may or may not be licensed)= in white space is a

   technique to &quot;unlock&quot; existing= spectrum for new use.  An obvious

   requirement is that these additional transmissio= ns do not interfere

   with the assigned use of the spectrum. &nbs= p;One approach to using the

   white space spectrum at a given time and locatio= n is to verify with a

   database for available channels.

 

   This document describes the concept of TV White = Spaces.  It also

   describes the problems that need to be addressed= to enable white

   space spectrum for additional uses, without caus= ing interference to

   currently assigned use, by querying a database w= hich stores

   information about the channel availability at an= y given location and

   time.  A number of possible use cases = of white space spectrum and

   technology as well as a set of requirements for = the database query

   protocol are also described.

 

 

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374008AM1MPN1001mg_-- From andy.sago@bt.com Tue Jun 12 03:51:26 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6448621F864C for ; Tue, 12 Jun 2012 03:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.771 X-Spam-Level: X-Spam-Status: No, score=-2.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ox-3L7ddyzfy for ; Tue, 12 Jun 2012 03:51:23 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91E21F8649 for ; Tue, 12 Jun 2012 03:51:23 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.264.0; Tue, 12 Jun 2012 11:51:22 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.2.114]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Tue, 12 Jun 2012 11:51:21 +0100 From: To: , Date: Tue, 12 Jun 2012 11:51:20 +0100 Thread-Topic: 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQAPGKaDA= Message-ID: <619CDADDCCD2B44380834BE8BF6F714140A732CF0B@EMV62-UKRD.domain1.systemhost.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601ED6676@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140A732CF0BEMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 12 Jun 2012 10:51:26 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140A732CF0BEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gabor I will review the use cases and requirements document against the latest UK= Ofcom requirements and send comments to the list, possibly this week. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: 07 June 2012 16:40 To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don't get reviews, we can't make progress. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Bajko Gab= or (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let's hav= e another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Probasco = Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. --_000_619CDADDCCD2B44380834BE8BF6F714140A732CF0BEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gabor

 

I will review the use ca= ses and requirements document against the latest UK Ofcom requirements and = send comments to the list, possibly this week.

 

Regards

 

Andy

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of Gabor.Bajko@nokia.com
Sent: 07 June 2012= 16:40
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC f= or draft-ietf-paws-problem-stmt-usecases-rqmts

<= /div>

 

Folks,

 

I issued the below 2nd wglc on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt

and = I only got one review with a comment which is easy to address.

 <= /p>

We really need more reviews in = order to be able to progress the draft. If you care about the use cases and= requirements related to White Space Database Access, please read the draft= and send your comments to the list. If you do not have comments, then 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.

 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>I cannot send the draft to the IESG without a minimum nu= mber of reviews. Ie, if we don’t get reviews, we can’t make pro= gress.

 

Thanks, Ga= bor

&nbs= p;

From:<= /b> paws-bounces@ietf.org= [mailto:paws-bounces@iet= f.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
= Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-= ietf-paws-problem-stmt-usecases-rqmts

 

Since there were quite a few changes made to = the new version -04, let’s have another WGLC for this document.<= /o:p>

 <= /span>

Therefore, I'd like to i= nitiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase= s-rqmts-04.txt

 

= Please review the draft and send your comments to the list by June 1st, 201= 2.

 = ;

If you review th= e draft and have no comments, send a note to the list that the draft is goo= d as it is, we need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On= Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Friday, Ma= y 11, 2012 11:51 AM
To: paws@iet= f.org
Subject: [paws] UC&R document

=

 

Hello All,

 

A new version of the Use Cases & Requirements dra= ft has been uploaded. This version of the Internet Draft has addressed= all of the issues raised during Working Group Last Call, including discuss= ion from IETF #83, and is ready to be forwarded to IESG.<= /p>

 

Kind Regards,

<= p class=3DMsoNormal>Raj & Scott

 

 

 

Abstract:

<= p class=3DMsoNormal>   Portions of the radio spectrum that ar= e assigned to a particular use

   but are unused or unoccupied at specific location= s and times are

&n= bsp;  defined as "white space".  The concept of al= lowing additional

=    transmissions (which may or may not be licensed) in white spac= e is a

  = ; technique to &quot;unlock&quot; existing spectrum for new use.&nb= sp; An obvious

   requirement is that these additional transmissions do not in= terfere

 &nbs= p; with the assigned use of the spectrum.  One approach to using = the

   w= hite space spectrum at a given time and location is to verify with a

   database fo= r available channels.

=  

 =   This document describes the concept of TV White Spaces.  I= t also

  = ; describes the problems that need to be addressed to enable white

   space spectru= m for additional uses, without causing interference to

   currently assigned use, b= y querying a database which stores

   information about the channel availability at= any given location and

   time.  A number of possible use cases of white= space spectrum and

   technology as well as a set of requirements for the database= query

  = ; protocol are also described.

 

 

 

= --_000_619CDADDCCD2B44380834BE8BF6F714140A732CF0BEMV62UKRDdoma_-- From sdas@appcomsci.com Tue Jun 12 20:29:00 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC8A21F864B for ; Tue, 12 Jun 2012 20:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwC5lHZOF2yW for ; Tue, 12 Jun 2012 20:28:54 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1180221F8647 for ; Tue, 12 Jun 2012 20:28:53 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q5D3SkvH000091; Tue, 12 Jun 2012 23:28:46 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q5D3ShQG006840; Tue, 12 Jun 2012 23:28:44 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Tue, 12 Jun 2012 23:28:43 -0400 From: "Das, Subir" To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQARQB1TA= Date: Wed, 13 Jun 2012 03:28:39 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E47601ED6676@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: multipart/alternative; boundary="_000_AAC987F0CC2C7845A9FBD8A36D52E12D902DEDrrcatsexmb1_" MIME-Version: 1.0 Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 13 Jun 2012 03:29:00 -0000 --_000_AAC987F0CC2C7845A9FBD8A36D52E12D902DEDrrcatsexmb1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have reviewed the draft and it looks good. Below are some technical an= d editorial comments. Hope these are helpful. Regards, -Subir =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Technical: Section 1.2.1, In Scope: Page 6: "2. Connect to the database using a well-defined access method." SD> What is the meaning of 'well-defined access method' here? Then in the = following bullet point, it says 'using a well-defined protocol'. May be t= his is not necessary since the starting sentence of the section says "The = protocol will enable". "As a result, some of the scenarios described in the following section are = out of scope for this specification (although they might be addressed by f= uture specifications)." SD> It would be good if the 'out of scope' sections are explicitly identifi= ed. Section 2.2: Terminology: Page 6: Database In the context of white space and cognitive radio technologies, the databas= e is an entity which contains, but is not limited to, current information a= bout available spectrum at any given location SD> Suggest modifying the definition like this: In the context of white space and cognitive radio technologies, the databas= e is an entity which contains, but is not limited to, current information a= bout available spectrum at any given location and time as required by the= regulatory policies. Page 8: "White Space Device (WSD) A device which opportunistically uses some part of white space spectrum. A= white space device can be an access point, base station, a portable devic= e or similar. A white space device may be required by local regulations t= o query a database with its location to obtain information about available = spectrum." SD> Suggest adding definition of `Master Device` and ` Slave Device` as = two types of WSDS here and then delete them from Page 7 - Master Device WSD A device which is required to query the WS Database to find out the avail= able operating channels. - Slave Device WSD A device which uses the spectrum made available by a master device an= d cannot query the database directly. Section 4.1: Page 9 "A complete protocol solution must provide all services that are essential = to enable the white space paradigm. Before a white space device can begin = operating it needs to know what channels are available by sending a query t= o a white space database for a list of available channels, the white space = device must first locate or "discover" a suitable database." SD> Suggest changing the last sentence like this: "...., the white space de= vice must have the capability to first locate or discover a suitable datab= ase." Section 4.1.2: Page 11 SD> In Figure 2, Where is the 'Slave Device'? Also it may be better just= to mention 'Air IF' instead of 'TDD Air IF'. Page 15: Comment: In some use case it says 'Dev' and other use cases it says 'Slave = Dev'. Good to have the consistency. Section 4.2.3: Page 18 "1. The dual mode (or multi mode) device (3G + TVWS) is connected to a 3G n= etwork. The device has contacted a trusted database to discover the list o= f available TV channels at its current location. The device has located a = TVWS master/AP operating on an available channel and has associated or con= nected with the TVWS master/AP." SD> I got the impression from the above text that 'The device' refers to= the `Slave WS Dev' in Figure 5 and it has contacted the database. Am I= correct? If so, the text needs to be updated to clarify that the slave= cannot contact the database directly. Section 4.2.6: Page 22: "7. The slave/user device scans to locate a mobile master transmission, and= associates with the mobile master." SD> Where is the slave device coming from? There is no 'Slave device' in f= igure 8? Section 4.2.7, Page 23: SD> In Figure 9, there is a connection between Master devices using 'WS Air= IF' . Does this mean these devices have both 'Master' and 'Slave' capabili= ties? There is no such description and it is hard to understand why this c= onnection is necessary and its intended purpose. Section 4.2.8: Page 26: "7. The slave devices fitted to the machines scan the TV bands to locate th= e master transmissions, and associate with the master device." SD> The above step implies to me that all slave devices are connected to Ma= ster but the Figure 10 does not indicate that. Section 5: Page 28: SD> In Figure it says 'WS device' and it interfaces to the Database direct= ly . OTH, in all use cases the interface with the database is coming from = the 'Master Device'. It should be consistent. Suggest changing to 'Master = Device' or WSD Device (Master)'. Section 5.2 : Page 29: SD> This section seems to be a duplicate since Section 4.1.1 already covers= this. Section 5.4: Page 29: "Use of XML for specifying a data model is an attractive option. The inten= t is to evaluate the best option that meets the need for use between white = space devices and databases." SD> Suggest adding XML as an example Section 6.1: Page 30: "D.2: The Data Model MAY support specifying the regulatory domain and its= corresponding data requirements." SD> This requirement should be a 'MUST'; if not how will the databases in= terpret it? Also in P.2 it says "The protocol MUST support determination o= f regulatory domain governing its current location". Unless it is a must, = P.2 cannot be satisfied, IMO Page 31: "D.4: The Data Model MUST support specifying a manufacturer's serial numb= er for a master device" SD> Suggest deleting ` the master device' at the end. Since the serial n= umber is also applicable for slave device. Page 33: SD> Q.6 and Q.7 may be merged. Section 8: Page 38: "Threat 8: Natural disaster resulting in inability to obtain authorization= for white space spectrum use by emergency responders" Last sentence of this section says " The security requirements arising from= the above threats are captured in the requirements of section 6.1." SD> Not sure I understand the threat model here. Also it seems that the se= ction reference is not correct. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Editorial: Abstract 2nd paragraph : Page 1 "This document describes the concept of TV White Spaces." >From the above sentence I got the impression that the main focus of this dr= aft is to describe the concept of TV white Space which I believe is not. M= ay rephrase this or start with the second sentence like: This document desc= ribes the use cases and requirements of TV White Space and introduces the p= roblems that need ...." Section 3.2, Page 8: "More information about the switch to digital transmission is at : [DTV]." SD> Delete ':' Page 17: If the channel that a slave/user terminal is currently using is not longer = .. SD> Typo : 'not/no longer ...' Page 28: 4. Address regulatory requirements - Each country will likely have ... SD> typo: 'likely to have ...' Page 35: "Threat 1: .... A white space database may be operated by a commercial ent= ity which restricts access to authorized users. " SD> May add 'only' after 'access'; 'access to only authorized users. 'Threat 2: A master device discovers a white space database(s) thru which i= t can query for channel information.' SD> Typo: 'thru/through' From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Thursday, June 07, 2012 11:40 AM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don't get reviews, we can't make progress. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let's hav= e another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Probasco = Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. --_000_AAC987F0CC2C7845A9FBD8A36D52E12D902DEDrrcatsexmb1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have reviewed the draf= t and it looks good.   Below are some technical and editorial com= ments.  Hope these are helpful.

 <= /p>

Regards,

-Subir

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Technical:

 <= /p>

Section 1.2.1, In Scop= e:  Page 6: 

 <= /p>

“2.  Connect t= o the database using a well-defined access method.”=

 <= /p>

SD> What is the meanin= g of ‘well-defined access method’ here?  Then in the follo= wing bullet point,  it says  ‘using a well-defined protocol= ’. May be this is not necessary since the starting sentence of the section says  “= ;The protocol will enable”.  

 <= /p>

 <= /p>

“As a result, some = of the scenarios described in the following section are out of scope for th= is specification (although they might be  addressed by future specifications).”

 <= /p>

SD> It would be good i= f the ‘out of scope’ sections are explicitly identified.

 <= /p>

Section 2.2: Terminolo= gy: Page 6:

 <= /p>

Database

In the context of white s= pace and cognitive radio technologies, the database is an entity which cont= ains, but is not limited to, current information about available spectrum at any given location 

 <= /p>

SD>  Suggest = ; modifying the definition like this:

 <= /p>

In the context of white s= pace and cognitive radio technologies, the database is an entity which cont= ains, but is not limited to, current information about available spectrum at any given location  and time as  required by the reg= ulatory policies.

 <= /p>

 <= /p>

Page 8:

 <= /p>

“White Space Device= (WSD)

 <= /p>

A device which opportunis= tically uses some part of white space spectrum.  A white space device = can be an access point, base  station, a portable device or similar.&n= bsp; A white space device may  be required by local regulations to query a= database with its location to obtain information about available spectrum.= ”

 <= /p>

SD> Suggest  addi= ng definition  of `Master Device` and ` Slave Device`  as two typ= es of WSDS here and then delete  them from Page 7

 <= /p>

- =          Master Device WSD=

A device   whic= h is required to query the WS Database to find out the available operating = channels.

 <= /p>

- =          Slave Device WSD

    &= nbsp; A device which uses the spectrum made available by a master devi= ce and cannot query the  database  directly.

 <= /p>

 <= /p>

 <= /p>

Section 4.1: Page 9

 <= /p>

“A complete protoco= l solution must provide all services that are essential to enable the white= space paradigm.  Before a white space device can begin operating it needs to know what channels are available by sending a query to a white= space database for a list of available channels, the white space device mu= st first locate or  "discover" a suitable database.”

 <= /p>

SD> Suggest changing t= he last sentence like this: “…., the white space device must ha= ve the capability to first locate or discover  a suitable database.= 221;

 <= /p>

 <= /p>

Section 4.1.2: Page 11

 <= /p>

SD> In Figure 2, =   Where is the ‘Slave Device’?  Also it may be better= just to mention ‘Air IF’  instead of ‘TDD Air IF= 217;. 

 <= /p>

 <= /p>

Page 15:

 <= /p>

Comment: In some use case= it says ‘Dev’ and other use cases it says ‘Slave DevR= 17;. Good to have the consistency.

 <= /p>

 <= /p>

Section 4.2.3: Page 18=

 <= /p>

“1. The dual mode (= or multi mode) device (3G + TVWS) is connected to a 3G network.  T= he device has contacted a trusted database to discover the list of availabl= e TV channels at its current location.  The device has located a TVWS m= aster/AP operating on  an available channel and has associated or conn= ected with the TVWS master/AP.”

 <= /p>

SD>  I got the im= pression from the above text   that ‘The device’ refe= rs to the `Slave  WS Dev’  in Figure 5 and it has contacted=   the database.  Am I correct?   If so,  the text  needs to be updated to clarify that the slave = cannot contact the database directly.

 <= /p>

 <= /p>

Section 4.2.6:  P= age 22:

 <= /p>

“7. The slave/user = device scans to locate a mobile master transmission, and associates with th= e mobile master.”

 <= /p>

SD> Where is the slave= device coming from? There is no ‘Slave device’ in  figure= 8?

 <= /p>

 <= /p>

Section  4.2.7, P= age 23:

 

SD> In Figure 9, there= is a connection between Master devices using ‘WS Air IF’ . Doe= s this mean these devices have both ‘Master’ and ‘Slave&#= 8217; capabilities?  There is no such description and it is hard to understand why this connect= ion is necessary and its intended purpose.

 <= /p>

Section 4.2.8: Page 26= :

 <= /p>

“7. The slave devic= es fitted to the machines scan the TV bands to locate the master transmissi= ons, and associate with the master device.”

 <= /p>

SD> The above step imp= lies to me that all slave devices are connected to Master but the Figure 10= does not indicate that.

 <= /p>

Section 5: Page 28:

 <= /p>

SD>  In Figure it= says ‘WS device’ and it interfaces to the Database directly . = OTH, in all use cases the  interface with the database is coming from = the ‘Master Device’.  It should be consistent. Suggest changing to ‘M= aster Device’ or WSD Device (Master)’.

 <= /p>

Section 5.2 : Page 29:=

 <= /p>

SD> This section seems= to be a duplicate since Section 4.1.1 already covers this.

 <= /p>

Section 5.4: Page 29:<= o:p>

 <= /p>

“Use of XML for spe= cifying a data model is an attractive option.  The intent is to evalua= te the best option that meets the need for use between white space devices and databases.”

 <= /p>

SD> Suggest adding&nbs= p; XML  as an example

 <= /p>

Section 6.1: Page 30:<= o:p>

 <= /p>

“D.2: The Data Mode= l  MAY  support specifying the regulatory domain and its correspo= nding data requirements.”

 <= /p>

SD> This requirement&n= bsp;  should be a ‘MUST’; if not how will the databases in= terpret it?  Also in P.2 it says “The protocol MUST support dete= rmination of regulatory domain governing its current location”.  Unless it is a must, P= .2 cannot be satisfied, IMO

 <= /p>

Page 31:

 <= /p>

“D.4:   T= he Data Model MUST support specifying a manufacturer's serial number for a = master device”

 <= /p>

SD>  Suggest dele= ting ` the master device’ at the end.   Since the serial nu= mber is also applicable for slave device.

 <= /p>

 <= /p>

Page 33:

 

SD> Q.6 and Q.7 may&nb= sp; be merged.

 <= /p>

 <= /p>

Section 8: Page 38:

 <= /p>

“Threat 8:  Na= tural disaster resulting in inability to obtain authorization for white spa= ce spectrum use by emergency responders”

 <= /p>

Last sentence of this sec= tion says “ The security requirements arising from the above threats = are captured  in the requirements of section 6.1.”

 <= /p>

SD> Not sure I underst= and the threat model  here. Also it seems that the section reference i= s not correct.

 <= /p>

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 <= /p>

Editorial:<= /span>

 <= /p>

Abstract 2nd paragraph= : Page 1

“This document desc= ribes the concept of TV White Spaces.”   =

 <= /p>

From the above sentence I= got the impression that the main focus of this draft is to describe the co= ncept of TV white Space which I believe is not.  May rephrase this or start with the second sentence like: This document describes the u= se cases and requirements of TV White Space and introduces the problems tha= t need ….”

 <= /p>

Section 3.2, Page 8:

 <= /p>

“More information a= bout the switch to digital transmission is at : [DTV].”

 <= /p>

SD> Delete ‘:= 217;

 <= /p>

Page 17:

 <= /p>

If the channel that a sla= ve/user terminal is currently using is not longer ..

 <= /p>

SD> Typo :  ̵= 6;not/no  longer …’

 <= /p>

Page 28:

 <= /p>

4.  Address regulato= ry requirements - Each country will likely have …

 <= /p>

SD> typo:  ‘= ;likely to have …’

 <= /p>

Page 35:

 <= /p>

“Threat 1:  &#= 8230;. A white space database may be operated by a commercial entity which = restricts

access to authorized user= s. “

 <= /p>

SD> May add ‘onl= y’  after ‘access’;  ‘access to only auth= orized users.

 <= /p>

‘Threat 2: A master= device discovers a white space database(s) thru which it can query for cha= nnel information.’

 <= /p>

SD> Typo: ‘thru/= through’

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, June 07, 2012 11:40 AM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

Folks,<= /p>

 <= /p>

I issued the below 2= nd wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

and I only got one review= with a comment which is easy to address.

 <= /p>

We really need more revie= ws in order to be able to progress the draft. If you care about the use cas= es and requirements related to White Space Database Access, please read the draft and send your comments to the list. If you do not ha= ve comments, then 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.

 <= /p>

I cannot send the draft t= o the IESG without a minimum number of reviews. Ie, if we don’t get r= eviews, we can’t make progress.

 <= /p>

Thanks, Gabor<= /span>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts

 

Since there were quite a = few changes made to the new version -04, let’s have another WGLC for = this document.

 <= /p>

Therefore, I'd like to in= itiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

 <= /p>

Please review the draft a= nd send your comments to the list by June 1st, 2012.

 <= /p>

If you review the draft a= nd have no comments, send a note to the list that the draft is good as it i= s, we need these notes as much as we need the actual comments.

 <= /p>

Thanks, Gabor<= /span>

 <= /p>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Probasco Scott (Noki= a-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: paws@ietf.org
Subject: [paws] UC&R document

 

Hello All,

 

A new version of the Use Cases & Requirements draft has b= een uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.<= o:p>

 

Kind Regards,

Raj & Scott

 

 

 

Abstract:

   Portions of the radio spectrum that are assigned= to a particular use

   but are unused or unoccupied at specific locatio= ns and times are

   defined as "white space".  T= he concept of allowing additional

   transmissions (which may or may not be licensed)= in white space is a

   technique to &quot;unlock&quot; existing= spectrum for new use.  An obvious

   requirement is that these additional transmissio= ns do not interfere

   with the assigned use of the spectrum. &nbs= p;One approach to using the

   white space spectrum at a given time and locatio= n is to verify with a

   database for available channels.

 

   This document describes the concept of TV White = Spaces.  It also

   describes the problems that need to be addressed= to enable white

   space spectrum for additional uses, without caus= ing interference to

   currently assigned use, by querying a database w= hich stores

   information about the channel availability at an= y given location and

   time.  A number of possible use cases = of white space spectrum and

   technology as well as a set of requirements for = the database query

   protocol are also described.

 

 

 

--_000_AAC987F0CC2C7845A9FBD8A36D52E12D902DEDrrcatsexmb1_-- From JuanCarlos.Zuniga@InterDigital.com Thu Jun 14 14:17:26 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943DE11E8072 for ; Thu, 14 Jun 2012 14:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YjJQ4m05l75 for ; Thu, 14 Jun 2012 14:17:23 -0700 (PDT) Received: from idcout.InterDigital.com (smtp-out1.interdigital.com [64.208.228.135]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3E21F85C4 for ; Thu, 14 Jun 2012 14:17:22 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.11]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Jun 2012 17:17:22 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD4A73.1641FDBE" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 14 Jun 2012 17:17:19 -0400 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQAWsY/PA= References: <1ECAFF543A2FED4EA2BEB6CACE08E47601ED6676@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601F2B374@008-AM1MPN1-001.mgdnok.nokia.com> From: "Zuniga, Juan Carlos" To: , X-OriginalArrivalTime: 14 Jun 2012 21:17:22.0119 (UTC) FILETIME=[16678570:01CD4A73] Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 14 Jun 2012 21:17:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD4A73.1641FDBE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gabor, all, =20 I have reviewed the document and I think it is in very good shape. These are some minor comments I have: =20 =20 Abstract =20 Even though TV bands are currently the primary applications for PAWS, the protocol could be applicable to other bands. Hence, I would suggest removing "TV" from the second paragraph of the Abstract. =20 Section 1.1 =20 Multiple examples are provided throughout this section. Some are inside parenthesis, some are preceded by "e.g." and some are not. I would suggest keeping a common writing style when providing these examples. =20 Replace "...such as antenna height, and sometimes power." by "...such as antenna height and power." =20 Section 1.2.1 =20 Replace "...basic service in TV white space." by "...basic service in white spaces." (or alternatively "...basic service in white space frequencies.") =20 Section 6.1 =20 P.5 and P.6 could be combined into one single requirement with some wording similar to the one used in P.7, e.g. "The messages sent by the master device and database MUST support integrity protection." =20 Section 6.2 =20 I believe there is a preposition missing in O.5: "The master device MUST obtain an indication 'about' the regulatory domain governing operation..." =20 =20 =20 Regards, =20 Juan Carlos =20 =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, June 07, 2012 11:40 AM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts =20 Folks, =20 I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase s-rqmts-04.txt and I only got one review with a comment which is easy to address. =20 We really need more reviews in order to be able to progress the draft. If you care about the use cases and requirements related to White Space Database Access, please read the draft and send your comments to the list. If you do not have comments, then 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. =20 I cannot send the draft to the IESG without a minimum number of reviews. Ie, if we don't get reviews, we can't make progress. =20 Thanks, Gabor =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts =20 Since there were quite a few changes made to the new version -04, let's have another WGLC for this document. =20 Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecase s-rqmts-04.txt =20 Please review the draft and send your comments to the list by June 1st, 2012. =20 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. =20 Thanks, Gabor =20 =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Probasco Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document =20 Hello All, =20 A new version of the Use Cases & Requirements draft has been uploaded. This version of the Internet Draft has addressed all of the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG. =20 Kind Regards, Raj & Scott =20 Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-04.tx t =20 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecase= s -rqmts-04 =20 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. =20 This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. =20 =20 =20 ------_=_NextPart_001_01CD4A73.1641FDBE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gabor, all,

 

I have reviewed the document and I think it is in very good shape. = These are some minor comments I have:

 

 

Abstract

 

Even though TV bands are currently the primary applications for PAWS, = the protocol could be applicable to other bands. Hence, I would suggest = removing “TV” from the second paragraph of the = Abstract.

 

Section 1.1

 

Multiple examples are provided throughout this section. Some are = inside parenthesis, some are preceded by “e.g.” and some are = not. I would suggest keeping a common writing style when providing these = examples.

 

Replace “…such as antenna height, and sometimes = power.” by “…such as antenna height and = power.”

 

Section 1.2.1

 

Replace “…basic service in TV white space.” by =  “…basic service in white spaces.” (or = alternatively “…basic service in white space = frequencies.”)

 

Section 6.1

 

P.5 and P.6 could be combined into one single requirement with some = wording similar to the one used in P.7, e.g. “The messages sent by = the master device and database MUST support integrity = protection.”

 

Section 6.2

 

I believe there is a preposition missing in O.5: “The master = device MUST obtain an indication ‘about’ the regulatory = domain governing operation…”

 

 

 

Regards,

 

Juan Carlos

 

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Gabor.Bajko@nokia.com
Sent: Thursday, June 07, 2012 11:40 = AM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC = for = draft-ietf-paws-problem-stmt-usecases-rqmts

 

Folks,

 

I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-04.txt

and I only got one review with a comment which is easy to = address.

 

We really need more reviews in order to be able to progress the = draft. If you care about the use cases and requirements related to White = Space Database Access, please read the draft and send your comments to = the list. If you do not have comments, then 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.

 

I cannot send the draft to the IESG without a minimum number of = reviews. Ie, if we don’t get reviews, we can’t make = progress.

 

Thanks, Gabor

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May = 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] = 2nd WGLC for = draft-ietf-paws-problem-stmt-usecases-rqmts

 

Since there were quite a few changes made to the new version -04, = let’s have another WGLC for this document.

 

Therefore, I'd like to initiate a 2nd WG Last Call for = comments on http://www.ietf.org/internet-drafts/draft-ietf-paw= s-problem-stmt-usecases-rqmts-04.txt

 

Please review the draft and send your comments to the list by June = 1st, 2012.

 

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

 

 

From:= = paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of Probasco Scott = (Nokia-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 = AM
To: paws@ietf.org
Subject: = [paws] UC&R document

 

Hello = All,

 

A new = version of the Use Cases & Requirements draft has been = uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion = from IETF #83, and is ready to be forwarded to = IESG.

 

Kind = Regards,

Raj & = Scott

 

 

 

Abstract:

   = Portions of the radio spectrum that are assigned to a particular = use

   = but are unused or unoccupied at specific locations and times = are

   = defined as "white space".  The concept of allowing = additional

   = transmissions (which may or may not be licensed) in white space is = a

   = technique to &quot;unlock&quot; existing spectrum for new = use.  An obvious

   = requirement is that these additional transmissions do not = interfere

   = with the assigned use of the spectrum.  One approach to using = the

   = white space spectrum at a given time and location is to verify with = a

   = database for available channels.

 

   = This document describes the concept of TV White Spaces.  It = also

   = describes the problems that need to be addressed to enable = white

   = space spectrum for additional uses, without causing interference = to

   = currently assigned use, by querying a database which = stores

   = information about the channel availability at any given location = and

   = time.  A number of possible use cases of white space spectrum = and

   = technology as well as a set of requirements for the database = query

   = protocol are also described.

 

 

 

------_=_NextPart_001_01CD4A73.1641FDBE-- From scott.probasco@nokia.com Wed Jun 20 13:56:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7ED11E8093 for ; Wed, 20 Jun 2012 13:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpMvWqIkn6Tr for ; Wed, 20 Jun 2012 13:55:59 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 602CA11E8096 for ; Wed, 20 Jun 2012 13:55:58 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5KKtphL014006 for ; Wed, 20 Jun 2012 23:55:57 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 23:55:55 +0300 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.69]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Wed, 20 Jun 2012 22:55:54 +0200 From: To: Thread-Topic: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQARQB1TABdmlsAA== Date: Wed, 20 Jun 2012 20:55:53 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [172.19.40.42] Content-Type: multipart/alternative; boundary="_000_CC076557D4B3scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2012 20:55:55.0821 (UTC) FILETIME=[163085D0:01CD4F27] X-Nokia-AV: Clean Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 20 Jun 2012 20:56:01 -0000 --_000_CC076557D4B3scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Subir, Thank you for reviewing the draft and providing comments. I have addressed = each of your comments, please see below (MSP->) for further information. Kind Regards, Scott From: "ext Das, Subir" > Date: Wed, 13 Jun 2012 03:28:39 +0000 To: Gabor Bajko >, "paw= s@ietf.org" > Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s We have reviewed the draft and it looks good. Below are some technical an= d editorial comments. Hope these are helpful. Regards, -Subir =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Technical: Section 1.2.1, In Scope: Page 6: =932. Connect to the database using a well-defined access method.=94 SD> What is the meaning of =91well-defined access method=92 here? Then in = the following bullet point, it says =91using a well-defined protocol=92. = May be this is not necessary since the starting sentence of the section say= s =93The protocol will enable=94. MSP->These terms refer to the completed PAWS protocol. =93As a result, some of the scenarios described in the following section ar= e out of scope for this specification (although they might be addressed by= future specifications).=94 SD> It would be good if the =91out of scope=92 sections are explicitly iden= tified. MSP->I have removed the sentence citing 'out of scope'. Section 2.2: Terminology: Page 6: Database In the context of white space and cognitive radio technologies, the databas= e is an entity which contains, but is not limited to, current information a= bout available spectrum at any given location SD> Suggest modifying the definition like this: In the context of white space and cognitive radio technologies, the databas= e is an entity which contains, but is not limited to, current information a= bout available spectrum at any given location and time as required by the= regulatory policies. MSP->I have modified the definition based on your proposal. Page 8: =93White Space Device (WSD) A device which opportunistically uses some part of white space spectrum. A= white space device can be an access point, base station, a portable devic= e or similar. A white space device may be required by local regulations t= o query a database with its location to obtain information about available = spectrum.=94 SD> Suggest adding definition of `Master Device` and ` Slave Device` as = two types of WSDS here and then delete them from Page 7 - Master Device WSD A device which is required to query the WS Database to find out the avail= able operating channels. - Slave Device WSD A device which uses the spectrum made available by a master device an= d cannot query the database directly. MSP-> I have updated the definition of Slave Device based on your text abov= e. I have left the definitions as stand-alone definitions rather than placi= ng them under "White Space Device (WSD)" as the definitions are listed alph= abetically. Section 4.1: Page 9 =93A complete protocol solution must provide all services that are essentia= l to enable the white space paradigm. Before a white space device can begi= n operating it needs to know what channels are available by sending a query= to a white space database for a list of available channels, the white spac= e device must first locate or "discover" a suitable database.=94 SD> Suggest changing the last sentence like this: =93=85., the white space = device must have the capability to first locate or discover a suitable dat= abase.=94 MSP->I have implemented your proposal. Section 4.1.2: Page 11 SD> In Figure 2, Where is the =91Slave Device=92? Also it may be better = just to mention =91Air IF=92 instead of =91TDD Air IF=92. MSP->There is no slave device since only the Master Device registers with t= he database. I have removed "TDD" from the figure. Page 15: Comment: In some use case it says =91Dev=92 and other use cases it says =91= Slave Dev=92. Good to have the consistency. MSP->I have made changes in 4.2.1 step 6 & 9. Section 4.2.3: Page 18 =931. The dual mode (or multi mode) device (3G + TVWS) is connected to a 3G= network. The device has contacted a trusted database to discover the list= of available TV channels at its current location. The device has located = a TVWS master/AP operating on an available channel and has associated or c= onnected with the TVWS master/AP.=94 SD> I got the impression from the above text that =91The device=92 refer= s to the `Slave WS Dev=92 in Figure 5 and it has contacted the database.= Am I correct? If so, the text needs to be updated to clarify that the= slave cannot contact the database directly. MSP->I have removed the text describing the slave device contacting the dat= abase. Section 4.2.6: Page 22: =937. The slave/user device scans to locate a mobile master transmission, a= nd associates with the mobile master.=94 SD> Where is the slave device coming from? There is no =91Slave device=92 i= n figure 8? MSP->I have added a slave device to Figure 8 and clarified in step 6 that m= aster-master communications are possible outside the scope of PAWS. Section 4.2.7, Page 23: SD> In Figure 9, there is a connection between Master devices using =91WS A= ir IF=92 . Does this mean these devices have both =91Master=92 and =91Slave= =92 capabilities? There is no such description and it is hard to understan= d why this connection is necessary and its intended purpose. MSP->This capability is described in the first paragraph under 4.2.7. I hav= e clarified in step 6 that master-master communications are possible outsid= e the scope of PAWS. Section 4.2.8: Page 26: =937. The slave devices fitted to the machines scan the TV bands to locate = the master transmissions, and associate with the master device.=94 SD> The above step implies to me that all slave devices are connected to Ma= ster but the Figure 10 does not indicate that. MSP->The first paragraph in 4.2.8 does specify that each slave device is un= der control of a master device. Section 5: Page 28: SD> In Figure it says =91WS device=92 and it interfaces to the Database di= rectly . OTH, in all use cases the interface with the database is coming f= rom the =91Master Device=92. It should be consistent. Suggest changing to = =91Master Device=92 or WSD Device (Master)=92. MSP->I have updated Figure 11 to "Master" WS Device. Section 5.2 : Page 29: SD> This section seems to be a duplicate since Section 4.1.1 already covers= this. MSP->This section is relevant to the Problem Statement (Chapter 5) and shou= ld be kept. Section 5.4: Page 29: =93Use of XML for specifying a data model is an attractive option. The int= ent is to evaluate the best option that meets the need for use between whit= e space devices and databases.=94 SD> Suggest adding XML as an example MSP->Examples are nice, however as we are concluding the 2nd WGLC I propose= to leave this as written. Section 6.1: Page 30: =93D.2: The Data Model MAY support specifying the regulatory domain and i= ts corresponding data requirements.=94 SD> This requirement should be a =91MUST=92; if not how will the database= s interpret it? Also in P.2 it says =93The protocol MUST support determina= tion of regulatory domain governing its current location=94. Unless it is = a must, P.2 cannot be satisfied, IMO MSP->Changed D.2 to MUST. Page 31: =93D.4: The Data Model MUST support specifying a manufacturer's serial nu= mber for a master device=94 SD> Suggest deleting ` the master device=92 at the end. Since the serial= number is also applicable for slave device. MSP->Changed 'master' to 'white space' Page 33: SD> Q.6 and Q.7 may be merged. MSP->Merged O.6 and O.7 Section 8: Page 38: =93Threat 8: Natural disaster resulting in inability to obtain authorizati= on for white space spectrum use by emergency responders=94 Last sentence of this section says =93 The security requirements arising fr= om the above threats are captured in the requirements of section 6.1.=94 SD> Not sure I understand the threat model here. Also it seems that the se= ction reference is not correct. MSP->Section 6.1 is Normative Requirements, and contain the requirements ag= reed as result of the threat model. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Editorial: MSP->I have included the editorial corrections. Abstract 2nd paragraph : Page 1 =93This document describes the concept of TV White Spaces.=94 >From the above sentence I got the impression that the main focus of this dr= aft is to describe the concept of TV white Space which I believe is not. M= ay rephrase this or start with the second sentence like: This document desc= ribes the use cases and requirements of TV White Space and introduces the p= roblems that need =85.=94 Section 3.2, Page 8: =93More information about the switch to digital transmission is at : [DTV].= =94 SD> Delete =91:=92 Page 17: If the channel that a slave/user terminal is currently using is not longer = .. SD> Typo : =91not/no longer =85=92 Page 28: 4. Address regulatory requirements - Each country will likely have =85 SD> typo: =91likely to have =85=92 Page 35: =93Threat 1: =85. A white space database may be operated by a commercial e= ntity which restricts access to authorized users. =93 SD> May add =91only=92 after =91access=92; =91access to only authorized u= sers. =91Threat 2: A master device discovers a white space database(s) thru which= it can query for channel information.=92 SD> Typo: =91thru/through=92 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, June 07, 2012 11:40 AM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don=92t get reviews, we can=92t make progress. Thanks, Gabor From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let=92s h= ave another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Probasco S= cott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CC076557D4B3scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <13B2930BC965AF4CA4A4FA9229879E84@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hello Subir,

Thank you for reviewing the draft and providing comments. I have addre= ssed each of your comments, please see below (MSP->) for further informa= tion.

Kind Regards,
Scott


From: "ext Das, Subir" &l= t;sdas@appcomsci.com>
Date: Wed, 13 Jun 2012 03:28:39 = 3;0000
To: Gabor Bajko <Gabor.Bajko@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] 2nd WGLC for dr= aft-ietf-paws-problem-stmt-usecases-rqmts

We have reviewed the draft and it = looks good.   Below are some technical and editorial comments. &n= bsp;Hope these are helpful.

 

Regards,

-Subir

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Technical:

 

Section 1.2.1, In Scope:  = Page 6: 

 

=932.  Connect to the databas= e using a well-defined access method.=94

 

SD> What is the meaning of =91w= ell-defined access method=92 here?  Then in the following bullet point= ,  it says  =91using a well-defined protocol=92. May be this is not necessary since the starting sentence of the section says &= nbsp;=93The protocol will enable=94.  
MSP->These terms refer to the completed PAWS protocol.

 

 

=93As a result, some of the scenar= ios described in the following section are out of scope for this specificat= ion (although they might be  addressed by future specifications).=94

 

SD> It would be good if the =91= out of scope=92 sections are explicitly identified.
MSP->I have removed the sentence citing 'out of scope'.

 

Section 2.2: Terminology: Page = 6:

 

Database

In the context of white space and = cognitive radio technologies, the database is an entity which contains, but= is not limited to, current information about available spectrum at any given location 

 

SD>  Suggest  modifyi= ng the definition like this:

 

In the context of white space and = cognitive radio technologies, the database is an entity which contains, but= is not limited to, current information about available spectrum at any given location  and time as  req= uired by the regulatory policies.
MSP->I have modified the definition based on your proposal.

 

Page 8:

 

=93White Space Device (WSD)

 

A device which opportunistically u= ses some part of white space spectrum.  A white space device can be an= access point, base  station, a portable device or similar.  A white space device may  be required by loc= al regulations to query a database with its location to obtain information = about available spectrum.=94

 

SD> Suggest  adding defini= tion  of `Master Device` and ` Slave Device`  as two types of WSD= S here and then delete  them from Page 7

 

-    &nb= sp;     Master Device WSD<= /p>

A device   which is requ= ired to query the WS Database to find out the available operating channels.=

 

-    &nb= sp;     Slave Device WSD

     &nbs= p;A device which uses the spectrum made available by a master device and ca= nnot query the  database  directly.
MSP-> I have updated the definition of Slave Device based on your t= ext above. I have left the definitions as stand-alone definitions rather th= an placing them under "White Space Device (WSD)" as the definitio= ns are listed alphabetically.

 <= /span>

 

Section 4.1: Page 9<= /span>

 

=93A complete protocol solution mu= st provide all services that are essential to enable the white space paradi= gm.  Before a white space device can begin operating it needs to know what channels are available by sending a query = to a white space database for a list of available channels, the white space= device must first locate or  "discover" a suitable database= .=94

 

SD> Suggest changing the last s= entence like this: =93=85., the white space device must have the capability= to first locate or discover  a suitable database.=94
MSP->I have implemented your proposal. 

 

 

Section 4.1.2: Page 11<= /span>

 

SD> In Figure 2,   Wh= ere is the =91Slave Device=92?  Also it may be better just to mention = =91Air IF=92  instead of =91TDD Air IF=92. 
MSP->There is no slave device since only the Master Device register= s with the database. I have removed "TDD" from the figure.

 

 

Page 15:

 

Comment: In some use case it says = =91Dev=92 and other use cases it says =91Slave Dev=92. Good to have the con= sistency.
MSP->I have made changes in 4.2.1 step 6 & 9.

 

 

Section 4.2.3: Page 18

 

=931. The dual mode (or multi mode= ) device (3G + TVWS) is connected to a 3G network.  The device has= contacted a trusted database to discover the list of available TV channels at its current location.  The device has loc= ated a TVWS master/AP operating on  an available channel and has assoc= iated or connected with the TVWS master/AP.=94

 

SD>  I got the impression = from the above text   that =91The device=92 refers to the `Slave&= nbsp; WS Dev=92  in Figure 5 and it has contacted  the database.&= nbsp; Am I correct?   If so,  the text  needs to be updated = to clarify that the slave cannot contact the database directly.
MSP->I have removed the text describing the slave device contacting= the database.

 

 

Section 4.2.6:  Page 22:

 

=937. The slave/user device scans = to locate a mobile master transmission, and associates with the mobile mast= er.=94

 

SD> Where is the slave device c= oming from? There is no =91Slave device=92 in  figure 8?
MSP->I have added a slave device to Figure 8 and clarified in step = 6 that master-master communications are possible outside the scope of PAWS.=

 

 

Section  4.2.7, Page 23:

 

SD> In Figure 9, there is a con= nection between Master devices using =91WS Air IF=92 . Does this mean these= devices have both =91Master=92 and =91Slave=92 capabilities?  There is no such description and it is hard to understand why this connect= ion is necessary and its intended purpose.
MSP->This capability is described in the first paragraph under 4.2.= 7. I have clarified in step 6 that master-master communications are possibl= e outside the scope of PAWS.

 

Section 4.2.8: Page 26:

 

=937. The slave devices fitted to = the machines scan the TV bands to locate the master transmissions, and asso= ciate with the master device.=94

 

SD> The above step implies to m= e that all slave devices are connected to Master but the Figure 10 does not= indicate that.
MSP->The first paragraph in 4.2.8 does specify that each slave devi= ce is under control of a master device.

 

Section 5: Page 28:<= /span>

 

SD>  In Figure it says =91= WS device=92 and it interfaces to the Database directly . OTH, in all use c= ases the  interface with the database is coming from the =91Master Device=92.  It should be consistent. Suggest chang= ing to =91Master Device=92 or WSD Device (Master)=92.
MSP->I have updated Figure 11 to "Master" WS Device.

 

Section 5.2 : Page 29:

 

SD> This section seems to be a = duplicate since Section 4.1.1 already covers this.
MSP->This section is relevant to the Problem Statement (Chapter 5) = and should be kept.

 

Section 5.4: Page 29:

 

=93Use of XML for specifying a dat= a model is an attractive option.  The intent is to evaluate the best o= ption that meets the need for use between white space devices and databases.=94

 

SD> Suggest adding  XML&nb= sp; as an example
MSP->Examples are nice, however as we are concluding the 2nd WGLC I= propose to leave this as written.

 

Section 6.1: Page 30:

 

=93D.2: The Data Model  MAY&n= bsp; support specifying the regulatory domain and its corresponding data re= quirements.=94

 

SD> This requirement  = ; should be a =91MUST=92; if not how will the databases interpret it? = Also in P.2 it says =93The protocol MUST support determination of regulatory domain governing its current location=94.  Unless it is= a must, P.2 cannot be satisfied, IMO
MSP->Changed D.2 to MUST.

 

Page 31:<= /p>

 

=93D.4:   The Data Model= MUST support specifying a manufacturer's serial number for a master device= =94

 

SD>  Suggest deleting ` th= e master device=92 at the end.   Since the serial number is also = applicable for slave device.
MSP->Changed 'master' to 'white space'

 

 

Page 33:<= /p>

 

SD> Q.6 and Q.7 may  be me= rged.
MSP->Merged O.6 and O.7

 

 

Section 8: Page 38:<= /span>

 

=93Threat 8:  Natural disaste= r resulting in inability to obtain authorization for white space spectrum u= se by emergency responders=94

 

Last sentence of this section says= =93 The security requirements arising from the above threats are captured&= nbsp; in the requirements of section 6.1.=94

 

SD> Not sure I understand the t= hreat model  here. Also it seems that the section reference is not cor= rect.
MSP->Section 6.1 is Normative Requirements, and contain the require= ments agreed as result of the threat model.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Editorial:
MSP->I have included the editorial corrections.

 

Abstract 2nd paragraph : Page 1=

=93This document describes the con= cept of TV White Spaces.=94   

 

From the above sentence I got the = impression that the main focus of this draft is to describe the concept of = TV white Space which I believe is not.  May rephrase this or start with the second sentence like: This document de= scribes the use cases and requirements of TV White Space and introduces the= problems that need =85.=94

 

Section 3.2, Page 8:=

 

=93More information about the swit= ch to digital transmission is at : [DTV].=94

 

SD> Delete =91:=92

 

Page 17:

 

If the channel that a slave/user t= erminal is currently using is not longer ..

 

SD> Typo :  =91not/no = ; longer =85=92

 

Page 28:<= /p>

 

4.  Address regulatory requir= ements - Each country will likely have =85

 

SD> typo:  =91likely to ha= ve =85=92

 

Page 35:

 

=93Threat 1:  =85. A white sp= ace database may be operated by a commercial entity which restricts

access to authorized users. =93

 

SD> May add =91only=92  af= ter =91access=92;  =91access to only authorized users.

 

=91Threat 2: A master device disco= vers a white space database(s) thru which it can query for channel informat= ion.=92

 

SD> Typo: =91thru/through=92

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@no= kia.com
Sent: Thursday, June 07, 2012 11:40 AM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

Folks,

 

I issued the below 2nd = wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

and I only got one review with a c= omment which is easy to address.

 

We really need more reviews in ord= er to be able to progress the draft. If you care about the use cases and re= quirements related to White Space Database Access, please read the draft and send your comments to the list. If you d= o not have comments, then 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.

 

I cannot send the draft to the IES= G without a minimum number of reviews. Ie, if we don=92t get reviews, we ca= n=92t make progress.

 

Thanks, Gabor

 

From:paws-bou= nces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts

 

Since there were quite a few chang= es made to the new version -04, let=92s have another WGLC for this document= .

 

Therefore, I'd like to initiate a = 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

 

Please review the draft and send y= our comments to the list by June 1st, 2012.

 

If you review the draft and have n= o comments, send a note to the list that the draft is good as it is, we nee= d these notes as much as we need the actual comments.

 

Thanks, Gabor

 

 

From:paws-bou= nces@ietf.org [mailto:paws-bounces@ietf= .org] On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: paws@ietf.org
Subject: [paws] UC&R document

 

Hello All,

 

A new version of the Use Cases & Requirements draft has b= een uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.<= o:p>

 

Kind Regards,

Raj & Scott

 

 

 

Abstract:

   Portions of the radio spectrum that are assigned= to a particular use

   but are unused or unoccupied at specific locatio= ns and times are

   defined as "white space".  T= he concept of allowing additional

   transmissions (which may or may not be licensed)= in white space is a

   technique to &quot;unlock&quot; existing= spectrum for new use.  An obvious

   requirement is that these additional transmissio= ns do not interfere

   with the assigned use of the spectrum. &nbs= p;One approach to using the

   white space spectrum at a given time and locatio= n is to verify with a

   database for available channels.

 

   This document describes the concept of TV White = Spaces.  It also

   describes the problems that need to be addressed= to enable white

   space spectrum for additional uses, without caus= ing interference to

   currently assigned use, by querying a database w= hich stores

   information about the channel availability at an= y given location and

   time.  A number of possible use cases = of white space spectrum and

   technology as well as a set of requirements for = the database query

   protocol are also described.

 

 

 

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CC076557D4B3scottprobasconokiacom_-- From scott.probasco@nokia.com Wed Jun 20 13:58:52 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DB221F85BB for ; Wed, 20 Jun 2012 13:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX8pKXcAyvUL for ; Wed, 20 Jun 2012 13:58:50 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C537221F855E for ; Wed, 20 Jun 2012 13:58:45 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5KKwfl7016332 for ; Wed, 20 Jun 2012 23:58:44 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jun 2012 23:58:42 +0300 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.69]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0283.004; Wed, 20 Jun 2012 22:58:40 +0200 From: To: Thread-Topic: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQAWsY/PABH2sBAA== Date: Wed, 20 Jun 2012 20:58:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [172.19.40.42] Content-Type: multipart/alternative; boundary="_000_CC0793ACD51Fscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2012 20:58:42.0513 (UTC) FILETIME=[798BB410:01CD4F27] X-Nokia-AV: Clean Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 20 Jun 2012 20:58:52 -0000 --_000_CC0793ACD51Fscottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Juan Carlos, Thank you for reviewing the draft and providing comments. I have addressed = each of your comments, please see below (MSP->) for further information. Kind Regards, Scott From: Juan Zuniga > Date: Thu, 14 Jun 2012 17:17:19 -0400 To: Gabor Bajko >, "paw= s@ietf.org" > Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Gabor, all, I have reviewed the document and I think it is in very good shape. These ar= e some minor comments I have: Abstract Even though TV bands are currently the primary applications for PAWS, the p= rotocol could be applicable to other bands. Hence, I would suggest removing= =93TV=94 from the second paragraph of the Abstract. MSP->This section has received some changes based on comments from Subir. "= TV" is still in the abstract, but in a lower priority. Recall that we had d= iscussion on the email reflector whether to remove 'TV' or not, with the re= sult that many instances were removed, but some remain. Section 1.1 Multiple examples are provided throughout this section. Some are inside par= enthesis, some are preceded by =93e.g.=94 and some are not. I would suggest= keeping a common writing style when providing these examples. Replace =93=85such as antenna height, and sometimes power.=94 by =93=85such= as antenna height and power.=94 MSP->Agree, made the changes to the section. Section 1.2.1 Replace =93=85basic service in TV white space.=94 by =93=85basic service i= n white spaces.=94 (or alternatively =93=85basic service in white space fre= quencies.=94) MSP->Agree, made the change. Section 6.1 P.5 and P.6 could be combined into one single requirement with some wording= similar to the one used in P.7, e.g. =93The messages sent by the master de= vice and database MUST support integrity protection.=94 MSP->Agree, combined P.5 and P.5 Section 6.2 I believe there is a preposition missing in O.5: =93The master device MUST = obtain an indication =91about=92 the regulatory domain governing operation= =85=94 MSP->Agree, made the change. Regards, Juan Carlos From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, June 07, 2012 11:40 AM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don=92t get reviews, we can=92t make progress. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let=92s h= ave another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Probasco = Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CC0793ACD51Fscottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hello Juan Carlos,

Thank you for reviewing the draft and providing comments. I have addre= ssed each of your comments, please see below (MSP->) for further informa= tion.

Kind Regards,
Scott

From: Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com= >
Date: Thu, 14 Jun 2012 17:17:19 -04= 00
To: Gabor Bajko <Gabor.Bajko@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] 2nd WGLC for dr= aft-ietf-paws-problem-stmt-usecases-rqmts

Gabor, all,

 

I have reviewed the document and I= think it is in very good shape. These are some minor comments I have:=

 

 

Abstract

 

Even th= ough TV bands are currently the primary applications for PAWS, the protocol= could be applicable to other bands. Hence, I would suggest removing =93TV=94 from the second paragraph of the Abstrac= t.
MSP->This section has received some changes based on comments from = Subir. "TV" is still in the abstract, but in a lower priority. Re= call that we had discussion on the email reflector whether to remove 'TV' o= r not, with the result that many instances were removed, but some remain.

&n= bsp;

Secti= on 1.1

=  

Multipl= e examples are provided throughout this section. Some are inside parenthesi= s, some are preceded by =93e.g.=94 and some are not. I would suggest keeping a common writing style when providing the= se examples.

&n= bsp;

Replace= =93=85such as antenna height, and sometimes power.=94 by =93=85such as ant= enna height and power.=94
MSP->Agree, made the changes to the section.

&n= bsp;

Secti= on 1.2.1

=  

Replace= =93=85basic service in TV white space.=94 by  =93=85basic service in = white spaces.=94 (or alternatively =93=85basic service in white space frequencies.=94)
MSP->Agree, made the change.

&n= bsp;

Secti= on 6.1

=  

P.5 and= P.6 could be combined into one single requirement with some wording simila= r to the one used in P.7, e.g. =93The messages sent by the master device and database MUST support integrity protection.= =94
MSP->Agree, combined P.5 and P.5

&n= bsp;

Secti= on 6.2

=  

I belie= ve there is a preposition missing in O.5: =93The master device MUST obtain = an indication =91about=92 the regulatory domain governing operation=85=94
MSP->Agree, made the change.

&n= bsp;

&n= bsp;

&n= bsp;

Regar= ds,

=  

Juan = Carlos

=  

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@no= kia.com
Sent: Thursday, June 07, 2012 11:40 AM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

Folks,

 

I issued the below 2nd = wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

and I only got one review with a c= omment which is easy to address.

 

We really need more reviews in ord= er to be able to progress the draft. If you care about the use cases and re= quirements related to White Space Database Access, please read the draft and send your comments to the list. If you d= o not have comments, then 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.

 

I cannot send the draft to the IES= G without a minimum number of reviews. Ie, if we don=92t get reviews, we ca= n=92t make progress.

 

Thanks, Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts

 

Since there were quite a few chang= es made to the new version -04, let=92s have another WGLC for this document= .

 

Therefore, I'd like to initiate a = 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

 

Please review the draft and send y= our comments to the list by June 1st, 2012.

 

If you review the draft and have n= o comments, send a note to the list that the draft is good as it is, we nee= d these notes as much as we need the actual comments.

 

Thanks, Gabor

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Probasco Scott (Noki= a-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: paws@ietf.org
Subject: [paws] UC&R document

 

Hello All,

 

A new version of the Use Cases & Requirements draft has b= een uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.<= o:p>

 

Kind Regards,

Raj & Scott

 

 

 

Abstract:

   Portions of the radio spectrum that are assigned= to a particular use

   but are unused or unoccupied at specific locatio= ns and times are

   defined as "white space".  T= he concept of allowing additional

   transmissions (which may or may not be licensed)= in white space is a

   technique to &quot;unlock&quot; existing= spectrum for new use.  An obvious

   requirement is that these additional transmissio= ns do not interfere

   with the assigned use of the spectrum. &nbs= p;One approach to using the

   white space spectrum at a given time and locatio= n is to verify with a

   database for available channels.

 

   This document describes the concept of TV White = Spaces.  It also

   describes the problems that need to be addressed= to enable white

   space spectrum for additional uses, without caus= ing interference to

   currently assigned use, by querying a database w= hich stores

   information about the channel availability at an= y given location and

   time.  A number of possible use cases = of white space spectrum and

   technology as well as a set of requirements for = the database query

   protocol are also described.

 

 

 

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CC0793ACD51Fscottprobasconokiacom_-- From Gabor.Bajko@nokia.com Wed Jun 20 14:23:11 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5FF11E8093 for ; Wed, 20 Jun 2012 14:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Nc5kIwFuiG5 for ; Wed, 20 Jun 2012 14:23:07 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id B2A0011E8083 for ; Wed, 20 Jun 2012 14:23:05 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5KLN46X021766 for ; Thu, 21 Jun 2012 00:23:04 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jun 2012 00:23:04 +0300 Received: from 008-AM1MPN1-001.mgdnok.nokia.com ([169.254.1.49]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Wed, 20 Jun 2012 23:23:03 +0200 From: To: Thread-Topic: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQAWsY/PABH2sBAAAPSHPg Date: Wed, 20 Jun 2012 21:23:02 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F3AA1E@008-AM1MPN1-001.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F3AA1E008AM1MPN1001mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jun 2012 21:23:04.0677 (UTC) FILETIME=[E1103950:01CD4F2A] X-Nokia-AV: Clean Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 20 Jun 2012 21:23:11 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F3AA1E008AM1MPN1001mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Thanks for the comments received. The editors will generate a new version o= f the draft including proposed changes from Subir and JC, and add a new req= uirement to support pre-configured databases as requested by Peter and Joel= (eg, add a new requirement P.x: The address of a database (eg in form of a= URI) can be preconfigured in a master device. The master device MUST be ab= le to contact a database using a pre-configured database address.) If there won't be any additional comments received in the next week or so, = we can hopefully send the updated draft to the iesg, then the wg can focus = on the solution space. Regards, Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pro= basco Scott (Nokia-CIC/Dallas) Sent: Wednesday, June 20, 2012 1:59 PM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Hello Juan Carlos, Thank you for reviewing the draft and providing comments. I have addressed = each of your comments, please see below (MSP->) for further information. Kind Regards, Scott From: Juan Zuniga > Date: Thu, 14 Jun 2012 17:17:19 -0400 To: Gabor Bajko >, "paw= s@ietf.org" > Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Gabor, all, I have reviewed the document and I think it is in very good shape. These ar= e some minor comments I have: Abstract Even though TV bands are currently the primary applications for PAWS, the p= rotocol could be applicable to other bands. Hence, I would suggest removing= "TV" from the second paragraph of the Abstract. MSP->This section has received some changes based on comments from Subir. "= TV" is still in the abstract, but in a lower priority. Recall that we had d= iscussion on the email reflector whether to remove 'TV' or not, with the re= sult that many instances were removed, but some remain. Section 1.1 Multiple examples are provided throughout this section. Some are inside par= enthesis, some are preceded by "e.g." and some are not. I would suggest kee= ping a common writing style when providing these examples. Replace "...such as antenna height, and sometimes power." by "...such as an= tenna height and power." MSP->Agree, made the changes to the section. Section 1.2.1 Replace "...basic service in TV white space." by "...basic service in whit= e spaces." (or alternatively "...basic service in white space frequencies."= ) MSP->Agree, made the change. Section 6.1 P.5 and P.6 could be combined into one single requirement with some wording= similar to the one used in P.7, e.g. "The messages sent by the master devi= ce and database MUST support integrity protection." MSP->Agree, combined P.5 and P.5 Section 6.2 I believe there is a preposition missing in O.5: "The master device MUST ob= tain an indication 'about' the regulatory domain governing operation..." MSP->Agree, made the change. Regards, Juan Carlos From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, June 07, 2012 11:40 AM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don't get reviews, we can't make progress. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let's hav= e another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Probasco = Scott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F3AA1E008AM1MPN1001mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,<= /p>

 <= /p>

Thanks for the comments r= eceived. The editors will generate a new version of the draft including pro= posed changes from Subir and JC, and add a new requirement to support pre-configured databases as requested by Peter and Joel (eg, ad= d a new requirement P.x: The address of a database (eg in for= m of a URI) can be preconfigured in a master device. The master device MUST= be able to contact a database using a pre-configured database address.)

 <= /p>

If there won’t be a= ny additional comments received in the next week or so, we can hopefully se= nd the updated draft to the iesg, then the wg can focus on the solution space.

 <= /p>

Regards, Gabor=

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Wednesday, June 20, 2012 1:59 PM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

Hello Juan Carlos,

 

Thank you for reviewing the= draft and providing comments. I have addressed each of your comments, plea= se see below (MSP->) for further information.

 

Kind Regards,

Scott

 

From: Juan Zuniga <JuanCarlos.Zuniga@InterDigital.com> Date: Thu, 14 Jun 2012 17:17:19 -0400
To: Gabor Bajko <Gabor.B= ajko@nokia.com>, "paws@ietf.or= g" <paws@ietf.org>
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

Gabor, all,

 

I have reviewed the docum= ent and I think it is in very good shape. These are some minor comments I h= ave:

 

 

Abstract

 

MSP->This section has re= ceived some changes based on comments from Subir. "TV" is still i= n the abstract, but in a lower priority. Recall that we had discussion on the email reflector whether to remove 'TV' or not, with the result that= many instances were removed, but some remain.

Section 1.1

 

MSP->Agree, made the cha= nges to the section.

Section 1.2.1

 

<= /p>

MSP->Agree, made the cha= nge.

Section 6.1

 

MSP->Agree, combined P.5= and P.5

Section 6.2

 

MSP->Agree, made the cha= nge.

Regards,

 

Juan Carlos

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@no= kia.com
Sent: Thursday, June 07, 2012 11:40 AM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 =

Folks,

 

I issued the below 2= nd wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

and I only got one review= with a comment which is easy to address.

 

We really need more revie= ws in order to be able to progress the draft. If you care about the use cas= es and requirements related to White Space Database Access, please read the draft and send your comments to the list. If you do not ha= ve comments, then 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.

 

I cannot send the draft t= o the IESG without a minimum number of reviews. Ie, if we don’t get r= eviews, we can’t make progress.

 

Thanks, Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts

 =

Since there were quite a = few changes made to the new version -04, let’s have another WGLC for = this document.

 

Therefore, I'd like to in= itiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

 

Please review the draft a= nd send your comments to the list by June 1st, 2012.

 

If you review the draft a= nd have no comments, send a note to the list that the draft is good as it i= s, we need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Probasco Scott (Noki= a-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: paws@ietf.org
Subject: [paws] UC&R document=

 =

Hello All,

 

A new version of the Use Cases & Requirements draft has b= een uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.<= /span>

 

Kind Regards,

Raj & Scott=

 

 

 

Abstract:

   Portions of the radio spectrum that are assigned= to a particular use

   but are unused or unoccupied at specific locatio= ns and times are

   defined as "white space".  T= he concept of allowing additional

   transmissions (which may or may not be licensed)= in white space is a

   technique to &quot;unlock&quot; existing= spectrum for new use.  An obvious

   requirement is that these additional transmissio= ns do not interfere

   with the assigned use of the spectrum. &nbs= p;One approach to using the

   white space spectrum at a given time and locatio= n is to verify with a<= /p>

   database for available channels.

 

   This document describes the concept of TV White = Spaces.  It also

   describes the problems that need to be addressed= to enable white

   space spectrum for additional uses, without caus= ing interference to

   currently assigned use, by querying a database w= hich stores

   information about the channel availability at an= y given location and

   time.  A number of possible use cases = of white space spectrum and

   technology as well as a set of requirements for = the database query

   protocol are also described.

 

 

 

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

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601F3AA1E008AM1MPN1001mg_-- From sdas@appcomsci.com Wed Jun 20 19:58:02 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD011E80BE for ; Wed, 20 Jun 2012 19:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M56gIMb-8p3c for ; Wed, 20 Jun 2012 19:57:55 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 98E6B11E80D0 for ; Wed, 20 Jun 2012 19:57:53 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q5L2vo6H028136; Wed, 20 Jun 2012 22:57:50 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q5L2vnHV018267; Wed, 20 Jun 2012 22:57:49 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Wed, 20 Jun 2012 22:57:49 -0400 From: "Das, Subir" To: "scott.probasco@nokia.com" , "paws@ietf.org" Thread-Topic: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Thread-Index: Ac0y/JFDVFy+C21AQRmgK91Y1eqFMARxiunQARQB1TABdmlsAAAbSh2g Date: Thu, 21 Jun 2012 02:57:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: multipart/alternative; boundary="_000_AAC987F0CC2C7845A9FBD8A36D52E12D9085BArrcatsexmb1_" MIME-Version: 1.0 Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts 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, 21 Jun 2012 02:58:02 -0000 --_000_AAC987F0CC2C7845A9FBD8A36D52E12D9085BArrcatsexmb1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, Thanks for addressing the comments. Regards, -Subir From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: Wednesday, June 20, 2012 4:56 PM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Hello Subir, Thank you for reviewing the draft and providing comments. I have addressed = each of your comments, please see below (MSP->) for further information. Kind Regards, Scott From: "ext Das, Subir" > Date: Wed, 13 Jun 2012 03:28:39 +0000 To: Gabor Bajko >, "paw= s@ietf.org" > Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s We have reviewed the draft and it looks good. Below are some technical an= d editorial comments. Hope these are helpful. Regards, -Subir =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Technical: Section 1.2.1, In Scope: Page 6: "2. Connect to the database using a well-defined access method." SD> What is the meaning of 'well-defined access method' here? Then in the = following bullet point, it says 'using a well-defined protocol'. May be t= his is not necessary since the starting sentence of the section says "The = protocol will enable". MSP->These terms refer to the completed PAWS protocol. "As a result, some of the scenarios described in the following section are = out of scope for this specification (although they might be addressed by f= uture specifications)." SD> It would be good if the 'out of scope' sections are explicitly identifi= ed. MSP->I have removed the sentence citing 'out of scope'. Section 2.2: Terminology: Page 6: Database In the context of white space and cognitive radio technologies, the databas= e is an entity which contains, but is not limited to, current information a= bout available spectrum at any given location SD> Suggest modifying the definition like this: In the context of white space and cognitive radio technologies, the databas= e is an entity which contains, but is not limited to, current information a= bout available spectrum at any given location and time as required by the= regulatory policies. MSP->I have modified the definition based on your proposal. Page 8: "White Space Device (WSD) A device which opportunistically uses some part of white space spectrum. A= white space device can be an access point, base station, a portable devic= e or similar. A white space device may be required by local regulations t= o query a database with its location to obtain information about available = spectrum." SD> Suggest adding definition of `Master Device` and ` Slave Device` as = two types of WSDS here and then delete them from Page 7 - Master Device WSD A device which is required to query the WS Database to find out the avail= able operating channels. - Slave Device WSD A device which uses the spectrum made available by a master device an= d cannot query the database directly. MSP-> I have updated the definition of Slave Device based on your text abov= e. I have left the definitions as stand-alone definitions rather than placi= ng them under "White Space Device (WSD)" as the definitions are listed alph= abetically. Section 4.1: Page 9 "A complete protocol solution must provide all services that are essential = to enable the white space paradigm. Before a white space device can begin = operating it needs to know what channels are available by sending a query t= o a white space database for a list of available channels, the white space = device must first locate or "discover" a suitable database." SD> Suggest changing the last sentence like this: "...., the white space de= vice must have the capability to first locate or discover a suitable datab= ase." MSP->I have implemented your proposal. Section 4.1.2: Page 11 SD> In Figure 2, Where is the 'Slave Device'? Also it may be better just= to mention 'Air IF' instead of 'TDD Air IF'. MSP->There is no slave device since only the Master Device registers with t= he database. I have removed "TDD" from the figure. Page 15: Comment: In some use case it says 'Dev' and other use cases it says 'Slave = Dev'. Good to have the consistency. MSP->I have made changes in 4.2.1 step 6 & 9. Section 4.2.3: Page 18 "1. The dual mode (or multi mode) device (3G + TVWS) is connected to a 3G n= etwork. The device has contacted a trusted database to discover the list o= f available TV channels at its current location. The device has located a = TVWS master/AP operating on an available channel and has associated or con= nected with the TVWS master/AP." SD> I got the impression from the above text that 'The device' refers to= the `Slave WS Dev' in Figure 5 and it has contacted the database. Am I= correct? If so, the text needs to be updated to clarify that the slave= cannot contact the database directly. MSP->I have removed the text describing the slave device contacting the dat= abase. Section 4.2.6: Page 22: "7. The slave/user device scans to locate a mobile master transmission, and= associates with the mobile master." SD> Where is the slave device coming from? There is no 'Slave device' in f= igure 8? MSP->I have added a slave device to Figure 8 and clarified in step 6 that m= aster-master communications are possible outside the scope of PAWS. Section 4.2.7, Page 23: SD> In Figure 9, there is a connection between Master devices using 'WS Air= IF' . Does this mean these devices have both 'Master' and 'Slave' capabili= ties? There is no such description and it is hard to understand why this c= onnection is necessary and its intended purpose. MSP->This capability is described in the first paragraph under 4.2.7. I hav= e clarified in step 6 that master-master communications are possible outsid= e the scope of PAWS. Section 4.2.8: Page 26: "7. The slave devices fitted to the machines scan the TV bands to locate th= e master transmissions, and associate with the master device." SD> The above step implies to me that all slave devices are connected to Ma= ster but the Figure 10 does not indicate that. MSP->The first paragraph in 4.2.8 does specify that each slave device is un= der control of a master device. Section 5: Page 28: SD> In Figure it says 'WS device' and it interfaces to the Database direct= ly . OTH, in all use cases the interface with the database is coming from = the 'Master Device'. It should be consistent. Suggest changing to 'Master = Device' or WSD Device (Master)'. MSP->I have updated Figure 11 to "Master" WS Device. Section 5.2 : Page 29: SD> This section seems to be a duplicate since Section 4.1.1 already covers= this. MSP->This section is relevant to the Problem Statement (Chapter 5) and shou= ld be kept. Section 5.4: Page 29: "Use of XML for specifying a data model is an attractive option. The inten= t is to evaluate the best option that meets the need for use between white = space devices and databases." SD> Suggest adding XML as an example MSP->Examples are nice, however as we are concluding the 2nd WGLC I propose= to leave this as written. Section 6.1: Page 30: "D.2: The Data Model MAY support specifying the regulatory domain and its= corresponding data requirements." SD> This requirement should be a 'MUST'; if not how will the databases in= terpret it? Also in P.2 it says "The protocol MUST support determination o= f regulatory domain governing its current location". Unless it is a must, = P.2 cannot be satisfied, IMO MSP->Changed D.2 to MUST. Page 31: "D.4: The Data Model MUST support specifying a manufacturer's serial numb= er for a master device" SD> Suggest deleting ` the master device' at the end. Since the serial n= umber is also applicable for slave device. MSP->Changed 'master' to 'white space' Page 33: SD> Q.6 and Q.7 may be merged. MSP->Merged O.6 and O.7 Section 8: Page 38: "Threat 8: Natural disaster resulting in inability to obtain authorization= for white space spectrum use by emergency responders" Last sentence of this section says " The security requirements arising from= the above threats are captured in the requirements of section 6.1." SD> Not sure I understand the threat model here. Also it seems that the se= ction reference is not correct. MSP->Section 6.1 is Normative Requirements, and contain the requirements ag= reed as result of the threat model. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Editorial: MSP->I have included the editorial corrections. Abstract 2nd paragraph : Page 1 "This document describes the concept of TV White Spaces." >From the above sentence I got the impression that the main focus of this dr= aft is to describe the concept of TV white Space which I believe is not. M= ay rephrase this or start with the second sentence like: This document desc= ribes the use cases and requirements of TV White Space and introduces the p= roblems that need ...." Section 3.2, Page 8: "More information about the switch to digital transmission is at : [DTV]." SD> Delete ':' Page 17: If the channel that a slave/user terminal is currently using is not longer = .. SD> Typo : 'not/no longer ...' Page 28: 4. Address regulatory requirements - Each country will likely have ... SD> typo: 'likely to have ...' Page 35: "Threat 1: .... A white space database may be operated by a commercial ent= ity which restricts access to authorized users. " SD> May add 'only' after 'access'; 'access to only authorized users. 'Threat 2: A master device discovers a white space database(s) thru which i= t can query for channel information.' SD> Typo: 'thru/through' From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Thursday, June 07, 2012 11:40 AM To: paws@ietf.org Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmt= s Folks, I issued the below 2nd wglc on http://www.ietf.org/internet-drafts/draft-ie= tf-paws-problem-stmt-usecases-rqmts-04.txt and I only got one review with a comment which is easy to address. We really need more reviews in order to be able to progress the draft. If y= ou care about the use cases and requirements related to White Space Databas= e Access, please read the draft and send your comments to the list. If you = do not have comments, then send a note to the list that the draft is good a= s it is, we need these notes as much as we need the actual comments. I cannot send the draft to the IESG without a minimum number of reviews. Ie= , if we don't get reviews, we can't make progress. Thanks, Gabor From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, May 15, 2012 5:50 PM To: paws@ietf.org Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-rqmts Since there were quite a few changes made to the new version -04, let's hav= e another WGLC for this document. Therefore, I'd like to initiate a 2nd WG Last Call for comments on http://w= ww.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-04.= txt Please review the draft and send your comments to the list by June 1st, 201= 2. 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 From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Probasco S= cott (Nokia-CIC/Dallas) Sent: Friday, May 11, 2012 11:51 AM To: paws@ietf.org Subject: [paws] UC&R document Hello All, A new version of the Use Cases & Requirements draft has been uploaded. This= version of the Internet Draft has addressed all of the issues raised durin= g Working Group Last Call, including discussion from IETF #83, and is ready= to be forwarded to IESG. Kind Regards, Raj & Scott Draft: http://www.ietf.org/id/draft-ietf-paws-problem-stmt-usecases-rqmts-= 04.txt Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-u= secases-rqmts-04 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvio= us requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_AAC987F0CC2C7845A9FBD8A36D52E12D9085BArrcatsexmb1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Scott,

Thanks for addressing the= comments.

 <= /p>

Regards,

-Subir

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Wednesday, June 20, 2012 4:56 PM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

Hello Subir,

 

Thank you for reviewing the= draft and providing comments. I have addressed each of your comments, plea= se see below (MSP->) for further information.

 

Kind Regards,

Scott

 

 

From: "ext Das, Subir" <sdas@appcomsci.com>
Date: Wed, 13 Jun 2012 03:28:39 +0000
To: Gabor Bajko <Gabor.B= ajko@nokia.com>, "paws@ietf.or= g" <paws@ietf.org>
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 

We have reviewed the draf= t and it looks good.   Below are some technical and editorial com= ments.  Hope these are helpful.

 

Regards,

-Subir

 

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Technical:

 

Section 1.2.1, In Scop= e:  Page 6: 

 

“2.  Connect t= o the database using a well-defined access method.”

 

SD> What is the meanin= g of ‘well-defined access method’ here?  Then in the follo= wing bullet point,  it says  ‘using a well-defined protocol= ’. May be this is not necessary since the starting sentence of the section says  “= ;The protocol will enable”.  

MSP->These terms refer t= o the completed PAWS protocol.

 

 

“As a result, some = of the scenarios described in the following section are out of scope for th= is specification (although they might be  addressed by future specifications).”

 

SD> It would be good i= f the ‘out of scope’ sections are explicitly identified.=

MSP->I have removed the = sentence citing 'out of scope'.

 

Section 2.2: Terminolo= gy: Page 6:

 

Database

In the context of white s= pace and cognitive radio technologies, the database is an entity which cont= ains, but is not limited to, current information about available spectrum at any given location 

 

SD>  Suggest = ; modifying the definition like this:

 

In the context of white s= pace and cognitive radio technologies, the database is an entity which cont= ains, but is not limited to, current information about available spectrum at any given location  and time as  required by the reg= ulatory policies.

MSP->I have modified the= definition based on your proposal.

 

Page 8:

 

“White Space Device= (WSD)

 

A device which opportunis= tically uses some part of white space spectrum.  A white space device = can be an access point, base  station, a portable device or similar.&n= bsp; A white space device may  be required by local regulations to query a= database with its location to obtain information about available spectrum.= ”

 

SD> Suggest  addi= ng definition  of `Master Device` and ` Slave Device`  as two typ= es of WSDS here and then delete  them from Page 7

 

- &nbs= p;        Master Device WSD

A device   whic= h is required to query the WS Database to find out the available operating = channels.

 

- &nbs= p;        Slave Device WSD

    &= nbsp; A device which uses the spectrum made available by a master devi= ce and cannot query the  database  directly.

MSP-> I have updated the= definition of Slave Device based on your text above. I have left the defin= itions as stand-alone definitions rather than placing them under "White Space Device (WSD)" as the definitions are listed a= lphabetically.

 <= /p>

 

Section 4.1: Page 9

 

“A complete protoco= l solution must provide all services that are essential to enable the white= space paradigm.  Before a white space device can begin operating it needs to know what channels are available by sending a query to a white= space database for a list of available channels, the white space device mu= st first locate or  "discover" a suitable database.”

 

SD> Suggest changing t= he last sentence like this: “…., the white space device must ha= ve the capability to first locate or discover  a suitable database.= 221;

MSP->I have implemented = your proposal. 

 

 

Section 4.1.2: Page 11

 

SD> In Figure 2, =   Where is the ‘Slave Device’?  Also it may be better= just to mention ‘Air IF’  instead of ‘TDD Air IF= 217;. 

MSP->There is no slave d= evice since only the Master Device registers with the database. I have remo= ved "TDD" from the figure.

 

 

Page 15:

 

Comment: In some use case= it says ‘Dev’ and other use cases it says ‘Slave DevR= 17;. Good to have the consistency.<= /o:p>

MSP->I have made changes= in 4.2.1 step 6 & 9.

 

 

Section 4.2.3: Page 18=

 

“1. The dual mode (= or multi mode) device (3G + TVWS) is connected to a 3G network.  T= he device has contacted a trusted database to discover the list of availabl= e TV channels at its current location.  The device has located a TVWS m= aster/AP operating on  an available channel and has associated or conn= ected with the TVWS master/AP.”

 

SD>  I got the im= pression from the above text   that ‘The device’ refe= rs to the `Slave  WS Dev’  in Figure 5 and it has contacted=   the database.  Am I correct?   If so,  the text  needs to be updated to clarify that the slave = cannot contact the database directly.

MSP->I have removed the = text describing the slave device contacting the database.=

 

 

Section 4.2.6:  P= age 22:

 

“7. The slave/user = device scans to locate a mobile master transmission, and associates with th= e mobile master.”

 

SD> Where is the slave= device coming from? There is no ‘Slave device’ in  figure= 8?

MSP->I have added a slav= e device to Figure 8 and clarified in step 6 that master-master communicati= ons are possible outside the scope of PAWS.

 

 

Section  4.2.7, P= age 23:

 

SD> In Figure 9, there= is a connection between Master devices using ‘WS Air IF’ . Doe= s this mean these devices have both ‘Master’ and ‘Slave&#= 8217; capabilities?  There is no such description and it is hard to understand why this connect= ion is necessary and its intended purpose.

MSP->This capability is = described in the first paragraph under 4.2.7. I have clarified in step 6 th= at master-master communications are possible outside the scope of PAWS.

 

Section 4.2.8: Page 26= :

 

“7. The slave devic= es fitted to the machines scan the TV bands to locate the master transmissi= ons, and associate with the master device.”

 

SD> The above step imp= lies to me that all slave devices are connected to Master but the Figure 10= does not indicate that.

MSP->The first paragraph= in 4.2.8 does specify that each slave device is under control of a master = device.

 

Section 5: Page 28:

 

SD>  In Figure it= says ‘WS device’ and it interfaces to the Database directly . = OTH, in all use cases the  interface with the database is coming from = the ‘Master Device’.  It should be consistent. Suggest changing to ‘M= aster Device’ or WSD Device (Master)’.

MSP->I have updated Figu= re 11 to "Master" WS Device.

 

Section 5.2 : Page 29:=

 

SD> This section seems= to be a duplicate since Section 4.1.1 already covers this.

MSP->This section is rel= evant to the Problem Statement (Chapter 5) and should be kept.

 

Section 5.4: Page 29:<= /span>

 

“Use of XML for spe= cifying a data model is an attractive option.  The intent is to evalua= te the best option that meets the need for use between white space devices and databases.”

 

SD> Suggest adding&nbs= p; XML  as an example

MSP->Examples are nice, = however as we are concluding the 2nd WGLC I propose to leave this as writte= n.

 

Section 6.1: Page 30:<= /span>

 

“D.2: The Data Mode= l  MAY  support specifying the regulatory domain and its correspo= nding data requirements.”

 

SD> This requirement&n= bsp;  should be a ‘MUST’; if not how will the databases in= terpret it?  Also in P.2 it says “The protocol MUST support dete= rmination of regulatory domain governing its current location”.  Unless it is a must, P= .2 cannot be satisfied, IMO

MSP->Changed D.2 to MUST= .

 

Page 31:

 

“D.4:   T= he Data Model MUST support specifying a manufacturer's serial number for a = master device”

 

SD>  Suggest dele= ting ` the master device’ at the end.   Since the serial nu= mber is also applicable for slave device.

MSP->Changed 'master' to= 'white space'

 

 

Page 33:

 

SD> Q.6 and Q.7 may&nb= sp; be merged.

MSP->Merged O.6 and O.7<= o:p>

 

 

Section 8: Page 38:

 

“Threat 8:  Na= tural disaster resulting in inability to obtain authorization for white spa= ce spectrum use by emergency responders”

 

Last sentence of this sec= tion says “ The security requirements arising from the above threats = are captured  in the requirements of section 6.1.”

 

SD> Not sure I underst= and the threat model  here. Also it seems that the section reference i= s not correct.

MSP->Section 6.1 is Norm= ative Requirements, and contain the requirements agreed as result of the th= reat model.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Editorial:<= span style=3D"color:black">

MSP->I have included the= editorial corrections.

 

Abstract 2nd paragraph= : Page 1

“This document desc= ribes the concept of TV White Spaces.”   

 

From the above sentence I= got the impression that the main focus of this draft is to describe the co= ncept of TV white Space which I believe is not.  May rephrase this or start with the second sentence like: This document describes the u= se cases and requirements of TV White Space and introduces the problems tha= t need ….”=

 

Section 3.2, Page 8:

 

“More information a= bout the switch to digital transmission is at : [DTV].”

 

SD> Delete ‘:= 217;

 

Page 17:

 

If the channel that a sla= ve/user terminal is currently using is not longer ..

 

SD> Typo :  ̵= 6;not/no  longer …’

 

Page 28:

 

4.  Address regulato= ry requirements - Each country will likely have …

 

SD> typo:  ‘= ;likely to have …’

 

Page 35:

 

“Threat 1:  &#= 8230;. A white space database may be operated by a commercial entity which = restricts

access to authorized user= s. “

 

SD> May add ‘onl= y’  after ‘access’;  ‘access to only auth= orized users.

 

‘Threat 2: A master= device discovers a white space database(s) thru which it can query for cha= nnel information.’

 

SD> Typo: ‘thru/= through’

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@no= kia.com
Sent: Thursday, June 07, 2012 11:40 AM
To: paws@ietf.org
Subject: Re: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecas= es-rqmts

 =

Folks,

 

I issued the below 2= nd wglc on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

and I only got one review= with a comment which is easy to address.

 

We really need more revie= ws in order to be able to progress the draft. If you care about the use cas= es and requirements related to White Space Database Access, please read the draft and send your comments to the list. If you do not ha= ve comments, then 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.

 

I cannot send the draft t= o the IESG without a minimum number of reviews. Ie, if we don’t get r= eviews, we can’t make progress.

 

Thanks, Gabor

 

From:paws-bounces@ietf.o= rg [mailto:paws-bounces@ietf.org= ] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, May 15, 2012 5:50 PM
To: paws@ietf.org
Subject: [paws] 2nd WGLC for draft-ietf-paws-problem-stmt-usecases-r= qmts

 =

Since there were quite a = few changes made to the new version -04, let’s have another WGLC for = this document.

 

Therefore, I'd like to in= itiate a 2nd WG Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-04.txt

 

Please review the draft a= nd send your comments to the list by June 1st, 2012.

 

If you review the draft a= nd have no comments, send a note to the list that the draft is good as it i= s, we need these notes as much as we need the actual comments.

 

Thanks, Gabor

 

 

From:paws-bounces@ietf.o= rg [mailto:paws-bounces@ietf= .org] On Behalf Of Probasco Scott (Nokia-CIC/Dallas)
Sent: Friday, May 11, 2012 11:51 AM
To: paws@ietf.org
Subject: [paws] UC&R document=

 =

Hello All,

 

A new version of the Use Cases & Requirements draft has b= een uploaded. This version of the Internet Draft has addressed all of = the issues raised during Working Group Last Call, including discussion from IETF #83, and is ready to be forwarded to IESG.<= /span>

 

Kind Regards,

Raj & Scott=

 

 

 

Abstract:

   Portions of the radio spectrum that are assigned= to a particular use

   but are unused or unoccupied at specific locatio= ns and times are

   defined as "white space".  T= he concept of allowing additional

   transmissions (which may or may not be licensed)= in white space is a

   technique to &quot;unlock&quot; existing= spectrum for new use.  An obvious

   requirement is that these additional transmissio= ns do not interfere

   with the assigned use of the spectrum. &nbs= p;One approach to using the

   white space spectrum at a given time and locatio= n is to verify with a<= /p>

   database for available channels.

 

   This document describes the concept of TV White = Spaces.  It also

   describes the problems that need to be addressed= to enable white

   space spectrum for additional uses, without caus= ing interference to

   currently assigned use, by querying a database w= hich stores

   information about the channel availability at an= y given location and

   time.  A number of possible use cases = of white space spectrum and

   technology as well as a set of requirements for = the database query

   protocol are also described.

 

 

 

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

--_000_AAC987F0CC2C7845A9FBD8A36D52E12D9085BArrcatsexmb1_-- From internet-drafts@ietf.org Thu Jun 21 09:42:31 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90721F8746; Thu, 21 Jun 2012 09:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.276 X-Spam-Level: X-Spam-Status: No, score=-102.276 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuuWg4IKrFuR; Thu, 21 Jun 2012 09:42:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B02921F8679; Thu, 21 Jun 2012 09:42:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120621164230.15619.87332.idtracker@ietfa.amsl.com> Date: Thu, 21 Jun 2012 09:42:30 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 16:42:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt Pages : 42 Date : 2012-06-21 Abstract: Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes a number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol. The concept of TV white spaces is described including the problems that need to be addressed to enable white space spectrum for additional uses without causing interference to currently assigned use. Use of white space is enabled by querying a database which stores information about the channel availability at any given location and time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-= rqmts-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scott.probasco@nokia.com Thu Jun 21 09:57:32 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FC621F86C7 for ; Thu, 21 Jun 2012 09:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xwoh+dEse3p for ; Thu, 21 Jun 2012 09:57:32 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DF6C721F86D1 for ; Thu, 21 Jun 2012 09:57:31 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5LGvT8n018926 for ; Thu, 21 Jun 2012 19:57:30 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jun 2012 19:57:31 +0300 Received: from 008-AM1MPN1-025.mgdnok.nokia.com ([169.254.5.69]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Thu, 21 Jun 2012 18:57:29 +0200 From: To: Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt Thread-Index: AQHNT87waPQcHCLdgEi6NSBAo5lVnw== Date: Thu, 21 Jun 2012 16:57:28 +0000 Message-ID: In-Reply-To: <20120621164230.15619.87332.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.184.35.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jun 2012 16:57:31.0309 (UTC) FILETIME=[F272F5D0:01CD4FCE] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 16:57:32 -0000 Hello All, This version 05 contains updates from the editors to address the comments posted to the reflector during 2nd WGLC. We hope this fulfills the work group's needs & desires, and look forward to continued progress in PAWS. Kind Regards, Scott & Raj On 6/21/12 11:42 AM, "ext internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Protocol to Access WS database Working >Group of the IETF. > > Title : Protocol to Access White Space database: PS, use >cases and rqmts > Author(s) : Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > Pages : 42 > Date : 2012-06-21 > >Abstract: > Portions of the radio spectrum that are assigned to a particular use > but are unused or unoccupied at specific locations and times are > defined as "white space". The concept of allowing additional > transmissions (which may or may not be licensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these additional transmissions do not interfere > with the assigned use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with a > database for available channels. > > This document describes a number of possible use cases of white space > spectrum and technology as well as a set of requirements for the > database query protocol. The concept of TV white spaces is described > including the problems that need to be addressed to enable white > space spectrum for additional uses without causing interference to > currently assigned use. Use of white space is enabled by querying a > database which stores information about the channel availability at > any given location and time. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqm >ts > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-05 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases= -r >qmts-05 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Mon Jun 25 08:02:14 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAEB11E8080 for ; Mon, 25 Jun 2012 08:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrpwUWwI7YrK for ; Mon, 25 Jun 2012 08:02:12 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2C411E8079 for ; Mon, 25 Jun 2012 08:02:12 -0700 (PDT) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 25 Jun 2012 16:02:11 +0100 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.33]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Mon, 25 Jun 2012 16:02:11 +0100 From: To: , Date: Mon, 25 Jun 2012 16:02:10 +0100 Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt Thread-Index: AQHNT87waPQcHCLdgEi6NSBAo5lVn5cLHxFQ Message-ID: <619CDADDCCD2B44380834BE8BF6F714140A82F45FA@EMV62-UKRD.domain1.systemhost.net> References: <20120621164230.15619.87332.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2012 15:02:14 -0000 Scott, Raj Thank you for all your hard work on the requirements drafts. I've reviewed = draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt and it appears to cover = all the UK and Ofcom requirements as we currently understand them. I believ= e that there will be a public url from next week for the reference for [Ofc= om Requirements], and I'll let you know as soon as this is made available. I have a suggestion regarding Figure 8, for clarity. According to the text,= this scenario is not dependent on the air interface being TDD, so it shoul= d be labelled as "WS AirIF" (for consistency with subsequent figures) inste= ad of "TDD Air Interface". I then suggest that the label is moved to be nex= t to or across the dotted line between the right hand master device and the= slave device that was added recently under editing. At the moment it could= be interpreted that the slave is wired to the master. Finally I have found just two typos: In 6.2 O.2, second sentence: "... have the capability determine its locatio= n..." is missing "to" In 6.2 O.9, "frequency" is misspelt. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 21 June 2012 17:57 To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -05.txt Hello All, This version 05 contains updates from the editors to address the comments p= osted to the reflector during 2nd WGLC. We hope this fulfills the work grou= p's needs & desires, and look forward to continued progress in PAWS. Kind Regards, Scott & Raj On 6/21/12 11:42 AM, "ext internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Protocol to Access WS database=20 >Working Group of the IETF. > > Title : Protocol to Access White Space database: PS, use >cases and rqmts > Author(s) : Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > Pages : 42 > Date : 2012-06-21 > >Abstract: > Portions of the radio spectrum that are assigned to a particular use > but are unused or unoccupied at specific locations and times are > defined as "white space". The concept of allowing additional > transmissions (which may or may not be licensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these additional transmissions do not interfere > with the assigned use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with a > database for available channels. > > This document describes a number of possible use cases of white space > spectrum and technology as well as a set of requirements for the > database query protocol. The concept of TV white spaces is described > including the problems that need to be addressed to enable white > space spectrum for additional uses without causing interference to > currently assigned use. Use of white space is enabled by querying a > database which stores information about the channel availability at > any given location and time. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases- >rqm >ts > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts- >05 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecase >s-r >qmts-05 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Jun 28 17:41:29 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A8311E80F5 for ; Thu, 28 Jun 2012 17:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwrGuoCQ-KO5 for ; Thu, 28 Jun 2012 17:41:28 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD9111E80EF for ; Thu, 28 Jun 2012 17:41:28 -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 q5T0fNka005466; Fri, 29 Jun 2012 03:41:24 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 03:41:33 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.220]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0283.004; Fri, 29 Jun 2012 02:41:22 +0200 From: To: , , Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt Thread-Index: AQHNT873Ab3SCiMIQUKgDDyR7C3155cLBdgAgAV596A= Date: Fri, 29 Jun 2012 00:41:21 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F55E8B@008-AM1MPN1-006.mgdnok.nokia.com> References: <20120621164230.15619.87332.idtracker@ietfa.amsl.com> <619CDADDCCD2B44380834BE8BF6F714140A82F45FA@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140A82F45FA@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2012 00:41:33.0404 (UTC) FILETIME=[EE85C1C0:01CD558F] X-Nokia-AV: Clean Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 00:41:29 -0000 Folks, There have not been any comments to the draft version -05 which would resul= t in significant changes to the draft. The editors will generate in the nex= t few days a version -06 to incorporate the minor/editorial changes reques= ted by Andy, and I will do the write-up and send the draft to the iesg. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= andy.sago@bt.com Sent: Monday, June 25, 2012 8:02 AM To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -05.txt Scott, Raj Thank you for all your hard work on the requirements drafts. I've reviewed = draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt and it appears to cover = all the UK and Ofcom requirements as we currently understand them. I believ= e that there will be a public url from next week for the reference for [Ofc= om Requirements], and I'll let you know as soon as this is made available. I have a suggestion regarding Figure 8, for clarity. According to the text,= this scenario is not dependent on the air interface being TDD, so it shoul= d be labelled as "WS AirIF" (for consistency with subsequent figures) inste= ad of "TDD Air Interface". I then suggest that the label is moved to be nex= t to or across the dotted line between the right hand master device and the= slave device that was added recently under editing. At the moment it could= be interpreted that the slave is wired to the master. Finally I have found just two typos: In 6.2 O.2, second sentence: "... have the capability determine its locatio= n..." is missing "to" In 6.2 O.9, "frequency" is misspelt. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 21 June 2012 17:57 To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -05.txt Hello All, This version 05 contains updates from the editors to address the comments p= osted to the reflector during 2nd WGLC. We hope this fulfills the work grou= p's needs & desires, and look forward to continued progress in PAWS. Kind Regards, Scott & Raj On 6/21/12 11:42 AM, "ext internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Protocol to Access WS database=20 >Working Group of the IETF. > > Title : Protocol to Access White Space database: PS, use >cases and rqmts > Author(s) : Scott Probasco > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-05.txt > Pages : 42 > Date : 2012-06-21 > >Abstract: > Portions of the radio spectrum that are assigned to a particular use > but are unused or unoccupied at specific locations and times are > defined as "white space". The concept of allowing additional > transmissions (which may or may not be licensed) in white space is a > technique to "unlock" existing spectrum for new use. An obvious > requirement is that these additional transmissions do not interfere > with the assigned use of the spectrum. One approach to using the > white space spectrum at a given time and location is to verify with a > database for available channels. > > This document describes a number of possible use cases of white space > spectrum and technology as well as a set of requirements for the > database query protocol. The concept of TV white spaces is described > including the problems that need to be addressed to enable white > space spectrum for additional uses without causing interference to > currently assigned use. Use of white space is enabled by querying a > database which stores information about the channel availability at > any given location and time. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases- >rqm >ts > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts- >05 > >A diff from previous version is available at: >http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecase >s-r >qmts-05 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Gabor.Bajko@nokia.com Thu Jun 28 17:51:01 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBD911E80EF for ; Thu, 28 Jun 2012 17:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 j5HASZctUYxu for ; Thu, 28 Jun 2012 17:51:00 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF2911E80A2 for ; Thu, 28 Jun 2012 17:50:59 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5T0otjb001053 for ; Fri, 29 Jun 2012 03:50:56 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 03:51:06 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.220]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.02.0283.004; Fri, 29 Jun 2012 02:50:52 +0200 From: To: Thread-Topic: paws - Requested session has been scheduled for IETF 84 Thread-Index: AQHNVWUc7fQZE8B+0kqV2hI05YAWH5cQdhnA Date: Fri, 29 Jun 2012 00:50:51 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601F56EA6@008-AM1MPN1-006.mgdnok.nokia.com> References: <20120628193451.25522.3587.idtracker@ietfa.amsl.com> In-Reply-To: <20120628193451.25522.3587.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 29 Jun 2012 00:51:06.0166 (UTC) FILETIME=[43EA4D60:01CD5591] X-Nokia-AV: Clean Subject: [paws] FW: paws - Requested session has been scheduled for IETF 84 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, 29 Jun 2012 00:51:02 -0000 RllJDQoNCkEgMS41IEggc2Vzc2lvbiBoYXMgYmVlbiBhbGxvY2F0ZWQgZm9yIFBBV1MgaW4gdGhl IHVwY29taW5nIElFVEYgbWVldGluZyBpbiBWYW5jb3V2ZXIuIFRoZSBkcmFmdCBhZ2VuZGEgb24g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzg0L2FnZW5kYS50eHQgbGlzdHMg dGhlIFBBV1Mgc2Vzc2lvbiBvbiBNb25kYXksIEp1bHkgMzB0aCBhdCAxNTo0MHBzdCAodGhpcyBt YXkgY2hhbmdlKS4NCg0KRm9sa3Mgd2hvIHdvdWxkIGxpa2UgdG8gcHJlc2VudCBuZWVkIHRvIHVw ZGF0ZSB0aGVpciBleGlzdGluZyBkcmFmdCBiZWZvcmUgdGhlIEp1bHkgMTZ0aCBkZWFkbGluZSwg b3Igc3VibWl0IGEgbmV3IGRyYWZ0IGJlZm9yZSB0aGUgSnVseSA5dGggZGVhZGxpbmUuDQpJIGV4 cGVjdCBwcmVzZW50YXRpb25zIG9uIHRoZSBzb2x1dGlvbiBzcGFjZSBsaWtlIGRpc2NvdmVyeSwg ZGF0YSBtb2RlbCBhbmQgcHJvdG9jb2wuIEkgZG8gbm90IGV4cGVjdCB0byBoYXZlIGFueSBwcmVz ZW50YXRpb25zIG9uIHRoZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cyBkb2N1bWVudC4NCg0K LSBHYWJvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IElFVEYgU2Vj cmV0YXJpYXQgW21haWx0bzphZ2VuZGFAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNkYXksIEp1bmUg MjgsIDIwMTIgMTI6MzUgUE0NClRvOiBCYWprbyBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxs ZXkpDQpDYzogcGF3cy1hZHNAdG9vbHMuaWV0Zi5vcmc7IGJyQGJyaWFucm9zZW4ubmV0OyBCYWpr byBHYWJvciAoTm9raWEtQ0lDL1NpbGljb25WYWxsZXkpOyB3bG9AYW1zbC5jb20NClN1YmplY3Q6 IHBhd3MgLSBSZXF1ZXN0ZWQgc2Vzc2lvbiBoYXMgYmVlbiBzY2hlZHVsZWQgZm9yIElFVEYgODQN Cg0KRGVhciBHYWJvciBCYWprbywNCg0KVGhlIHNlc3Npb24ocykgdGhhdCB5b3UgaGF2ZSByZXF1 ZXN0ZWQgaGF2ZSBiZWVuIHNjaGVkdWxlZC4NCkJlbG93IGlzIHRoZSBzY2hlZHVsZWQgc2Vzc2lv biBpbmZvcm1hdGlvbiBmb2xsb3dlZCBieSB0aGUgb3JpZ2luYWwgcmVxdWVzdC4gDQoNCnBhd3Mg U2Vzc2lvbiAxICgxOjMwOjAwKQ0KICAgIE1vbmRheSwgQWZ0ZXJub29uIFNlc3Npb24gSUkgMTU0 MC0xNzEwDQogICAgUm9vbSBOYW1lOiBHZW9yZ2lhIEENCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCg0KDQpSZXF1ZXN0IEluZm9ybWF0aW9u Og0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KV29ya2luZyBHcm91cCBOYW1lOiANCkFyZWEgTmFtZTogDQpTZXNzaW9uIFJlcXVl c3RlcjogDQoNCk51bWJlciBvZiBTZXNzaW9uczogMQ0KTGVuZ3RoIG9mIFNlc3Npb24ocyk6ICAx LjUgSG91cnMNCk51bWJlciBvZiBBdHRlbmRlZXM6IDM1DQpDb25mbGljdHMgdG8gQXZvaWQ6IA0K IEZpcnN0IFByaW9yaXR5OiBzaXByZWMgcDJwc2lwIGVjcml0IGdlb3ByaXYgcnRjd2ViICBTZWNv bmQgUHJpb3JpdHk6IG5ldGV4dA0KDQoNCg0KU3BlY2lhbCBSZXF1ZXN0czoNCiAgDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K