From Gabor.Bajko@nokia.com Tue Dec 4 11:57:30 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE60221F85F5 for ; Tue, 4 Dec 2012 11:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeDH6h0m+38e for ; Tue, 4 Dec 2012 11:57:29 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6B021F85DC for ; Tue, 4 Dec 2012 11:57:16 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB4JvEbW013364 for ; Tue, 4 Dec 2012 21:57:14 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 21:57:13 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.199]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0318.003; Tue, 4 Dec 2012 19:57:13 +0000 From: To: Thread-Topic: outcome of the Atlanta F2F -2- Thread-Index: Ac3SVSmgSndUu+IiSRC/8/gHAvYpvQ== Date: Tue, 4 Dec 2012 19:57:12 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@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: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0614008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 19:57:13.0491 (UTC) FILETIME=[8DB3DE30:01CDD259] X-Nokia-AV: Clean Subject: [paws] outcome of the Atlanta F2F -2- X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 19:57:30 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0614008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One main discussion point in the f2f was future extensibility, for the case= s when regulators decide to require additional parameters from master devic= es; another discussion point was what parameters would the master initially= , eg after the first power up, send to the DB. The suggestion was to extend the INIT procedure from a one round trip to a = two round trips, where the first request from master would either be respon= ded as already described in the draft, or the DB would respond with a messa= ge indicating additional required parameters, after which the master would = resend the request with the indicated parameters. I believe this functionality could be supported by the currently defined on= e round trip INIT procedure as well, once the error handling is added to th= e document: 1. Master sends INIT request to the server, including at least its lo= cation 2. DB would respond with an error message, indicating the missing par= ameters 3. Master sends a new INIT request, including all the required parame= ters 4. DB sends to master the regulatory domain, parameter values and req= uired behavior from master in this regulatory domain Am I missing sg? There was also another suggestion on having the parameters which could be c= arried in message 2 above be defined and put in the IANA registry. That way= , the DB can easily point the master to which parameter it requires from it= , possibly avoiding the need for a firmware update in the master (but still= having the need for an admin to configure the required new parameter). And= with the parameters in the registry, there would be no need to do per regu= latory domain profiling of the required parameters. I would like to confirm if this path forward is ok with folks; if you have = objections, then now is the time to speak up. What I believe we have not discussed, is the profiling or parameterization = of the behavior required from master device in that regulatory domain (whic= h would be sent from DB to master in either message 2 or 4 above). Ie, is i= t ok if the DB tells the master, that eg, the rules as defined in 'Ofcom-20= 12' or 'FCC-2013' are applicable (profiling), or should the behavior requir= ed by the rules be broken down into parameters and parameters defined in th= e registry (parameterization)? Profiling means that the master can only operate in one particular regulato= ry domain, if it is preconfigured with the profile applicable to that regul= atory domain; Parameterization means that we have to identify the exhaustive list of para= meters which describe the behaviours; which is a bit more work than the pro= filing. Any opinions on this? Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0614008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One main discussion po= int in the f2f was future extensibility, for the cases when regulators deci= de to require additional parameters from master devices; another discussion= point was what parameters would the master initially, eg after the first power up, send to the DB.<= /span>

 

The suggestion was to = extend the INIT procedure from a one round trip to a two round trips, where= the first request from master would either be responded as already describ= ed in the draft, or the DB would respond with a message indicating additional required parameters, after which the = master would resend the request with the indicated parameters.

 

I believe this functio= nality could be supported by the currently defined one round trip INIT proc= edure as well, once the error handling is added to the document:=

1.&n= bsp;      Master sends I= NIT request to the server, including at least its location

2.&n= bsp;      DB would respo= nd with an error message, indicating the missing parameters

3.&n= bsp;      Master sends a= new INIT request, including all the required parameters<= /p>

4.&n= bsp;      DB sends to ma= ster the regulatory domain, parameter values and required behavior from mas= ter in this regulatory domain

 

Am I missing sg?<= /o:p>

 

There was also another= suggestion on having the parameters which could be carried in message 2 ab= ove be defined and put in the IANA registry. That way, the DB can easily po= int the master to which parameter it requires from it, possibly avoiding the need for a firmware update in the = master (but still having the need for an admin to configure the required ne= w parameter). And with the parameters in the registry, there would be no ne= ed to do per regulatory domain profiling of the required parameters.

 

I would like to confir= m if this path forward is ok with folks; if you have objections, then now i= s the time to speak up.

 

What I believe we have= not discussed, is the profiling or parameterization of the behavior requir= ed from master device in that regulatory domain (which would be sent from D= B to master in either message 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, the rules as def= ined in ‘Ofcom-2012’ or ‘FCC-2013’ are applicable (= profiling), or should the behavior required by the rules be broken down int= o parameters and parameters defined in the registry (parameterization)?

Profiling means that t= he master can only operate in one particular regulatory domain, if it is pr= econfigured with the profile applicable to that regulatory domain;

Parameterization means= that we have to identify the exhaustive list of parameters which describe = the behaviours; which is a bit more work than the profiling.

Any opinions on this?<= o:p>

 

Thanks, Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0614008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Tue Dec 4 12:15:23 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8721F8767 for ; Tue, 4 Dec 2012 12:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCJDrFpGeyug for ; Tue, 4 Dec 2012 12:15:22 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E40B521F85E8 for ; Tue, 4 Dec 2012 12:15:21 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB4KFKt4028351 for ; Tue, 4 Dec 2012 22:15:20 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 22:15:19 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0318.003; Tue, 4 Dec 2012 20:15:19 +0000 From: To: Thread-Topic: Outcome of the Atlanta F2F - security Thread-Index: Ac3SWf7qIT/BF4UXT0CRURopdZF7zA== Date: Tue, 4 Dec 2012 20:15:18 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0644@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: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0644008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 20:15:19.0809 (UTC) FILETIME=[1532D710:01CDD25C] X-Nokia-AV: Clean Subject: [paws] Outcome of the Atlanta F2F - security 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, 04 Dec 2012 20:15:23 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0644008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding security, there was agreement that the security protocol between = the master and the DB is going to protect the DB resources and not the radi= o spectrum. Ie, we are not going to design a protocol to prevent malicious = use of the WS spectrum; devices can put energy in the air and cause interfe= rence without asking the DB. Since the Use cases and Requirements document is also going to be soon revi= sed, I would propose that we capture the scope of the security in there too= , and get rid of threats 3, 5 and first part of threat 4. Does anybody have any issues with the above? In the solution document, security section, we need input to address the re= st of the threats described in the use case and requirements document. Yang= Cui volunteered in the f2f to provide some text, hopefully we'll see sg so= on. Anybody else interested in this topic is also welcome to contribute. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0644008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding security, th= ere was agreement that the security protocol between the master and the DB = is going to protect the DB resources and not the radio spectrum. Ie, we are= not going to design a protocol to prevent malicious use of the WS spectrum; devices can put energy in the air and ca= use interference without asking the DB.

 

Since the Use cases an= d Requirements document is also going to be soon revised, I would propose t= hat we capture the scope of the security in there too, and get rid of threa= ts 3, 5 and first part of threat 4.

 

Does anybody have any = issues with the above?

 

In the solution docume= nt, security section, we need input to address the rest of the threats desc= ribed in the use case and requirements document. Yang Cui volunteered in th= e f2f to provide some text, hopefully we’ll see sg soon. Anybody else interested in this topic is also wel= come to contribute.

 

-&nb= sp;         Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0644008AM1MPN1007mg_-- From Gabor.Bajko@nokia.com Tue Dec 4 12:21:10 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 0B17521F8BA0 for ; Tue, 4 Dec 2012 12:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gNfqu3Cu7mj for ; Tue, 4 Dec 2012 12:21:09 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69721F8AA3 for ; Tue, 4 Dec 2012 12:21:08 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB4KL6Mw032552 for ; Tue, 4 Dec 2012 22:21:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Dec 2012 22:21:06 +0200 Received: from 008-AM1MPN1-007.mgdnok.nokia.com ([169.254.7.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0318.003; Tue, 4 Dec 2012 20:21:05 +0000 From: To: Thread-Topic: Outcome of the Atlanta F2F - DB Discovery Thread-Index: Ac3SXCBMoT+YS/P8TBmrhtCdBzxvWA== Date: Tue, 4 Dec 2012 20:21:05 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0661@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: [24.23.137.91] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0661008AM1MPN1007mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2012 20:21:06.0698 (UTC) FILETIME=[E3F5E6A0:01CDD25C] X-Nokia-AV: Clean Subject: [paws] Outcome of the Atlanta F2F - DB Discovery 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, 04 Dec 2012 20:21:10 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0661008AM1MPN1007mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding DB Discovery, we had no input or discussion in Atlanta, other tha= n if there's not going to be any input by the next meeting, then we'll just= have to say that the DB address is not discovered, it is preconfigured in = the master device. We still have an active draft describing discovery, see http://datatracker.= ietf.org/doc/draft-probasco-paws-discovery, but the author is not intereste= d in progressing it further. Anybody interested in this topic, please submit an I-D, or provide text whi= ch can be included into the solution document. - Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0661008AM1MPN1007mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding DB Discovery= , we had no input or discussion in Atlanta, other than if there’s not= going to be any input by the next meeting, then we’ll just have to s= ay that the DB address is not discovered, it is preconfigured in the master device.

 

We still have an activ= e draft describing discovery, see h= ttp://datatracker.ietf.org/doc/draft-probasco-paws-discovery, but the a= uthor is not interested in progressing it further.

 

Anybody interested in = this topic, please submit an I-D, or provide text which can be included int= o the solution document.

 

-&nb= sp;         Gabor

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020B0661008AM1MPN1007mg_-- From weixinpeng@huawei.com Tue Dec 4 17:58:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FDF21F8A87 for ; Tue, 4 Dec 2012 17:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU8CQXSQxKVJ for ; Tue, 4 Dec 2012 17:58:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28A21F8A73 for ; Tue, 4 Dec 2012 17:58:07 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANM44211; Wed, 05 Dec 2012 01:58:04 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 01:56:29 +0000 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 01:56:55 +0000 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.206]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 09:56:48 +0800 From: Weixinpeng To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: Outcome of the Atlanta F2F - DB Discovery Thread-Index: Ac3SXCBMoT+YS/P8TBmrhtCdBzxvWAALrzYw Date: Wed, 5 Dec 2012 01:56:47 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0661@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0661@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43BF4C6B8SZXEML519MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] Outcome of the Atlanta F2F - DB Discovery 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, 05 Dec 2012 01:58:09 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43BF4C6B8SZXEML519MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the topic of DB discovery, I think I can do some more work to f= inish a new draft before the next f2f meeting. If anyone has interests in this topic, maybe we can cooperate for = it. From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gab= or.Bajko@nokia.com Sent: Wednesday, December 05, 2012 4:21 AM To: paws@ietf.org Subject: [paws] Outcome of the Atlanta F2F - DB Discovery Regarding DB Discovery, we had no input or discussion in Atlanta, other tha= n if there's not going to be any input by the next meeting, then we'll just= have to say that the DB address is not discovered, it is preconfigured in = the master device. We still have an active draft describing discovery, see http://datatracker.= ietf.org/doc/draft-probasco-paws-discovery, but the author is not intereste= d in progressing it further. Anybody interested in this topic, please submit an I-D, or provide text whi= ch can be included into the solution document. - Gabor --_000_C5C3BB522B1DDF478AA09545169155B43BF4C6B8SZXEML519MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

         To the topic of = DB discovery, I think I can do some more work to finish a new draft before = the next f2f meeting.

         If anyone has in= terests in this topic, maybe we can cooperate for it.

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com
Sent: Wednesday, December 05, 2012 4:21 AM
To: paws@ietf.org
Subject: [paws] Outcome of the Atlanta F2F - DB Discovery=

 

Regardi= ng DB Discovery, we had no input or discussion in Atlanta, other than if th= ere’s not going to be any input by the next meeting, then we’ll= just have to say that the DB address is not discovered, it is preconfigured in the master device.

&n= bsp;

We stil= l have an active draft describing discovery, see h= ttp://datatracker.ietf.org/doc/draft-probasco-paws-discovery, but the a= uthor is not interested in progressing it further.

&n= bsp;

Anybody= interested in this topic, please submit an I-D, or provide text which can = be included into the solution document.

&n= bsp;

= -          Gabor

--_000_C5C3BB522B1DDF478AA09545169155B43BF4C6B8SZXEML519MBXchi_-- From lei.zhu@huawei.com Tue Dec 4 18:00: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 CF37721F8A87 for ; Tue, 4 Dec 2012 18:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjNJujpsPYAz for ; Tue, 4 Dec 2012 18:00:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7CD21F8A73 for ; Tue, 4 Dec 2012 18:00:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AME43797; Wed, 05 Dec 2012 02:00:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 01:59:21 +0000 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 5 Dec 2012 01:59:48 +0000 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.99]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.003; Wed, 5 Dec 2012 09:59:40 +0800 From: Zhulei To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: Outcome of the Atlanta F2F - DB Discovery Thread-Index: Ac3SXCBMoT+YS/P8TBmrhtCdBzxvWAAL74ig Date: Wed, 5 Dec 2012 01:59:39 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE62524B01CD6@szxeml504-mbx.china.huawei.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0661@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0661@008-AM1MPN1-007.mgdnok.nokia.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.65.68] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE62524B01CD6szxeml504mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] Outcome of the Atlanta F2F - DB Discovery 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, 05 Dec 2012 02:00:05 -0000 --_000_470F27D1263A1B4EB73491ED995DE62524B01CD6szxeml504mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgR2Fib3IsDQoNCkkgdGhvdWdodCB0aGF0IHdlIGNhbiBzZWUgc29tZSBpbnB1dCBvbiBEQiBk aXNjb3ZlcnksIGFzIHdoaWxlIEkgZGlkIG5vdCBkaXNjYXJkIHRoZSBvcHRpb24gdG8gaGF2ZSBz b21lIHByZS1kZWZpbmVkIGNvbmZpZ3VyYXRpb24uDQoNCkJlc3QgcmVnYXJkcywNClpodSBMZWkN CreivP7IyzogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIEdhYm9yLkJhamtvQG5va2lhLmNvbQ0Kt6LLzcqxvOQ6IDIwMTLE6jEy1MI1yNUg NDoyMQ0KytW8/sjLOiBwYXdzQGlldGYub3JnDQrW98ziOiBbcGF3c10gT3V0Y29tZSBvZiB0aGUg QXRsYW50YSBGMkYgLSBEQiBEaXNjb3ZlcnkNCg0KUmVnYXJkaW5nIERCIERpc2NvdmVyeSwgd2Ug aGFkIG5vIGlucHV0IG9yIGRpc2N1c3Npb24gaW4gQXRsYW50YSwgb3RoZXIgdGhhbiBpZiB0aGVy ZaGvcyBub3QgZ29pbmcgdG8gYmUgYW55IGlucHV0IGJ5IHRoZSBuZXh0IG1lZXRpbmcsIHRoZW4g d2Whr2xsIGp1c3QgaGF2ZSB0byBzYXkgdGhhdCB0aGUgREIgYWRkcmVzcyBpcyBub3QgZGlzY292 ZXJlZCwgaXQgaXMgcHJlY29uZmlndXJlZCBpbiB0aGUgbWFzdGVyIGRldmljZS4NCg0KV2Ugc3Rp bGwgaGF2ZSBhbiBhY3RpdmUgZHJhZnQgZGVzY3JpYmluZyBkaXNjb3ZlcnksIHNlZSBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXByb2Jhc2NvLXBhd3MtZGlzY292ZXJ5LCBi dXQgdGhlIGF1dGhvciBpcyBub3QgaW50ZXJlc3RlZCBpbiBwcm9ncmVzc2luZyBpdCBmdXJ0aGVy Lg0KDQpBbnlib2R5IGludGVyZXN0ZWQgaW4gdGhpcyB0b3BpYywgcGxlYXNlIHN1Ym1pdCBhbiBJ LUQsIG9yIHByb3ZpZGUgdGV4dCB3aGljaCBjYW4gYmUgaW5jbHVkZWQgaW50byB0aGUgc29sdXRp b24gZG9jdW1lbnQuDQoNCg0KLSAgICAgICAgR2Fib3INCg== --_000_470F27D1263A1B4EB73491ED995DE62524B01CD6szxeml504mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Gabor,

 

I thought that we can see some input on DB discovery, as while I = did not discard the option to have some pre-defined configuration.

 

Best regards,

Zhu Lei

=B7=A2=BC=FE=C8=CB: paws-bounces@ietf.org= [mailto:paws-bounces@ietf.org] =B4=FA=B1=ED = Gabor.Bajko@nokia.com
=B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA12=D4=C2= 5=C8=D5 4:21
=CA=D5=BC=FE=C8=CB: paws@ietf.org
=D6=F7=CC=E2: [paws] Outcome of the Atlanta F2F - DB Discovery=

 

Regardi= ng DB Discovery, we had no input or discussion in Atlanta, other than if th= ere=A1=AFs not going to be any input by the next meeting, then we=A1=AFll j= ust have to say that the DB address is not discovered, it is preconfigured in the master device.

&n= bsp;

We stil= l have an active draft describing discovery, see h= ttp://datatracker.ietf.org/doc/draft-probasco-paws-discovery, but the a= uthor is not interested in progressing it further.

&n= bsp;

Anybody= interested in this topic, please submit an I-D, or provide text which can = be included into the solution document.

&n= bsp;

= -        Gabor

--_000_470F27D1263A1B4EB73491ED995DE62524B01CD6szxeml504mbxchi_-- From internet-drafts@ietf.org Mon Dec 17 17:56:28 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602AE21E803D; Mon, 17 Dec 2012 17:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8xCknoSMVwy; Mon, 17 Dec 2012 17:56:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA01311E809A; Mon, 17 Dec 2012 17:56:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121218015623.6381.28068.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 17:56:23 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-01.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: Tue, 18 Dec 2012 01:56:28 -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 Spectrum Database Author(s) : Vincent Chen Subir Das Zhu Lei John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-01.txt Pages : 72 Date : 2012-12-17 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vchen@google.com Mon Dec 17 18:02:08 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A3511E809C for ; Mon, 17 Dec 2012 18:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWNZou54ZiXz for ; Mon, 17 Dec 2012 18:02:04 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5289221F8A52 for ; Mon, 17 Dec 2012 18:02:04 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so29474wgb.29 for ; Mon, 17 Dec 2012 18:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pwyo+6gqGBLdnOKdmY/CoD0LDkL/hZkPJ/Tlz8Pt/DA=; b=RJqXuL79sCiRyflVVAAKmDRtdvMVfvRMZRa4ZvXQlZeA+JTZ8bqLMtPlRouPatTJvw vPaCK+V28LobbFbVQN3TCqmdMkjMg3AxmNfOwoJxInXv6J3li2Ykboic7/SabueVujhM /mFDFNoRSMmUIkOMZ6g6msdq4b42X554d+Ju6INHBY1aUIeXd4CIpd2/8WLb3xnm/O+5 HMHW+ysBCcR9fQVadCx7im2iA/44adi/xV79oDm2O/l59D9Pv5o1ySyH43+uidFhWoE4 PyC3JJmPTOQgaMxJCWAG3RRNn7RI3AxW85Zg390kKYCpLI7yluMQBzlb6JtAwHj2h4y2 HR2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=pwyo+6gqGBLdnOKdmY/CoD0LDkL/hZkPJ/Tlz8Pt/DA=; b=FZo5F2Bl+6vibwXP5ED/gYCnf3z0Wgv5nbNAnZIwDT5uZpzTdvO7vdUVFTd1nms+yS 17Hr9M6bXq0D4lLtGCf0djQ77Tg0SPYlL/Et2JVNJ3d2TTdImm2NK575F04zuaJsI61m 4U28lHxVPlt2Z4YxkGywrsgJa0LlobXlyxX/mm576kYHFKvMQHjC2LxARlITzmUbkqB+ XnJe3mo3i9A8QUCwGNtTJEzTYhSur5M965DgyKDgavAhaut8aHYtpvwhZ1qdR/BYYuHX Vl3dSSWrmWiWU7tGeZo0Z2MUM3eW5eGzmmEqFataK5kZspvDs0YlmvOZCev15aa+ucNi sVcw== MIME-Version: 1.0 Received: by 10.194.88.98 with SMTP id bf2mr570570wjb.49.1355796123303; Mon, 17 Dec 2012 18:02:03 -0800 (PST) Received: by 10.194.77.110 with HTTP; Mon, 17 Dec 2012 18:02:03 -0800 (PST) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476020A6629@008-AM1MPN1-007.mgdnok.nokia.com> Date: Mon, 17 Dec 2012 18:02:03 -0800 Message-ID: From: Vincent Chen To: Gabor.Bajko@nokia.com Content-Type: multipart/alternative; boundary=089e010d825a513f8b04d116e228 X-Gm-Message-State: ALoCoQmLNFFw6aLxYr8lXiMBvZYh0DYT+5Cls0S6dnsm66avYSqyz6jJzJKDZU7BAFebL0p3nXMxTJjdc1wPHsK+ykjceIbdJqeyBcjdWKNgX5u/eHwzH0s2xY05ywT+aS4dM+6c0AkHlCkqxfz548QSadNIkBGnDN7+rQCFMWiKpRnMzsAGlzpkAUjhvOrL8blA6XIsOuMI Cc: paws@ietf.org Subject: Re: [paws] outcome of the Atlanta 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: Tue, 18 Dec 2012 02:02:09 -0000 --089e010d825a513f8b04d116e228 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, I have uploaded a new version of the draft that addresses the non-controversial open items: - Add JSON encoding using JSON-RPC formatted messages along with some examples. - Adopt RFC5491 for GeoLocation data model - Adopt vCard for the contact information data model - Add Response Code section - Change "DeviceIdentifier" to "DeviceDescriptor" to allow it to hold identifiers and device-characteristic fields - Moved regulatory-specifics out of the main body of the document -vince On Mon, Nov 26, 2012 at 12:35 PM, Vincent Chen wrote: > Gabor, > > On Mon, Nov 26, 2012 at 11:35 AM, wrote: > >> We had good technical discussions during our last F2F, with good >> proposals on how to close some of the open issues. I=92ll try to summari= ze >> the outcome in the next couple of emails, starting with the least >> controversial items:**** >> >> ** ** >> >> There were no objections against Vince=92s proposal to use ** ** >> >> ** ** >> >> JSON-RPC, as indicated in slides 7&8 of >> http://www.ietf.org/proceedings/85/slides/slides-85-paws-1.pptx**** >> >> Keeping the PAWS and HTTP layers separate and Indicating errors as >> proposed in slide 9 of >> http://www.ietf.org/proceedings/85/slides/slides-85-paws-1.pptx >> > > FYI. Because of the acceptance of JSON-RPC, slide 9 is not quite accurate= , > but the intent remains the same. The error codes would be returned > within JSON-RPC error messages. > > >> **** >> >> Use RFC5491 for geo-location encoding (someone needs to JSON encode it), >> instead of RFC6225, to support requirement D8.**** >> >> Use vCard encoding for the contact field (slide 18 of >> http://www.ietf.org/proceedings/85/slides/slides-85-paws-1.pptx )**** >> >> ** ** >> >> I=92d like to confirm these on the list. If you see any issues with the >> above, please notify the list asap.**** >> >> ** ** >> >> Thanks, Gabor**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> ** ** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > --089e010d825a513f8b04d116e228 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
A= ll,

I have uploaded a new version of the draft that addr= esses the non-controversial open items:

- Add JSON= encoding using JSON-RPC formatted messages along with some examples.
- Adopt RFC5491 for GeoLocation data model
- Adopt vCard for= the contact information data model
- Add Response Code section
- Change "DeviceIdentifier" to "DeviceDescriptor&qu= ot; to allow it to hold identifiers and device-characteristic fields
- Moved regulatory-specifics out of the main body of the document

-vince

On Mon, Nov 2= 6, 2012 at 12:35 PM, Vincent Chen <vchen@google.com> wrote:
Gabor,

On Mon, Nov 26, 2012 at 11:35 AM, <Gabor.Bajko@nokia.com> wrote:

We had good technical discussions during our last F2= F, with good proposals on how to close some of the open issues. I=92ll try = to summarize the outcome in the next couple of emails, starting with the le= ast controversial items:

=A0

There were no objections against Vince=92s proposal = to use

=A0

JSON-RPC, as indicated in slides 7&8 of http://www.ietf.org/proceedings/85/slides/slides-85-paws-1.pptx<= u>

Keeping the PAWS and HTTP layers separate and Indica= ting errors as proposed in slide 9 of http://www.ietf.org/proceedings/85/slides/slides-85-paws= -1.pptx


FYI. Beca= use of the acceptance of JSON-RPC, slide 9 is not quite accurate, but the i= ntent remains the same. The error codes would be returned
within JSON-RPC error messages.
=A0

Use RFC5491 for geo-location encoding (someone needs= to JSON encode it), instead of RFC6225, to support requirement D8.<= u>

Use vCard encoding for the contact field (slide 18 o= f http://www.ietf.org/proceedings/85/slides/slides-85-paws-1.pptx )

=A0

I=92d like to confirm these on the list. If you see = any issues with the above, please notify the list asap.

=A0

Thanks, Gabor

=A0

=A0

=A0

=A0

=A0


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


<= br clear=3D"all">

--
-vince

--089e010d825a513f8b04d116e228-- From internet-drafts@ietf.org Fri Dec 21 09:10: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 817D821F869B; Fri, 21 Dec 2012 09:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.412 X-Spam-Level: X-Spam-Status: No, score=-102.412 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umP1PyNIZrlh; Fri, 21 Dec 2012 09:10:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FE221F8814; Fri, 21 Dec 2012 09:10:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> Date: Fri, 21 Dec 2012 09:10:51 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.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, 21 Dec 2012 17:10:52 -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 (PAWS) Database: Use Case= s and Requirements Author(s) : Anthony Mancuso Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt Pages : 27 Date : 2012-12-21 Abstract: [Editor's Note: This version is submitted for review. A final, post- review version is anticipated that will supersede this version]. 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 white space spectrum at a given time and location is to verify spectrum availability with a database that manages spectrum sharing and provides spectrum-availability information. 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 white spaces is described along with 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 that stores information about spectrum 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nbravin@earthlink.net Fri Dec 21 09:58:16 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5534121F850C for ; Fri, 21 Dec 2012 09:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqFkdIKnS2qw for ; Fri, 21 Dec 2012 09:58:15 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6141721F8503 for ; Fri, 21 Dec 2012 09:58:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Im8Dm1B92OtJfs6mfXrIgs0KEa/QcOYaZV4CzXKa7AYEdT4H/wIUvOrifiAwwHJm; h=Received:From:Mime-Version:Content-Type:Subject:Date:References:Cc:To:Message-Id:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.8]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Tm6rN-0005I5-QT; Fri, 21 Dec 2012 12:58:13 -0500 From: Nancy Bravin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8323FD77-976C-441E-9470-5D30FD04F7C3" Date: Fri, 21 Dec 2012 09:58:12 -0800 References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> To: Gabor Bajko Message-Id: <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad866332e37088501d60873c14cb5a5314f3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.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, 21 Dec 2012 17:58:16 -0000 --Apple-Mail=_8323FD77-976C-441E-9470-5D30FD04F7C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii HI Gabor, I do not understand when doing a global standard, and only referring to = underserved areas, which is more common in developed countries,=20 why use cases are left out for not only rural, but remote, which happens = to involve many countries that can or do not relate to underserved,=20 implying that some use is already there.=20 The constant use of the term wifi, and no other technology or use cases = left out seems to promote one technology over others. This is not agnostic in my view, it is if all other efforts done or in = process globally are irrelevant. Combining use cases as was done is not in the best interests of the = market, their choices of what to use, or a global effort in = demographics,=20 whether population, terrain, or different regs that apply or options = that other countries can use to determine what is the best course for = their sovereign nation. Sorry to violently disagree, but even the device regs from the US are = ignored as stated before. Nancy Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [paws] I-D Action: = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt > Date: December 21, 2012 9:10:51 AM PST > To: i-d-announce@ietf.org > Cc: paws@ietf.org >=20 >=20 > 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. >=20 > Title : Protocol to Access White Space (PAWS) = Database: Use Cases and Requirements > Author(s) : Anthony Mancuso > Basavaraj Patil > Filename : = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt > Pages : 27 > Date : 2012-12-21 >=20 > Abstract: > [Editor's Note: This version is submitted for review. A final, = post- > review version is anticipated that will supersede this version]. >=20 > 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 white > space spectrum at a given time and location is to verify spectrum > availability with a database that manages spectrum sharing and > provides spectrum-availability information. >=20 > 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 white spaces is described > along with 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 that stores information about spectrum availability at any > given location and time. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqm= ts >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-09 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-r= qmts-09 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_8323FD77-976C-441E-9470-5D30FD04F7C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii HI = Gabor,

I do not understand when doing a global = standard, and only referring to underserved areas, which is more common = in developed countries, 
why use cases are left out for = not only rural, but remote, which happens to involve many countries that = can or do not relate to underserved, 
implying that some = use is already there. 
The constant use of the term wifi, = and no other technology or use cases left out seems to promote one = technology over others.
This is not agnostic in my view, it is = if all other efforts done or in process globally are = irrelevant.
Combining use cases as was done is not in the best = interests of the market, their choices of what to use, or a global = effort in demographics, 
whether population, terrain, or = different regs that apply or options that other countries can use to = determine what is the best course for their
sovereign = nation.

Sorry to violently disagree, but even = the device regs from the US are ignored as stated = before.

Nancy


Begin forwarded = message:

Subject: [paws] I-D Action: = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
Date: December 21, 2012 = 9:10:51 AM PST

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

Title =           : Protocol = to Access White Space (PAWS) Database: Use Cases and = Requirements
= Author(s)       : Anthony = Mancuso
=             &n= bsp;           &nbs= p;Basavaraj Patil
Filename =        : = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
Pages =           : = 27
= Date =            : = 2012-12-21

Abstract:
  [Editor's Note: This version = is submitted for review.  A final, post-
  review = version is anticipated that will supersede this version].

=   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 white
  space = spectrum at a given time and location is to verify spectrum
=   availability with a database that manages spectrum sharing = and
  provides spectrum-availability information.

=   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 white spaces is described
  along with 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 that stores information about = spectrum 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-rq= mts-09

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-use= cases-rqmts-09


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

= --Apple-Mail=_8323FD77-976C-441E-9470-5D30FD04F7C3-- From amancuso@google.com Fri Dec 21 10:39:27 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAF621F86FA for ; Fri, 21 Dec 2012 10:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkVlJUZuO2Im for ; Fri, 21 Dec 2012 10:39:26 -0800 (PST) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by ietfa.amsl.com (Postfix) with ESMTP id D694621F85FE for ; Fri, 21 Dec 2012 10:39:25 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id j13so5487443lah.41 for ; Fri, 21 Dec 2012 10:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=9JDvtJ5R6sewMASTwc0yMbqFe4cBo/mgkNjlZUoODL4=; b=KjPHQMY4nx4L5w7M6E89axWcEwWq0gdJ5qoRpk6alVBQIwXyQkYU8AkFxo311+vw9v JYahLJcbvEYRIHEkmlE/RfWthcBKLisnG72J6HWhv9C9KqjUPFQ9zklGWer+Q/6RlL5e 8Aro6xd6V2OOADUEGjh+iu9Ew7ZsATjNIvZhfO9VZ7AHF1/HZ1ySoU9AjJTwGR5LqcS1 3DiO1eoIIsAAmsUbc6E5HuyXm4Gwi1+lW0PzGaZLtT+mQn6zXnWqpbOP3l8GVgorBIOd R3fhRN4UPeG+srCQ+qfw8Gm4CufggMWTA81EBVGXFZGwpJ8vJb/XxydHVWuQQdcSMT5g DQIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=9JDvtJ5R6sewMASTwc0yMbqFe4cBo/mgkNjlZUoODL4=; b=prs9Mh7hEt1wCGuyVIIpMuqNEO4/C+wh37SVfQYTU3f6Ds71ZAG2lDX9nI2p29YBdj uIrgvPGzlf0asTzsyIEt1NxXCx20lLSlEuutg07yy7d7rx4eKCVOQzFtyPIROg8y7N/m PaHdMxfm4lifU0Hd2C4rVEf/cwPpKN6UeevwOaOJmHlo7b3TVrhmtgc4/3FNzrD2XOeR 1kPJFryB+3vcHOH+ub8kYChLIaqSgoiNUiOKnoJu7rZHji2lZ0rqMwixWP26pvHqI/aU xrz1hPiMr0Un66FF9JJzwWmZaqYAO4zkrpooNY1igmsgl9S7G/yfLK5h0g3cdNlgIk0R ZZ6A== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr13098431lab.23.1356115161298; Fri, 21 Dec 2012 10:39:21 -0800 (PST) Received: by 10.112.61.8 with HTTP; Fri, 21 Dec 2012 10:39:20 -0800 (PST) In-Reply-To: <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> Date: Fri, 21 Dec 2012 10:39:20 -0800 Message-ID: From: Anthony Mancuso To: paws@ietf.org Content-Type: multipart/alternative; boundary=f46d0407152976b6b004d1612a0b X-Gm-Message-State: ALoCoQml0Uf/ACB399mg2wzkl7hefNCUrHSEZMq5ixupdMf1clZ9MgXBYBUV+q9DQj4rJZOAb6EjwsjOWdqbEAFd+6a16OudT8IV/6zPyfy/qy1zi00Eyx0JAI43sWV8eDQkDWaIRC8n8t9JRI/PNwmigE8/bWfuXEbPAt6HGCpfadzJ5eYcw0m4YwINBg0ZtlDWMtxa3Nu7 Subject: Re: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.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, 21 Dec 2012 18:39:27 -0000 --f46d0407152976b6b004d1612a0b Content-Type: text/plain; charset=ISO-8859-1 PAWS list members, I just submitted a new version of the PAWS Use Cases & Requirements doc for review and discussion. The latest draft (v. 09): - incorporates the suggestions contained in the post by Pete Resnick, AD, which included, among other things, recommendation to coordinate architecturally-and protocol-common use cases - adds a new use case (local TV broadcast) - Deleted security threat 5 and added language to security considerations to match the protocol security considerations that have evolved in the WG - Clarified protocol normative requirement 6.3 to: "The protocol MUST support determination of regulatory domain governing its current location." - Cleaned up language and usage: consistent use of primary, secondary users changed "channel" availability references to "spectrum" availability where appropriate deleted references specific to TV band and generalized these to radio spectrum changed references to regulatory domain to rule set of regulatory domain as appropriate to clarify that the latter controls device behavior regardless of country (Brazil adopts US "FccWhitespace2010" rule set) cleaned up language and syntax throughout Thanks for any feedback, Tony Mancuso On Fri, Dec 21, 2012 at 9:58 AM, Nancy Bravin wrote: > HI Gabor, > > I do not understand when doing a global standard, and only referring to > underserved areas, which is more common in developed countries, > why use cases are left out for not only rural, but remote, which happens > to involve many countries that can or do not relate to underserved, > implying that some use is already there. > The constant use of the term wifi, and no other technology or use cases > left out seems to promote one technology over others. > This is not agnostic in my view, it is if all other efforts done or in > process globally are irrelevant. > Combining use cases as was done is not in the best interests of the > market, their choices of what to use, or a global effort in demographics, > whether population, terrain, or different regs that apply or options that > other countries can use to determine what is the best course for their > sovereign nation. > > Sorry to violently disagree, but even the device regs from the US are > ignored as stated before. > > Nancy > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **[paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt* > *Date: *December 21, 2012 9:10:51 AM PST > *To: *i-d-announce@ietf.org > *Cc: *paws@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol to Access WS database Working > Group of the IETF. > > Title : Protocol to Access White Space (PAWS) Database: Use > Cases and Requirements > Author(s) : Anthony Mancuso > Basavaraj Patil > Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt > Pages : 27 > Date : 2012-12-21 > > Abstract: > [Editor's Note: This version is submitted for review. A final, post- > review version is anticipated that will supersede this version]. > > 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 white > space spectrum at a given time and location is to verify spectrum > availability with a database that manages spectrum sharing and > provides spectrum-availability information. > > 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 white spaces is described > along with 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 that stores information about spectrum 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-09 > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases-rqmts-09 > > > 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 > > --f46d0407152976b6b004d1612a0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<= div dir=3D"ltr">
PAWS list members,
=

I just submitted a new version of the PAWS Use Cases & Requirement= s doc for review and discussion.=A0

The latest draft (v. 09):
  • incorporates the suggestions contained in the post by Pete = Resnick, AD, which included, among other things, recommendation to coordina= te architecturally-and protocol-common use cases
  • adds a new use case (local TV broadcast)=A0
  • Deleted= security threat 5 and added language to security considerations to match t= he protocol security considerations that have evolved in the WG
    • Clarified protocol normative requirement 6.3 to: "The protocol MUST su= pport determination of regulatory domain governing its current location.&qu= ot;
  • Cleaned up language and usage:
    consistent use of primary, secondary users
    changed "channel&= quot; availability references to "spectrum" availability where ap= propriate
    deleted references specific to TV band and generalized = these to radio spectrum
    changed references to regulatory domain to rule set of regulatory doma= in as appropriate to clarify that the latter controls device behavior regar= dless of country (Brazil adopts US "FccWhitespace2010" rule set)<= /div>
    cleaned up language and syntax throughout
<= div class=3D"gmail_default" style>Thanks for any feedback,

To= ny Mancuso


On Fri,= Dec 21, 2012 at 9:58 AM, Nancy Bravin <nbravin@earthlink.net><= /span> wrote:
HI Gabor= ,

I do not understand when doing a global standard, and = only referring to underserved areas, which is more common in developed coun= tries,=A0
why use cases are left out for not only rural, but remote, which happe= ns to involve many countries that can or do not relate to underserved,=A0
implying that some use is already there.=A0
The constant= use of the term wifi, and no other technology or use cases left out seems = to promote one technology over others.
This is not agnostic in my view, it is if all other efforts done or in= process globally are irrelevant.
Combining use cases as was done= is not in the best interests of the market, their choices of what to use, = or a global effort in demographics,=A0
whether population, terrain, or different regs that apply or options t= hat other countries can use to determine what is the best course for their<= /div>
sovereign nation.

Sorry to violently dis= agree, but even the device regs from the US are ignored as stated before.

Nancy


Begin forw= arded message:

Subject: [paws] I-D Action: draft-iet= f-paws-problem-stmt-usecases-rqmts-09.txt
Date: December 21, 2012 9:10:51 AM PST


A New Internet-Draft is av= ailable from the on-line Internet-Drafts directories.
This draft is a w= ork item of the Protocol to Access WS database Working Group of the IETF.
Title =A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0: Protocol to Access White Space (PAWS) Database: Use Cases and= Requirements
Author(s) =A0= =A0=A0=A0=A0=A0: Anthony Mancuso
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Basavaraj Patil
Filename= =A0=A0=A0=A0=A0=A0=A0: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt<= br> Pages =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: 27
Date =A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0: 2012-12-21

Abstract:
=A0=A0[Editor's Note: This v= ersion is submitted for review. =A0A final, post-
=A0=A0review version = is anticipated that will supersede this version].

=A0=A0Portions of the radio spectrum that are assigned to a particular= use
=A0=A0but are unused or unoccupied at specific locations and times= are
=A0=A0defined as "white space." =A0The concept of allowi= ng additional
=A0=A0transmissions (which may or may not be licensed) in white space is a=
=A0=A0technique to "unlock" existing spectrum for new use. = =A0An obvious
=A0=A0requirement is that these additional transmissions = do not interfere
=A0=A0with the assigned use of the spectrum. =A0One approach to using whit= e
=A0=A0space spectrum at a given time and location is to verify spectr= um
=A0=A0availability with a database that manages spectrum sharing and=
=A0=A0provides spectrum-availability information.

=A0=A0This document describes a number of possible use cases of white = space
=A0=A0spectrum and technology as well as a set of requirements fo= r the
=A0=A0database query protocol. =A0The concept of white spaces is = described
=A0=A0along with the problems that need to be addressed to enable white =A0=A0space spectrum for additional uses without causing interference to<= br> =A0=A0currently assigned use. =A0Use of white space is enabled by query= ing a
=A0=A0database that stores information about spectrum availabilit= y at any
=A0=A0given location and time.



The IETF datatracker status = page for this draft is:
https://datatrac= ker.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-usecase= s-rqmts-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-probl= em-stmt-usecases-rqmts-09


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

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


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


--f46d0407152976b6b004d1612a0b-- From nbravin@earthlink.net Sat Dec 22 10:23:20 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 3DF5521F8A7C for ; Sat, 22 Dec 2012 10:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKi7S6XNaqpm for ; Sat, 22 Dec 2012 10:23:19 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCF521F8A78 for ; Sat, 22 Dec 2012 10:23:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XXPEs3ZRTPXnfNOCYj0MOqc/xYXNNMsnePW1eBChYtz2j7FQ52AdbXPM0GpJnW6E; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.8]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TmTjA-0002ua-9h; Sat, 22 Dec 2012 13:23:16 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D5829567-C83F-4A1C-B9B8-77C0D0541987" From: Nancy Bravin In-Reply-To: <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> Date: Sat, 22 Dec 2012 10:23:15 -0800 Message-Id: <7C938017-B27D-4EF5-AC06-F167276EDB3A@earthlink.net> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> To: Anthony Mancuso , Gabor Bajko X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86b6092928daf69e160ae44e2703ba304d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.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: Sat, 22 Dec 2012 18:23:20 -0000 --Apple-Mail=_D5829567-C83F-4A1C-B9B8-77C0D0541987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you Anthony for your insight off line as to my concerns. I = apologize for my comments, and feel more comfortable that my concerns have been managed well in the current draft.=20 Sincerely,=20 Nancy Bravin On Dec 21, 2012, at 9:58 AM, Nancy Bravin wrote: > HI Gabor, >=20 > I do not understand when doing a global standard, and only referring = to underserved areas, which is more common in developed countries,=20 > why use cases are left out for not only rural, but remote, which = happens to involve many countries that can or do not relate to = underserved,=20 > implying that some use is already there.=20 > The constant use of the term wifi, and no other technology or use = cases left out seems to promote one technology over others. > This is not agnostic in my view, it is if all other efforts done or in = process globally are irrelevant. > Combining use cases as was done is not in the best interests of the = market, their choices of what to use, or a global effort in = demographics,=20 > whether population, terrain, or different regs that apply or options = that other countries can use to determine what is the best course for = their > sovereign nation. >=20 > Sorry to violently disagree, but even the device regs from the US are = ignored as stated before. >=20 > Nancy >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: [paws] I-D Action: = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt >> Date: December 21, 2012 9:10:51 AM PST >> To: i-d-announce@ietf.org >> Cc: paws@ietf.org >>=20 >>=20 >> 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. >>=20 >> Title : Protocol to Access White Space (PAWS) = Database: Use Cases and Requirements >> Author(s) : Anthony Mancuso >> Basavaraj Patil >> Filename : = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt >> Pages : 27 >> Date : 2012-12-21 >>=20 >> Abstract: >> [Editor's Note: This version is submitted for review. A final, = post- >> review version is anticipated that will supersede this version]. >>=20 >> 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 white >> space spectrum at a given time and location is to verify spectrum >> availability with a database that manages spectrum sharing and >> provides spectrum-availability information. >>=20 >> 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 white spaces is described >> along with 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 that stores information about spectrum availability at any >> given location and time. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqm= ts >>=20 >> There's also a htmlized version available at: >> = http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-09 >>=20 >> A diff from the previous version is available at: >> = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-r= qmts-09 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 --Apple-Mail=_D5829567-C83F-4A1C-B9B8-77C0D0541987 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thank = you Anthony for your insight off line as to my concerns. I apologize for = my comments, and feel more comfortable that
my concerns have been = managed well in the current = draft. 

Sincerely, 
Nancy = Bravin

On Dec 21, 2012, at 9:58 AM, Nancy = Bravin wrote:

HI = Gabor,

I do not understand when doing a global = standard, and only referring to underserved areas, which is more common = in developed countries, 
why use cases are left out for = not only rural, but remote, which happens to involve many countries that = can or do not relate to underserved, 
implying that some = use is already there. 
The constant use of the term wifi, = and no other technology or use cases left out seems to promote one = technology over others.
This is not agnostic in my view, it is = if all other efforts done or in process globally are = irrelevant.
Combining use cases as was done is not in the best = interests of the market, their choices of what to use, or a global = effort in demographics, 
whether population, terrain, or = different regs that apply or options that other countries can use to = determine what is the best course for their
sovereign = nation.

Sorry to violently disagree, but even = the device regs from the US are ignored as stated = before.

Nancy


Begin forwarded = message:

Subject: [paws] I-D Action: = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
Date: December 21, 2012 = 9:10:51 AM PST

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

Title =           : Protocol = to Access White Space (PAWS) Database: Use Cases and = Requirements
= Author(s)       : Anthony = Mancuso
=             &n= bsp;           &nbs= p;Basavaraj Patil
Filename =        : = draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
Pages =           : = 27
= Date =            : = 2012-12-21

Abstract:
  [Editor's Note: This version = is submitted for review.  A final, post-
  review = version is anticipated that will supersede this version].

=   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 white
  space = spectrum at a given time and location is to verify spectrum
=   availability with a database that manages spectrum sharing = and
  provides spectrum-availability information.

=   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 white spaces is described
  along with 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 that stores information about = spectrum 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-09

A diff from the previous version is available = at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-use= cases-rqmts-09


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


= = --Apple-Mail=_D5829567-C83F-4A1C-B9B8-77C0D0541987--