From presnick@qti.qualcomm.com Wed Jan 2 17:02:47 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42F421F8831 for ; Wed, 2 Jan 2013 17:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k7tURdGy23aP for ; Wed, 2 Jan 2013 17:02:47 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id E8B9221F8825 for ; Wed, 2 Jan 2013 17:02:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1357173213; x=1388709213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=4l3xPIi9VEJDjUoeGI/sRAd2GW7o6wxGB65ZTNujUJo=; b=JTcvdgpIS0WtbJCGWkJOA9EL7ZMUsPGaJlyo8dkiemSF9Ni5Ps9j1gzE pHOSnpO090FUNntC+Uojr5fqP97qjYEXqLcAkSQ2aLczvfIK3qFPRUAwM pWt04XMF6SwTTEd2SKBxSOVfRuB8ReGZjLubox/jthepevDY7gStc+pHa U=; X-IronPort-AV: E=Sophos;i="4.84,400,1355126400"; d="scan'208,217";a="14345531" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 02 Jan 2013 16:33:32 -0800 X-IronPort-AV: E=Sophos;i="4.84,398,1355126400"; d="scan'208,217";a="455133594" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 02 Jan 2013 17:02:45 -0800 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 2 Jan 2013 17:02:45 -0800 Message-ID: <50E4D8B8.808@qti.qualcomm.com> Date: Wed, 2 Jan 2013 19:02:48 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Anthony Mancuso References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040701090706020507070903" X-Originating-IP: [172.30.48.1] Cc: paws@ietf.org 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: Thu, 03 Jan 2013 01:02:47 -0000 --------------040701090706020507070903 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Tony, Thanks for the new version. At first glance, it looks like a good edit. I'll do a thorough review once the WG confirms that this one is good to go. Chairs, let me know when this has had enough review. I'd especially like to hear from folks like Peter Stanforth and others who had concerns that my suggestions might have removed too much from the document. Does this version satisfy everyone? Thanks for giving this a go, and a happy new year to everyone. pr On 12/21/12 12:39 PM, Anthony Mancuso wrote: > 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 > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040701090706020507070903 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Tony,

Thanks for the new version. At first glance, it looks like a good edit. I'll do a thorough review once the WG confirms that this one is good to go.

Chairs, let me know when this has had enough review. I'd especially like to hear from folks like Peter Stanforth and others who had concerns that my suggestions might have removed too much from the document. Does this version satisfy everyone?

Thanks for giving this a go, and a happy new year to everyone.

pr

On 12/21/12 12:39 PM, Anthony Mancuso wrote:
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


-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040701090706020507070903-- From Gabor.Bajko@nokia.com Tue Jan 8 13:58:12 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB011E80F4 for ; Tue, 8 Jan 2013 13:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 zAz5PBPStUH4 for ; Tue, 8 Jan 2013 13:58:10 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 925EE21F84BC for ; Tue, 8 Jan 2013 13:58:08 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r08LvfvT020200; Tue, 8 Jan 2013 23:58:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Jan 2013 23:57:51 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.102]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0318.003; Tue, 8 Jan 2013 21:57:51 +0000 From: To: , Thread-Topic: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt Thread-Index: AQHN6U4T8w9gKf2+EE2jIUDmtworgJhAAYZg Date: Tue, 8 Jan 2013 21:57:50 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7@008-AM1MPN1-006.mgdnok.nokia.com> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> <50E4D8B8.808@qti.qualcomm.com> In-Reply-To: <50E4D8B8.808@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.33.173] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jan 2013 21:57:51.0719 (UTC) FILETIME=[347B0F70:01CDEDEB] X-Nokia-AV: Clean Cc: paws@ietf.org 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: Tue, 08 Jan 2013 21:58:12 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Tony for generating this new version of the document. The overlappin= g use cases have been merged, a new use case has been added and the languag= e was cleaned up throughout the document. I would like to ask people to review it and send to the list any issues. So= far we got feedback from Nancy (thanks!), this new revision captures her c= omments. But I would like to hear from others as well, before we ask the AD= to review it again. It only takes 10-15min to review. If we do not hear any concerns or objections from anyone until next Monday = (Jan 14th), we'll assume the group is fine with the document and we'll ask = for the AD review. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Pete Resnick Sent: Wednesday, January 02, 2013 5:03 PM To: Anthony Mancuso Cc: paws@ietf.org Subject: Re: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-= rqmts-09.txt Tony, Thanks for the new version. At first glance, it looks like a good edit. I'l= l do a thorough review once the WG confirms that this one is good to go. Chairs, let me know when this has had enough review. I'd especially like to= hear from folks like Peter Stanforth and others who had concerns that my s= uggestions might have removed too much from the document. Does this version= satisfy everyone? Thanks for giving this a go, and a happy new year to everyone. pr On 12/21/12 12:39 PM, Anthony Mancuso wrote: 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, A= D, which included, among other things, recommendation to coordinate archite= cturally-and protocol-common use cases * adds a new use case (local TV broadcast) * Deleted security threat 5 and added language to security consideratio= ns to match the protocol security considerations that have evolved in the W= G * Clarified protocol normative requirement 6.3 to: "The protocol MUST s= upport 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 spect= rum 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 -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Tony for generatin= g this new version of the document. The overlapping use cases have been mer= ged, a new use case has been added and the language was cleaned up throughout the document.

I would like to ask peopl= e to review it and send to the list any issues. So far we got feedback from= Nancy (thanks!), this new revision captures her comments. But I would like to hear from others as well, before we ask the AD to revi= ew it again. It only takes 10-15min to review.

If we do not hear any con= cerns or objections from anyone until next Monday (Jan 14th), we= ’ll assume the group is fine with the document and we’ll ask for the AD review.

 <= /p>

Thanks, Gabor<= /span>

 <= /p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of ext Pete Resnick
Sent: Wednesday, January 02, 2013 5:03 PM
To: Anthony Mancuso
Cc: paws@ietf.org
Subject: Re: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-us= ecases-rqmts-09.txt

 

Tony,

Thanks for the new version. At first glance, it looks like a good edit. I'l= l do a thorough review once the WG confirms that this one is good to go.
Chairs, let me know when this has had enough review. I'd especially like to= hear from folks like Peter Stanforth and others who had concerns that my s= uggestions might have removed too much from the document. Does this version= satisfy everyone?

Thanks for giving this a go, and a happy new year to everyone.

pr

On 12/21/12 12:39 PM, Anthony Mancuso wrote:

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, whi= ch included, among other things, recommendation to coordinate architectural= ly-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 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" availability references to "spectrum"= availability where appropriate

deleted references specific to TV band and generalized these to radio spect= rum

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)<= /o:p>

cleaned up language and syntax throughout

Thanks for any feedback,

 

Tony Mancuso

 



-- 
Pete Resnick <http:/=
/www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Tue Jan 8 14:02:40 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF90621F853C for ; Tue, 8 Jan 2013 14:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 yPygIdN7M7Oq for ; Tue, 8 Jan 2013 14:02:36 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 22B1221F853A for ; Tue, 8 Jan 2013 14:02:35 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r08M2YsQ012609 for ; Wed, 9 Jan 2013 00:02:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Jan 2013 00:02:33 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.102]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0318.003; Tue, 8 Jan 2013 22:02:33 +0000 From: To: Thread-Topic: outcome of the Atlanta F2F -2- Thread-Index: Ac3SVSmgSndUu+IiSRC/8/gHAvYpvQblkI0A Date: Tue, 8 Jan 2013 22:02:32 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> In-Reply-To: <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: [10.163.33.173] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jan 2013 22:02:33.0671 (UTC) FILETIME=[DC898570:01CDEDEB] X-Nokia-AV: Clean Subject: Re: [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, 08 Jan 2013 22:02:40 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am re-sending this email, as I got no feedback on my questions in it. The responses to the questions below would significantly influence the solu= tion design, so I'd like to hear some feedback. Is there anybody who cares = about it? - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Baj= ko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, December 04, 2012 11:57 AM To: paws@ietf.org Subject: [paws] outcome of the Atlanta F2F -2- 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_1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am re-sending this e= mail, as I got no feedback on my questions in it.

The responses to the q= uestions below would significantly influence the solution design, so I̵= 7;d like to hear some feedback. Is there anybody who cares about it?

 

-&nb= sp;         Gabor

 

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, December 04, 2012 11:57 AM
To: paws@ietf.org
Subject: [paws] outcome of the Atlanta F2F -2-

 

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_1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B008AM1MPN1006mg_-- From warren@kumari.net Tue Jan 8 15:17:06 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68441F0CFA for ; Tue, 8 Jan 2013 15:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 OeRAeRj31OcX for ; Tue, 8 Jan 2013 15:17:05 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DA021F84D5 for ; Tue, 8 Jan 2013 15:17:05 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id BF5061B40460; Tue, 8 Jan 2013 18:16:58 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 8 Jan 2013 18:16:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> To: gabor.bajko@nokia.com X-Mailer: Apple Mail (2.1499) Cc: paws@ietf.org Subject: Re: [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, 08 Jan 2013 23:17:06 -0000 On Jan 8, 2013, at 5:02 PM, gabor.bajko@nokia.com wrote: > I am re-sending this email, as I got no feedback on my questions in = it. Apologies. This got lost in a mailbox... > The responses to the questions below would significantly influence the = solution design, so I=92d like to hear some feedback. Is there anybody = who cares about it? I don't care deeply, but have *some* opinions... > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: Tuesday, December 04, 2012 11:57 AM > To: paws@ietf.org > Subject: [paws] outcome of the Atlanta F2F -2- > =20 > One main discussion point in the f2f was future extensibility, for the = cases when regulators decide 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. > =20 > 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 described 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. > =20 > I believe this functionality could be supported by the currently = defined one round trip INIT procedure as well, once the error handling = is added to the document: > 1. Master sends INIT request to the server, including at least = its location > 2. DB would respond with an error message, indicating the = missing parameters > 3. Master sends a new INIT request, including all the required = parameters > 4. DB sends to master the regulatory domain, parameter values = and required behavior from master in this regulatory domain > =20 > Am I missing sg? Only some clarifications: I thing that 2 is actually: If the Master included all parameters that = the DB needed, things proceed normally. If there are parameters that the = DB needs, then "DB would respond with an error message, indicating the = missing parameters". Also, if the DB requests that the Master send Color_of_Unicorn and the = Master doesn't know this, what happens? What if this is simply something = the DB would *like* to know, but is OK proceeding without it? > =20 > There was also another suggestion on having the parameters which could = be carried 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 regulatory domain profiling of the required = parameters. Yup. This sounds good -- I don't really think that avoiding firmware = updates are likely, but a registry would defiantly make it easier to = track allocation of code points, etc. Much simpler to instruct the IANA = to assign something in a registry (possibly after RFC or stable = reference) than to keep obsoleting docs, following long chains of = drafts, etc... > =20 > 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. No objections... > =20 > What I believe we have not discussed, is the profiling or = parameterization of the behavior required from master device in that = regulatory domain (which would be sent from DB to master in either = message 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, = the rules as defined in =91Ofcom-2012=92 or =91FCC-2013=92 are = applicable (profiling), or should the behavior required by the rules be = broken down into parameters and parameters defined in the registry = (parameterization)? > Profiling means that the master can only operate in one particular = regulatory domain, if it is preconfigured 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? Yes=85 Parameterization is (IMO, etc) much much simpler.=20 Let's say that Ofcom-2012 requires "rules" A, B, C and J and that = FCC-2013 requires A, J, X, Y and Z. I have made a widget that works in both FCC and Ofcom worlds, so I know = about rules A - Z. In the future Ofcom decides that they also want to require / support = rules X and Y, so they make a new profile called "Ofcom-2020", which = requires A, B, C, J, X, Y. If we use profiles, until I roll upgrade all of my devices I won't know = what all is required in the Ofcom-2020 profile, *even though* I know = about all of the "rules" / parameters. If instead the DB simply says = "Please send me A, B, C, J, X, Y" I'm golden=85 W > =20 > Thanks, Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws -- It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 From vchen@google.com Tue Jan 8 23:28:31 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C351421F8799 for ; Tue, 8 Jan 2013 23:28:31 -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 sQL1Oj9OBb9Z for ; Tue, 8 Jan 2013 23:28:30 -0800 (PST) Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by ietfa.amsl.com (Postfix) with ESMTP id 1541521F877B for ; Tue, 8 Jan 2013 23:28:29 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t49so912068wey.14 for ; Tue, 08 Jan 2013 23:28:29 -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=fLurj2JqZeso+KF9JiW6nIxcIvWDzAe14q4h1+xxZC0=; b=bWdPu/SW3m51S7AkM2arz99MjDcFrG7UvjSH34EbHUyTNtZcS1Qacqe86fbnhQFbKc koYeeJ+yInz9q9/cAdZARk0JzGWBw8RmFrvGg0YlvnsF/9ymUs56kCw8J6Zj5ypyzp4n bL6jqEgQv9d6NrF7+u8L8aWDHs2wFWb4Ft78+y/Dj53Y+V2gphJQp+8K/A6WBrWGKVWr gYBm4Ugk3R9PvvFhvBPReKjVxh6GNcV+fEoivNnGy3S9nUPngHMyC0WJpzywmKojUpIi YqntSLAcee2F4Pu6sQc0v5+jnWGKPQ5gt2yGkzmvvWC0bCYVfnkd5beOGK9rtBl/50TC e9AA== 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=fLurj2JqZeso+KF9JiW6nIxcIvWDzAe14q4h1+xxZC0=; b=Cc3/VIlfvOmdC8wE8cLtjcp+ArmywjQfnu3hvzQczhcnovsnzgUofIuXduwkSkgMuT iVofZKdKbCF2adaf9eWAAT+sGQQkXMYcgEvxTbCbTIZ9KiSO8aC4mKeEBBpDQILC34te bunLQK+BovB1zYb6MEfLBxGaAh83COG3ZleOMfth0tpTIXiiBauBwPpfF4lg67RmZbmT IHw2KwArFpAVSzuRlUMOp3eb24KWZVOyleRqpWB6B7q62PvVEXACO8vF6h5YhvAbxW85 v9cVVJ3mvPJxn1sl6hGRP1X8LCXl4gDkQ9EbTP4164JRQadzHF33ygRpElJP8M6V2PPV bm1g== MIME-Version: 1.0 Received: by 10.180.73.80 with SMTP id j16mr1530251wiv.5.1357716509000; Tue, 08 Jan 2013 23:28:29 -0800 (PST) Received: by 10.194.16.36 with HTTP; Tue, 8 Jan 2013 23:28:28 -0800 (PST) In-Reply-To: <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> Date: Tue, 8 Jan 2013 23:28:28 -0800 Message-ID: From: Vincent Chen To: Warren Kumari Content-Type: multipart/alternative; boundary=f46d043bdf3839822004d2d60266 X-Gm-Message-State: ALoCoQlthrk0vnB8wTCb6TmuR0ZQZB/c3aY8L3jElt6P0Q4Co1i0//giNJtVvIDdqfr1CbrDTs6SSDtdNk/kpaf2pyyF+Igy3JeJKvFEmsEXFqcflFzLONSUBt8gGk1Qk1Fyrha8A75PNCy/PhKB5DfcNbtwiencL7BuBOxAJhQXQPoSGoTmoLrPpy35RFhEaM2v3iY3Ke4u Cc: "paws@ietf.org" Subject: Re: [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: Wed, 09 Jan 2013 07:28:31 -0000 --f46d043bdf3839822004d2d60266 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jan 8, 2013 at 3:16 PM, Warren Kumari wrote: > > On Jan 8, 2013, at 5:02 PM, gabor.bajko@nokia.com wrote: > > > I am re-sending this email, as I got no feedback on my questions in it. > > Apologies. This got lost in a mailbox... > > > The responses to the questions below would significantly influence the > solution design, so I=92d like to hear some feedback. Is there anybody wh= o > cares about it? > > I don't care deeply, but have *some* opinions... > > > > > - Gabor > > > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Bajko Gabor (Nokia-CIC/SiliconValley) > > Sent: Tuesday, December 04, 2012 11:57 AM > > To: paws@ietf.org > > Subject: [paws] outcome of the Atlanta F2F -2- > > > > One main discussion point in the f2f was future extensibility, for the > cases when regulators decide 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. > > > > The suggestion was to extend the INIT procedure from a one round trip t= o > a two round trips, where the first request from master would either be > responded as already described 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 functionality could be supported by the currently define= d > one round trip INIT procedure as well, once the error handling is added t= o > the document: > > 1. Master sends INIT request to the server, including at least it= s > location > > 2. DB would respond with an error message, indicating the missing > parameters > > 3. Master sends a new INIT request, including all the required > parameters > > 4. DB sends to master the regulatory domain, parameter values and > required behavior from master in this regulatory domain > > > > Am I missing sg? > > Only some clarifications: > I thing that 2 is actually: If the Master included all parameters that th= e > DB needed, things proceed normally. If there are parameters that the DB > needs, then "DB would respond with an error message, indicating the missi= ng > parameters". > Agreed. > > Also, if the DB requests that the Master send Color_of_Unicorn and the > Master doesn't know this, what happens? What if this is simply something > the DB would *like* to know, but is OK proceeding without it? > I think it the DB is OK proceeding without it, then it is not a "required" parameter, so it should just proceed to return the requested information. If it must know, and the Master doesn't know it, then the DB must still respond with an error. I don't think there is an inconsistency. > > > > > There was also another suggestion on having the parameters which could > be carried in message 2 above be defined and put in the IANA registry. Th= at > way, the DB can easily point the master to which parameter it requires fr= om > 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 ne= ed > to do per regulatory domain profiling of the required parameters. > > Yup. This sounds good -- I don't really think that avoiding firmware > updates are likely, but a registry would defiantly make it easier to trac= k > allocation of code points, etc. Much simpler to instruct the IANA to assi= gn > something in a registry (possibly after RFC or stable reference) than to > keep obsoleting docs, following long chains of drafts, etc... > > > > > > 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. > > No objections... > > > > > What I believe we have not discussed, is the profiling or > parameterization of the behavior required from master device in that > regulatory domain (which would be sent from DB to master in either messag= e > 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, the rule= s > as defined in =91Ofcom-2012=92 or =91FCC-2013=92 are applicable (profilin= g), or > should the behavior required by the rules be broken down into parameters > and parameters defined in the registry (parameterization)? > > Profiling means that the master can only operate in one particular > regulatory domain, if it is preconfigured 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 t= he > profiling. > > Any opinions on this? > > Yes=85 Parameterization is (IMO, etc) much much simpler. > > Let's say that Ofcom-2012 requires "rules" A, B, C and J and that FCC-201= 3 > requires A, J, X, Y and Z. > I have made a widget that works in both FCC and Ofcom worlds, so I know > about rules A - Z. > > In the future Ofcom decides that they also want to require / support rule= s > X and Y, so they make a new profile called "Ofcom-2020", which requires A= , > B, C, J, X, Y. > > If we use profiles, until I roll upgrade all of my devices I won't know > what all is required in the Ofcom-2020 profile, *even though* I know abou= t > all of the "rules" / parameters. If instead the DB simply says "Please se= nd > me A, B, C, J, X, Y" I'm golden=85 > Actually, there are two halves to this. What you're contrasting is a profile name versus a set of configuration parameters for the device. Here, I would agree that just having configuration parameters is more flexible/extensible. The other half of the problem is that the DB needs to know that the device will know what to do with the answers it returns. Suppose a device has been certified for FCC-2013, but FCC-2015 adds some additional device requirements where, if satisfied, would allow enhanced spectrum usage: - Device contacts DB telling it is compliant with FCC-2013 - DB will not ask the device for new required parameters under FCC-2015 rules - DB responds with "degraded" spectrum compliant with FCC-2013 rules (Assuming regulator allows both types of devices to continue to operate) These named rulesets may also allow new regulators to simply adopt an existing ruleset. E.g., Regulator B will allow FCC-2015 devices. -vince > W > > > > > > Thanks, Gabor > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vai= n > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > --f46d043bdf3839822004d2d60266 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 8, 2013 at 3:1= 6 PM, Warren Kumari <warren@kumari.net> wrote:

On Jan 8, 2013, at 5:02 PM, gabor.= bajko@nokia.com wrote:

> I am re-sending this email, as I got no feedback on my questions in it= .

Apologies. This got lost in a mailbox...

> The responses to the questions below would significantly influence the= solution design, so I=92d like to hear some feedback. Is there anybody who= cares about it?

I don't care deeply, but have *some* opinions...

>
> - =A0 =A0 =A0 =A0 =A0Gabor
>
> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
> Sent: Tuesday, December 04, 2012 11:57 AM
> To: paws@ietf.org
> Subject: [paws] outcome of the Atlanta F2F -2-
>
> One main discussion point in the f2f was future extensibility, for the= cases when regulators decide to require additional parameters from master = devices; another discussion point was what parameters would the master init= ially, 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 r= esponded as already described in the draft, or the DB would respond with a = message indicating additional required parameters, after which the master w= ould resend the request with the indicated parameters.
>
> I believe this functionality could be supported by the currently defin= ed one round trip INIT procedure as well, once the error handling is added = to the document:
> 1. =A0 =A0 =A0 Master sends INIT request to the server, including at l= east its location
> 2. =A0 =A0 =A0 DB would respond with an error message, indicating the = missing parameters
> 3. =A0 =A0 =A0 Master sends a new INIT request, including all the requ= ired parameters
> 4. =A0 =A0 =A0 DB sends to master the regulatory domain, parameter val= ues and required behavior from master in this regulatory domain
>
> Am I missing sg?

Only some clarifications:
I thing that 2 is actually: If the Master included all parameters that the = DB needed, things proceed normally. If there are parameters that the DB nee= ds, then "DB would respond with an error message, indicating the missi= ng parameters".

Agreed.
=A0

Also, if the DB requests that the Master send Color_of_Unicorn and the Mast= er doesn't know this, what happens? What if this is simply something th= e DB would *like* to know, but is OK proceeding without it?

I think it the DB is OK proceeding without it, th= en it is not a "required" parameter, so it should just proceed to= return the requested information.
If it must know, and the= Master doesn't know it, then the DB must still respond with an error.<= /div>
I don't think there is an inconsistency.
=A0

>
> There was also another suggestion on having the parameters which could= be carried in message 2 above be defined and put in the IANA registry. Tha= t way, the DB can easily point the master to which parameter it requires fr= om 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= regulatory domain profiling of the required parameters.

Yup. This sounds good -- I don't really think that avoiding firmw= are updates are likely, but a registry would defiantly make it easier to tr= ack allocation of code points, etc. Much simpler to instruct the IANA to as= sign something in a registry (possibly after RFC or stable reference) than = to keep obsoleting docs, following long chains of drafts, etc...


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

No objections...

>
> What I believe we have not discussed, is the profiling or parameteriza= tion of the behavior required from master device in that regulatory domain = (which would be sent from DB to master in either message 2 or 4 above). Ie,= is it ok if the DB tells the master, that eg, the rules as defined in =91O= fcom-2012=92 or =91FCC-2013=92 are applicable (profiling), or should the be= havior required by the rules be broken down into parameters and parameters = defined in the registry (parameterization)?
> Profiling means that the master can only operate in one particular reg= ulatory domain, if it is preconfigured 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 th= e profiling.
> Any opinions on this?

Yes=85 Parameterization is (IMO, etc) much much simpler.

Let's say that Ofcom-2012 requires "rules" A, B, C and J and = that FCC-2013 requires A, J, X, Y and Z.
I have made a widget that works in both FCC and Ofcom worlds, so I know abo= ut rules A - Z.

In the future Ofcom decides that they also want to require / support rules = X and Y, so they make a new profile called "Ofcom-2020", which re= quires A, B, C, J, X, Y.

If we use profiles, until I roll upgrade all of my devices I won't know= what all is required in the Ofcom-2020 profile, *even though* I know about= all of the "rules" / parameters. If instead the DB simply says &= quot;Please send me A, B, C, J, X, Y" I'm golden=85

Actually, there are two halves to th= is.

What you're contrasting is a p= rofile name versus a set of configuration parameters for the device. Here, = I would agree that just having configuration parameters is more flexible/ex= tensible.

The other half of the problem is that the D= B needs to know that the device will know what to do with the answers it re= turns.

Suppose a device has been certi= fied for FCC-2013, but FCC-2015 adds some additional device requirements wh= ere, if satisfied, would allow enhanced spectrum usage:
=A0- Device contacts DB telling it is compliant with FCC-2013
=A0- DB will not ask the device for new required parameters u= nder FCC-2015 rules
=A0- DB responds with "degraded&qu= ot; spectrum compliant with FCC-2013 rules

(Assuming regulator allows both types of de= vices to continue to operate)

These na= med rulesets may also allow new regulators to simply adopt an existing rule= set. E.g., Regulator B will allow FCC-2015 devices.

-vince


W


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

--
It is impossible to sharpen a pencil with a blunt axe. =A0It is equal= ly vain
to try to do it with ten blunt axes instead.
=A0 =A0 -- =A0E.W Dijkstra, 1930-2002



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



<= /div> --f46d043bdf3839822004d2d60266-- From michael.fitch@bt.com Wed Jan 9 06:55:05 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB0221F85D2 for ; Wed, 9 Jan 2013 06:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4NXq-nxKnuxo for ; Wed, 9 Jan 2013 06:55:04 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0310421F85C2 for ; Wed, 9 Jan 2013 06:55:03 -0800 (PST) Received: from EVHUB70-UKRD.domain1.systemhost.net (10.36.3.153) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 9 Jan 2013 14:55:01 +0000 Received: from EVMHT31-UKDY.domain1.systemhost.net (193.113.31.41) by EVHUB70-UKRD.domain1.systemhost.net (10.36.3.153) with Microsoft SMTP Server (TLS) id 14.2.328.5; Wed, 9 Jan 2013 14:55:00 +0000 Received: from EMV35-UKDY.domain1.systemhost.net ([169.254.1.169]) by EVMHT31-UKDY.domain1.systemhost.net ([193.113.31.41]) with mapi; Wed, 9 Jan 2013 14:55:00 +0000 From: To: , Date: Wed, 9 Jan 2013 14:54:59 +0000 Thread-Topic: [paws] outcome of the Atlanta F2F -2- Thread-Index: Ac3t9kkWfbljHq3WS5Klg+iu6kCBAQAgmnVA Message-ID: <69A7E364B918F949829C3CD4FF25994E0AB3E01656@EMV35-UKDY.domain1.systemhost.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> In-Reply-To: <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [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: Wed, 09 Jan 2013 14:55:05 -0000 Dear all I would support the view that there be provision for including information = that the dB would 'like' to know, or more to the point could 'usefully' kno= w, in order to optionally provide more value-added services. Examples might= be to pre-clear spectrum when a WSD is moving, or to take account of anten= na directivity.=20 Best wishes Michael Fitch, BT -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of War= ren Kumari Sent: 08 January 2013 23:17 To: gabor.bajko@nokia.com Cc: paws@ietf.org Subject: Re: [paws] outcome of the Atlanta F2F -2- On Jan 8, 2013, at 5:02 PM, gabor.bajko@nokia.com wrote: > I am re-sending this email, as I got no feedback on my questions in it. Apologies. This got lost in a mailbox... > The responses to the questions below would significantly influence the so= lution design, so I'd like to hear some feedback. Is there anybody who care= s about it? I don't care deeply, but have *some* opinions... > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Bajko Gabor (Nokia-CIC/SiliconValley) > Sent: Tuesday, December 04, 2012 11:57 AM > To: paws@ietf.org > Subject: [paws] outcome of the Atlanta F2F -2- > =20 > One main discussion point in the f2f was future extensibility, for the ca= ses when regulators decide to require additional parameters from master dev= ices; another discussion point was what parameters would the master initial= ly, eg after the first power up, send to the DB. > =20 > 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 resp= onded as already described in the draft, or the DB would respond with a mes= sage indicating additional required parameters, after which the master woul= d resend the request with the indicated parameters. > =20 > I believe this functionality could be supported by the currently defined = one round trip INIT procedure as well, once the error handling is added to = the document: > 1. Master sends INIT request to the server, including at least its = location > 2. DB would respond with an error message, indicating the missing p= arameters > 3. Master sends a new INIT request, including all the required para= meters > 4. DB sends to master the regulatory domain, parameter values and r= equired behavior from master in this regulatory domain > =20 > Am I missing sg? Only some clarifications: I thing that 2 is actually: If the Master included all parameters that the = DB needed, things proceed normally. If there are parameters that the DB nee= ds, then "DB would respond with an error message, indicating the missing pa= rameters". Also, if the DB requests that the Master send Color_of_Unicorn and the Mast= er doesn't know this, what happens? What if this is simply something the DB= would *like* to know, but is OK proceeding without it? > =20 > There was also another suggestion on having the parameters which could be= carried in message 2 above be defined and put in the IANA registry. That w= ay, 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 sti= ll having the need for an admin to configure the required new parameter). A= nd with the parameters in the registry, there would be no need to do per re= gulatory domain profiling of the required parameters. Yup. This sounds good -- I don't really think that avoiding firmware update= s are likely, but a registry would defiantly make it easier to track alloca= tion of code points, etc. Much simpler to instruct the IANA to assign somet= hing in a registry (possibly after RFC or stable reference) than to keep ob= soleting docs, following long chains of drafts, etc... > =20 > I would like to confirm if this path forward is ok with folks; if you hav= e objections, then now is the time to speak up. No objections... > =20 > What I believe we have not discussed, is the profiling or parameterizatio= n of the behavior required from master device in that regulatory domain (wh= ich would be sent from DB to master in either message 2 or 4 above). Ie, is= it ok if the DB tells the master, that eg, the rules as defined in 'Ofcom-= 2012' or 'FCC-2013' are applicable (profiling), or should the behavior requ= ired by the rules be broken down into parameters and parameters defined in = the registry (parameterization)? > Profiling means that the master can only operate in one particular=20 > regulatory domain, if it is preconfigured 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 bi= t more work than the profiling. > Any opinions on this? Yes... Parameterization is (IMO, etc) much much simpler.=20 Let's say that Ofcom-2012 requires "rules" A, B, C and J and that FCC-2013 = requires A, J, X, Y and Z. I have made a widget that works in both FCC and Ofcom worlds, so I know abo= ut rules A - Z. In the future Ofcom decides that they also want to require / support rules = X and Y, so they make a new profile called "Ofcom-2020", which requires A, = B, C, J, X, Y. If we use profiles, until I roll upgrade all of my devices I won't know wha= t all is required in the Ofcom-2020 profile, *even though* I know about all= of the "rules" / parameters. If instead the DB simply says "Please send me= A, B, C, J, X, Y" I'm golden... W > =20 > Thanks, Gabor > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws -- It is impossible to sharpen a pencil with a blunt axe. It is equally vain = to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Wed Jan 9 07:16:53 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF6521F8425 for ; Wed, 9 Jan 2013 07:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 zVmVnCFidUoJ for ; Wed, 9 Jan 2013 07:16:52 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7385B21F8700 for ; Wed, 9 Jan 2013 07:16:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Irfo+uhIFN4yjk8SUD5o3Sw+T66n0DubE0kzjPtXu9OjZomdhVlKW1aq3uojtMai; 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-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TsxOF-00071W-IU; Wed, 09 Jan 2013 10:16:27 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E332D599-479D-4C03-98CF-14E6A30B0124" From: Nancy Bravin In-Reply-To: <69A7E364B918F949829C3CD4FF25994E0AB3E01656@EMV35-UKDY.domain1.systemhost.net> Date: Wed, 9 Jan 2013 07:16:25 -0800 Message-Id: <4519CE06-69B1-4EEB-9939-62DE30E7F0CE@earthlink.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> <69A7E364B918F949829C3CD4FF25994E0AB3E01656@EMV35-UKDY.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86829d448cd0f579026af2dc625d0df8bd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [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: Wed, 09 Jan 2013 15:16:53 -0000 --Apple-Mail=_E332D599-479D-4C03-98CF-14E6A30B0124 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I would be in favor of anything that could make such things extensible = without having to re write=85maybe some of the DB guys can weigh in on this as well. Sincerely,=20 Nancy=20 On Jan 9, 2013, at 6:54 AM, wrote: > Dear all >=20 > I would support the view that there be provision for including = information that the dB would 'like' to know, or more to the point could = 'usefully' know, in order to optionally provide more value-added = services. Examples might be to pre-clear spectrum when a WSD is moving, = or to take account of antenna directivity.=20 >=20 > Best wishes >=20 > Michael Fitch, BT >=20 >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Warren Kumari > Sent: 08 January 2013 23:17 > To: gabor.bajko@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] outcome of the Atlanta F2F -2- >=20 >=20 > On Jan 8, 2013, at 5:02 PM, gabor.bajko@nokia.com wrote: >=20 >> I am re-sending this email, as I got no feedback on my questions in = it. >=20 > Apologies. This got lost in a mailbox... >=20 >> The responses to the questions below would significantly influence = the solution design, so I'd like to hear some feedback. Is there anybody = who cares about it? >=20 > I don't care deeply, but have *some* opinions... >=20 >>=20 >> - Gabor >>=20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20= >> Of Bajko Gabor (Nokia-CIC/SiliconValley) >> Sent: Tuesday, December 04, 2012 11:57 AM >> To: paws@ietf.org >> Subject: [paws] outcome of the Atlanta F2F -2- >>=20 >> One main discussion point in the f2f was future extensibility, for = the cases when regulators decide 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. >>=20 >> 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 described 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. >>=20 >> I believe this functionality could be supported by the currently = defined one round trip INIT procedure as well, once the error handling = is added to the document: >> 1. Master sends INIT request to the server, including at least = its location >> 2. DB would respond with an error message, indicating the = missing parameters >> 3. Master sends a new INIT request, including all the required = parameters >> 4. DB sends to master the regulatory domain, parameter values = and required behavior from master in this regulatory domain >>=20 >> Am I missing sg? >=20 > Only some clarifications: > I thing that 2 is actually: If the Master included all parameters that = the DB needed, things proceed normally. If there are parameters that the = DB needs, then "DB would respond with an error message, indicating the = missing parameters". >=20 > Also, if the DB requests that the Master send Color_of_Unicorn and the = Master doesn't know this, what happens? What if this is simply something = the DB would *like* to know, but is OK proceeding without it? >=20 >>=20 >> There was also another suggestion on having the parameters which = could be carried 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 regulatory domain profiling = of the required parameters. >=20 > Yup. This sounds good -- I don't really think that avoiding firmware = updates are likely, but a registry would defiantly make it easier to = track allocation of code points, etc. Much simpler to instruct the IANA = to assign something in a registry (possibly after RFC or stable = reference) than to keep obsoleting docs, following long chains of = drafts, etc... >=20 >=20 >>=20 >> 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. >=20 > No objections... >=20 >>=20 >> What I believe we have not discussed, is the profiling or = parameterization of the behavior required from master device in that = regulatory domain (which would be sent from DB to master in either = message 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, = the rules as defined in 'Ofcom-2012' or 'FCC-2013' are applicable = (profiling), or should the behavior required by the rules be broken down = into parameters and parameters defined in the registry = (parameterization)? >> Profiling means that the master can only operate in one particular=20 >> regulatory domain, if it is preconfigured 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? >=20 > Yes... Parameterization is (IMO, etc) much much simpler.=20 >=20 > Let's say that Ofcom-2012 requires "rules" A, B, C and J and that = FCC-2013 requires A, J, X, Y and Z. > I have made a widget that works in both FCC and Ofcom worlds, so I = know about rules A - Z. >=20 > In the future Ofcom decides that they also want to require / support = rules X and Y, so they make a new profile called "Ofcom-2020", which = requires A, B, C, J, X, Y. >=20 > If we use profiles, until I roll upgrade all of my devices I won't = know what all is required in the Ofcom-2020 profile, *even though* I = know about all of the "rules" / parameters. If instead the DB simply = says "Please send me A, B, C, J, X, Y" I'm golden... >=20 >=20 > W >=20 >=20 >>=20 >> Thanks, Gabor >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 >=20 >=20 >=20 > _______________________________________________ > 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 --Apple-Mail=_E332D599-479D-4C03-98CF-14E6A30B0124 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = would be in favor of anything that could make such things extensible = without having to re write=85maybe some of the DB guys can weigh = in
on this as = well.

Sincerely, 
michael.fitch@bt.com> = wrote:

Dear all

I would support the view that there = be provision for including information that the dB would 'like' to know, = or more to the point could 'usefully' know, in order to optionally = provide more value-added services. Examples might be to pre-clear = spectrum when a WSD is moving, or to take account of antenna = directivity.

Best wishes

Michael Fitch, = BT



-----Original Message-----
From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Warren Kumari
Sent: 08 = January 2013 23:17
To: gabor.bajko@nokia.com
Cc: = paws@ietf.org
Subject: Re: = [paws] outcome of the Atlanta F2F -2-


On Jan 8, 2013, at 5:02 = PM, gabor.bajko@nokia.com = wrote:

I am re-sending this email, as I = got no feedback on my questions in it.

Apologies. = This got lost in a mailbox...

The = responses to the questions below would significantly influence the = solution design, so I'd like to hear some feedback. Is there anybody who = cares about it?

I don't care deeply, but have *some* = opinions...


- =          Gabor

From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf
Of Bajko Gabor = (Nokia-CIC/SiliconValley)
Sent: = Tuesday, December 04, 2012 11:57 AM
To: paws@ietf.org
Subject: [paws] outcome of the Atlanta F2F = -2-

One main discussion point in the f2f was future = extensibility, for the cases when regulators decide 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.

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 described 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 = functionality could be supported by the currently defined one round trip = INIT procedure as well, once the error handling is added to the = document:
1. =       Master sends INIT request to the = server, including at least its location
2.       DB would respond = with an error message, indicating the missing = parameters
3. =       Master sends a new INIT request, = including all the required parameters
4.       DB sends to master = the regulatory domain, parameter values and required behavior from = master in this regulatory domain

Am I missing = sg?

Only some clarifications:
I thing that 2 is = actually: If the Master included all parameters that the DB needed, = things proceed normally. If there are parameters that the DB needs, then = "DB would respond with an error message, indicating the missing = parameters".

Also, if the DB requests that the Master send = Color_of_Unicorn and the Master doesn't know this, what happens? What if = this is simply something the DB would *like* to know, but is OK = proceeding without it?


There was also = another suggestion on having the parameters which could be carried 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 regulatory domain profiling of the required = parameters.

Yup. This sounds good -- I don't really = think that avoiding firmware updates are likely, but a registry would = defiantly make it easier to track allocation of code points, etc. Much = simpler to instruct the IANA to assign something in a registry (possibly = after RFC or stable reference) than to keep obsoleting docs, following = long chains of drafts, etc...



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.

No = objections...


What I believe = we have not discussed, is the profiling or parameterization of the = behavior required from master device in that regulatory domain (which = would be sent from DB to master in either message 2 or 4 above). Ie, is = it ok if the DB tells the master, that eg, the rules as defined in = 'Ofcom-2012' or 'FCC-2013' are applicable (profiling), or should the = behavior required by the rules be broken down into parameters and = parameters defined in the registry = (parameterization)?
Profiling = means that the master can only operate in one particular =
regulatory domain, if it is = preconfigured 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?

Yes... Parameterization is (IMO, etc) much = much simpler.

Let's say that Ofcom-2012 requires "rules" A, B, C = and J and that FCC-2013 requires A, J, X, Y and Z.
I have made a = widget that works in both FCC and Ofcom worlds, so I know about rules A = - Z.

In the future Ofcom decides that they also want to require / = support rules X and Y, so they make a new profile called "Ofcom-2020", = which requires A, B, C, J, X, Y.

If we use profiles, until I roll = upgrade all of my devices I won't know what all is required in the = Ofcom-2020 profile, *even though* I know about all of the "rules" / = parameters. If instead the DB simply says "Please send me A, B, C, J, X, = Y" I'm golden...


W



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

--
It is impossible to = sharpen a pencil with a blunt axe.  It is equally vain to try to do = it with ten blunt axes instead.
   --  E.W = Dijkstra, = 1930-2002



_______________________________________________paws mailing list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws
_______________________________________________
= paws mailing = list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

= --Apple-Mail=_E332D599-479D-4C03-98CF-14E6A30B0124-- From warren@kumari.net Wed Jan 9 07:23:11 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD121F87EA for ; Wed, 9 Jan 2013 07:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 YhNqSq4UHWH0 for ; Wed, 9 Jan 2013 07:23:10 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D9821F842B for ; Wed, 9 Jan 2013 07:23:09 -0800 (PST) Received: from [192.168.1.136] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 2CE471B4040E; Wed, 9 Jan 2013 10:23:09 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: Date: Wed, 9 Jan 2013 10:23:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <504EBC1E-4197-41DF-85A0-FB71B547CF4C@kumari.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> To: Vincent Chen X-Mailer: Apple Mail (2.1499) Cc: "paws@ietf.org" Subject: Re: [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: Wed, 09 Jan 2013 15:23:11 -0000 On Jan 9, 2013, at 2:28 AM, Vincent Chen wrote: >=20 >=20 >=20 > On Tue, Jan 8, 2013 at 3:16 PM, Warren Kumari = wrote: >=20 > On Jan 8, 2013, at 5:02 PM, gabor.bajko@nokia.com wrote: >=20 > > I am re-sending this email, as I got no feedback on my questions in = it. >=20 > Apologies. This got lost in a mailbox... >=20 > > The responses to the questions below would significantly influence = the solution design, so I=92d like to hear some feedback. Is there = anybody who cares about it? >=20 > I don't care deeply, but have *some* opinions... >=20 > > > > - Gabor > > > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Bajko Gabor (Nokia-CIC/SiliconValley) > > Sent: Tuesday, December 04, 2012 11:57 AM > > To: paws@ietf.org > > Subject: [paws] outcome of the Atlanta F2F -2- > > > > One main discussion point in the f2f was future extensibility, for = the cases when regulators decide 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. > > > > 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 described 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 functionality could be supported by the currently = defined one round trip INIT procedure as well, once the error handling = is added to the document: > > 1. Master sends INIT request to the server, including at least = its location > > 2. DB would respond with an error message, indicating the = missing parameters > > 3. Master sends a new INIT request, including all the required = parameters > > 4. DB sends to master the regulatory domain, parameter values = and required behavior from master in this regulatory domain > > > > Am I missing sg? >=20 > Only some clarifications: > I thing that 2 is actually: If the Master included all parameters that = the DB needed, things proceed normally. If there are parameters that the = DB needs, then "DB would respond with an error message, indicating the = missing parameters". >=20 > Agreed. > =20 >=20 > Also, if the DB requests that the Master send Color_of_Unicorn and the = Master doesn't know this, what happens? What if this is simply something = the DB would *like* to know, but is OK proceeding without it? >=20 > I think it the DB is OK proceeding without it, then it is not a = "required" parameter, so it should just proceed to return the requested = information. > If it must know, and the Master doesn't know it, then the DB must = still respond with an error. > I don't think there is an inconsistency. >=20 > =20 >=20 > > > > There was also another suggestion on having the parameters which = could be carried 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 regulatory domain profiling = of the required parameters. >=20 > Yup. This sounds good -- I don't really think that avoiding firmware = updates are likely, but a registry would defiantly make it easier to = track allocation of code points, etc. Much simpler to instruct the IANA = to assign something in a registry (possibly after RFC or stable = reference) than to keep obsoleting docs, following long chains of = drafts, etc... >=20 >=20 > > > > 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. >=20 > No objections... >=20 > > > > What I believe we have not discussed, is the profiling or = parameterization of the behavior required from master device in that = regulatory domain (which would be sent from DB to master in either = message 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, = the rules as defined in =91Ofcom-2012=92 or =91FCC-2013=92 are = applicable (profiling), or should the behavior required by the rules be = broken down into parameters and parameters defined in the registry = (parameterization)? > > Profiling means that the master can only operate in one particular = regulatory domain, if it is preconfigured 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? >=20 > Yes=85 Parameterization is (IMO, etc) much much simpler. >=20 > Let's say that Ofcom-2012 requires "rules" A, B, C and J and that = FCC-2013 requires A, J, X, Y and Z. > I have made a widget that works in both FCC and Ofcom worlds, so I = know about rules A - Z. >=20 > In the future Ofcom decides that they also want to require / support = rules X and Y, so they make a new profile called "Ofcom-2020", which = requires A, B, C, J, X, Y. >=20 > If we use profiles, until I roll upgrade all of my devices I won't = know what all is required in the Ofcom-2020 profile, *even though* I = know about all of the "rules" / parameters. If instead the DB simply = says "Please send me A, B, C, J, X, Y" I'm golden=85 >=20 > Actually, there are two halves to this. >=20 > What you're contrasting is a profile name versus a set of = configuration parameters for the device. Here, I would agree that just = having configuration parameters is more flexible/extensible. >=20 > The other half of the problem is that the DB needs to know that the = device will know what to do with the answers it returns. >=20 > Suppose a device has been certified for FCC-2013, but FCC-2015 adds = some additional device requirements where, if satisfied, would allow = enhanced spectrum usage: > - Device contacts DB telling it is compliant with FCC-2013 > - DB will not ask the device for new required parameters under = FCC-2015 rules > - DB responds with "degraded" spectrum compliant with FCC-2013 rules What about: - Device contacts DB telling it that it understands requirements [A, B, = C, P, Q, J] - DB will not ask the device for new required parameters under FCC-2015 = rules (which added requirement X, Y and Z) - DB responds with "degraded" spectrum compliant with FCC-2013 rules This way only the DB needs to know about profiles. If I make a white = space compatible hairbrush I really don't want to have to know about all = of the different countries required profiles, and don't want to have to = roll new profile sets every time a regulator adds a new requirement to = their set. If the requirements / parameters are something like a menu in a = restaurant then regulators can pick and choose (and change) their = requirements as they see fit=85 >=20 > (Assuming regulator allows both types of devices to continue to = operate) >=20 > These named rulesets may also allow new regulators to simply adopt an = existing ruleset. E.g., Regulator B will allow FCC-2015 devices. Well, kinda. If Regulator B wants to support FCC-2015 except that they = don't want Subsection 3, Clause 12.2.8.3 they are kinda stuck. Or, if = they want a superset of FCC-2015 and Ofcom-2013 or=85 Simply doing a = capability exchange with available (numbered or names) parameters allows = regulators to build *their* preferred profile without device = manufacturers to know about it. FCC and Ofcom and Telkom and and and can still publish "profiles" = somewhere (maybe in the same IANA registry), but the profile would look = more like: FCC-2013: Required [ A, B, C, J] Optional [ P, Q] FCC-2015: Required [ A, B, C, J, P] Optional [Q, X, Y, Z] Ofcom-2013: Required [ A, B, C, J ] Optional [ P, R, X, Y ] Telkom-1886: Required [ A ] Building and transmitting a list of supported parameters is easy, = tracking every regulators set of requirements in their profiles is = "hard" :-P W >=20 > -vince >=20 >=20 > W >=20 >=20 > > > > Thanks, Gabor > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws >=20 > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally = vain > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=20 --=20 Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 -- J.R.R. Tolkien From budden@nps.edu Wed Jan 9 09:23:53 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B51021F85B8 for ; Wed, 9 Jan 2013 09:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cT-IB0wfOMGr for ; Wed, 9 Jan 2013 09:23:52 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3A21F84BC for ; Wed, 9 Jan 2013 09:23:52 -0800 (PST) X-ASG-Debug-ID: 1357752231-036c92203a245750001-Z0ZA9G Received: from skytrain.ern.nps.edu (skytrain.ern.nps.edu [172.20.24.112]) by mule.nps.edu with ESMTP id OacspyisnL0Plhpp; Wed, 09 Jan 2013 09:23:51 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 9 Jan 2013 09:23:50 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt To: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7@008-AM1MPN1-006.mgdnok.nokia.com> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <7C4CBD4C-BCB0-4598-9990-3AB1C88BFB4E@earthlink.net> <50E4D8B8.808@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F4CE7@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 9 Jan 2013 09:22:34 -0800 Message-ID: <1357752154.2201.881.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: skytrain.ern.nps.edu[172.20.24.112] X-Barracuda-Start-Time: 1357752231 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.119381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: paws@ietf.org, presnick@qti.qualcomm.com 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: Wed, 09 Jan 2013 17:23:53 -0000 Gabor, I thought this was a no-negatives review;-) I read through the doc last night and could only find irrelevant nits to carp about. You've done a good job of getting the 'how' issues out of the way of the 'what' ones. On Tue, 2013-01-08 at 21:57 +0000, Gabor.Bajko@nokia.com wrote: > Thanks Tony for generating this new version of the document. The > overlapping use cases have been merged, a new use case has been added > and the language was cleaned up throughout the document. > > I would like to ask people to review it and send to the list any > issues. So far we got feedback from Nancy (thanks!), this new revision > captures her comments. But I would like to hear from others as well, > before we ask the AD to review it again. It only takes 10-15min to > review. > > If we do not hear any concerns or objections from anyone until next > Monday (Jan 14th), we’ll assume the group is fine with the document > and we’ll ask for the AD review. > > > > Thanks, Gabor > > > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of ext Pete Resnick > Sent: Wednesday, January 02, 2013 5:03 PM > To: Anthony Mancuso > Cc: paws@ietf.org > Subject: Re: [paws] Fwd: I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt > > > > > Tony, > > Thanks for the new version. At first glance, it looks like a good > edit. I'll do a thorough review once the WG confirms that this one is > good to go. > > Chairs, let me know when this has had enough review. I'd especially > like to hear from folks like Peter Stanforth and others who had > concerns that my suggestions might have removed too much from the > document. Does this version satisfy everyone? > > Thanks for giving this a go, and a happy new year to everyone. > > pr > > On 12/21/12 12:39 PM, Anthony Mancuso wrote: > > 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 > > > > > > > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From budden@nps.edu Wed Jan 9 09:49:56 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0129A21F8862 for ; Wed, 9 Jan 2013 09:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] 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 wH+-65eGyOA0 for ; Wed, 9 Jan 2013 09:49:55 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id E542C21F8698 for ; Wed, 9 Jan 2013 09:49:54 -0800 (PST) X-ASG-Debug-ID: 1357753794-036c92203c245c60001-Z0ZA9G Received: from skytrain.ern.nps.edu (skytrain.ern.nps.edu [172.20.24.112]) by mule.nps.edu with ESMTP id gmah0DyooKoOsUTB; Wed, 09 Jan 2013 09:49:54 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.438.0; Wed, 9 Jan 2013 09:49:53 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] outcome of the Atlanta F2F -2- To: In-Reply-To: <69A7E364B918F949829C3CD4FF25994E0AB3E01656@EMV35-UKDY.domain1.systemhost.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> <69A7E364B918F949829C3CD4FF25994E0AB3E01656@EMV35-UKDY.domain1.systemhost.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 9 Jan 2013 09:48:43 -0800 Message-ID: <1357753723.2201.898.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: skytrain.ern.nps.edu[172.20.24.112] X-Barracuda-Start-Time: 1357753794 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.119381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: paws@ietf.org Subject: Re: [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: Wed, 09 Jan 2013 17:49:56 -0000 Gabor, First, agree that extensibility is a must. No regulatory agency will get it all right the first time. Extending Michael's thoughts a bit here: - DHCP implementations have sticky memories. If you shut off your office computer, then, after a weekend of carousing, turn it back on, then if the IP address you used to have is still in the pool it will be reassigned to you. If the database were to have this kind of stickiness, then a down-the-calendar request for spectrum might require less startup information (over what might be a low-bandwidth connection). - it might make sense for the db to award a minimal amount of spectrum in order to get _a_ connection working. Then the master could use that connection as the means to amend its request. Do we have to get everything right in the first request? On Wed, 2013-01-09 at 14:54 +0000, michael.fitch@bt.com wrote: > Dear all > > I would support the view that there be provision for including information that the dB would 'like' to know, or more to the point could 'usefully' know, in order to optionally provide more value-added services. Examples might be to pre-clear spectrum when a WSD is moving, or to take account of antenna directivity. > > Best wishes > > Michael Fitch, BT > > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Warren Kumari > Sent: 08 January 2013 23:17 > To: gabor.bajko@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] outcome of the Atlanta F2F -2- > > > On Jan 8, 2013, at 5:02 PM, gabor.bajko@nokia.com wrote: > > > I am re-sending this email, as I got no feedback on my questions in it. > > Apologies. This got lost in a mailbox... > > > The responses to the questions below would significantly influence the solution design, so I'd like to hear some feedback. Is there anybody who cares about it? > > I don't care deeply, but have *some* opinions... > > > > > - Gabor > > > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > > Of Bajko Gabor (Nokia-CIC/SiliconValley) > > Sent: Tuesday, December 04, 2012 11:57 AM > > To: paws@ietf.org > > Subject: [paws] outcome of the Atlanta F2F -2- > > > > One main discussion point in the f2f was future extensibility, for the cases when regulators decide 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. > > > > 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 described 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 functionality could be supported by the currently defined one round trip INIT procedure as well, once the error handling is added to the document: > > 1. Master sends INIT request to the server, including at least its location > > 2. DB would respond with an error message, indicating the missing parameters > > 3. Master sends a new INIT request, including all the required parameters > > 4. DB sends to master the regulatory domain, parameter values and required behavior from master in this regulatory domain > > > > Am I missing sg? > > Only some clarifications: > I thing that 2 is actually: If the Master included all parameters that the DB needed, things proceed normally. If there are parameters that the DB needs, then "DB would respond with an error message, indicating the missing parameters". > > Also, if the DB requests that the Master send Color_of_Unicorn and the Master doesn't know this, what happens? What if this is simply something the DB would *like* to know, but is OK proceeding without it? > > > > > There was also another suggestion on having the parameters which could be carried 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 regulatory domain profiling of the required parameters. > > Yup. This sounds good -- I don't really think that avoiding firmware updates are likely, but a registry would defiantly make it easier to track allocation of code points, etc. Much simpler to instruct the IANA to assign something in a registry (possibly after RFC or stable reference) than to keep obsoleting docs, following long chains of drafts, etc... > > > > > > 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. > > No objections... > > > > > What I believe we have not discussed, is the profiling or parameterization of the behavior required from master device in that regulatory domain (which would be sent from DB to master in either message 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, the rules as defined in 'Ofcom-2012' or 'FCC-2013' are applicable (profiling), or should the behavior required by the rules be broken down into parameters and parameters defined in the registry (parameterization)? > > Profiling means that the master can only operate in one particular > > regulatory domain, if it is preconfigured 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? > > Yes... Parameterization is (IMO, etc) much much simpler. > > Let's say that Ofcom-2012 requires "rules" A, B, C and J and that FCC-2013 requires A, J, X, Y and Z. > I have made a widget that works in both FCC and Ofcom worlds, so I know about rules A - Z. > > In the future Ofcom decides that they also want to require / support rules X and Y, so they make a new profile called "Ofcom-2020", which requires A, B, C, J, X, Y. > > If we use profiles, until I roll upgrade all of my devices I won't know what all is required in the Ofcom-2020 profile, *even though* I know about all of the "rules" / parameters. If instead the DB simply says "Please send me A, B, C, J, X, Y" I'm golden... > > > W > > > > > > Thanks, Gabor > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 > > > > _______________________________________________ > 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 vchen@google.com Wed Jan 9 15:38:04 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FAC21F842E for ; Wed, 9 Jan 2013 15:38:04 -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 gEjoi8Yk10r6 for ; Wed, 9 Jan 2013 15:38:03 -0800 (PST) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by ietfa.amsl.com (Postfix) with ESMTP id 29BF121F8439 for ; Wed, 9 Jan 2013 15:38:02 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id x48so1330637wey.36 for ; Wed, 09 Jan 2013 15:38:01 -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=DolQP0aD1aWO/7zh5VLzN5/5hN2jVEJLHf8KAu2a98g=; b=lWFEE4vaDDmAxJzdtclJYD/hOFN6OhU74ao51gfpZOgyABqKkeJHTE25MO9Y2djY+X iOiJJGim8hHXcEfrKPGPYZ60RpXgCKg0gjnQGAgVjTI1aqhJhdgJ621tyuD4Z3WZU2Gk mdnQoujPEy6NUfw+v2NSy2KV2ZeQVaLlFWpq+38FXaKAuT7c+zpAUGE7BYYu4yZO+JC9 X2USF1O8W8RQDYusIA4IO9UacFR/wDhla+Mpdm2O6BMBML39VsxBCzJAkhpxPOEonuwa whiEXeVZgWxRSZpRQsm0Wobe3pJwhRYIAg0AYASHyEZVA6ealEqGAZ1mgfYl0li1sqW5 w9Fg== 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=DolQP0aD1aWO/7zh5VLzN5/5hN2jVEJLHf8KAu2a98g=; b=L+kru3e3Zn4ndDQcXu6A/DNTGrJCZgRxxT6gdwBZ5/7TmR+8jC3EKlrvOPkAvwkYc1 LPnlQQf2C9Gq/D6Pr6lxVWfnD/FFuvdJRkZtuh8rvVJK/QSIKOhovPF+F2ZmOBv864wi lpUtmTfeV027nJ9iF2kxOHZzH8Q4jlGhv/TmujGFqcz1VHtWfIkeUetiwtA148vOpUjL kXTptcyi/M1u2ynG616E+TgxVILAdGvOgMuYCx006Vn0KqgVgB93TzLN5mJi8JNYPtPO PnECqrVi7zEB3m9j5qQeTXWxjbI9+iS9Xt+q+5Om/SnCjeAao0TJrURTNvoCH8vSoO6o rMrg== MIME-Version: 1.0 Received: by 10.194.76.99 with SMTP id j3mr111802320wjw.47.1357774681686; Wed, 09 Jan 2013 15:38:01 -0800 (PST) Received: by 10.194.16.36 with HTTP; Wed, 9 Jan 2013 15:38:01 -0800 (PST) In-Reply-To: References: <1ECAFF543A2FED4EA2BEB6CACE08E476020B0614@008-AM1MPN1-007.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F5D0B@008-AM1MPN1-006.mgdnok.nokia.com> <01060872-B01B-4F01-8006-C2A4E0B228A8@kumari.net> <504EBC1E-4197-41DF-85A0-FB71B547CF4C@kumari.net> Date: Wed, 9 Jan 2013 15:38:01 -0800 Message-ID: From: Vincent Chen To: "paws@ietf.org" , Warren Kumari Content-Type: multipart/alternative; boundary=047d7bb04cf69642e504d2e38dde X-Gm-Message-State: ALoCoQkA5EYEq17/Ti+8jDr5EUPQcRqrjg8cg1GCUi434w4Rw/puhSA2SMoOM4iooRpTsj/3CdEHlTYilPrItfxEZYWUZK/jaBo33wacQO3RPmRRMNIl9pHcKR4ABL7De9G7f15IwFaYF/nhsPvFKXsquNh63nGQZHLAQo1dXeQAgN8HODpnEMxlW6axNLMmK935nYSpjm72 Subject: [paws] Fwd: 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: Wed, 09 Jan 2013 23:38:04 -0000 --047d7bb04cf69642e504d2e38dde Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +paws > > > Actually, there are two halves to this. > > > > What you're contrasting is a profile name versus a set of configuration > parameters for the device. Here, I would agree that just having > configuration parameters is more flexible/extensible. > > > > The other half of the problem is that the DB needs to know that the > device will know what to do with the answers it returns. > > > > Suppose a device has been certified for FCC-2013, but FCC-2015 adds som= e > additional device requirements where, if satisfied, would allow enhanced > spectrum usage: > > - Device contacts DB telling it is compliant with FCC-2013 > > - DB will not ask the device for new required parameters under FCC-201= 5 > rules > > - DB responds with "degraded" spectrum compliant with FCC-2013 rules > > What about: > > - Device contacts DB telling it that it understands requirements [A, B, > C, P, Q, J] > - DB will not ask the device for new required parameters under FCC-2015 > rules (which added requirement X, Y and Z) > - DB responds with "degraded" spectrum compliant with FCC-2013 rules > > This way only the DB needs to know about profiles. If I make a white spac= e > compatible hairbrush I really don't want to have to know about all of the > different countries required profiles, and don't want to have to roll new > profile sets every time a regulator adds a new requirement to their set. > If the requirements / parameters are something like a menu in a restauran= t > then regulators can pick and choose (and change) their requirements as th= ey > see fit=85 > > > > > (Assuming regulator allows both types of devices to continue to operate= ) > > > > These named rulesets may also allow new regulators to simply adopt an > existing ruleset. E.g., Regulator B will allow FCC-2015 devices. > > Well, kinda. If Regulator B wants to support FCC-2015 except that they > don't want Subsection 3, Clause 12.2.8.3 they are kinda stuck. Or, if the= y > want a superset of FCC-2015 and Ofcom-2013 or=85 Simply doing a capabilit= y > exchange with available (numbered or names) parameters allows regulators = to > build *their* preferred profile without device manufacturers to know abou= t > it. > > FCC and Ofcom and Telkom and and and can still publish "profiles" > somewhere (maybe in the same IANA registry), but the profile would look > more like: > > FCC-2013: Required [ A, B, C, J] Optional [ P, Q] > FCC-2015: Required [ A, B, C, J, P] Optional [Q, X, Y, Z] > > Ofcom-2013: Required [ A, B, C, J ] Optional [ P, R, X, Y ] > > Telkom-1886: Required [ A ] > > > Building and transmitting a list of supported parameters is easy, trackin= g > every regulators set of requirements in their profiles is "hard" :-P > > W > Some more thoughts: 1. It may be to the best interest of a regulator to adopt an existing rule set, because all those devices would just work. If a regulator chooses to modify the rules, then it takes on the burden of certifying that a device still works correctly, since: a. The device may never have operated in that particular configuration before b. Or, conversely, it's a burden to have the device manufactures test the device in all possible combinations of requirements, just in case some regulator might want to use it in a particular configuration. c. There is no guarantee that a mix-and-match of requirements still results in the right behavior. It might result in refactoring of requirements, which will make this a really complex system to understand. 2. Also, there are regulatory rules that involve only the device and is not (and probably should not be) reflected in the protocol or Database. (E.g., how a device must select channels and powers from the available spectrum list provided by the Database). The assertion of which rule set the device supports allows the Database to determine easily whether it can service that device. Are you confident that one can always decompose a set of regulations into a set of orthogonal requirements allowing mix and match? --=20 -vince --047d7bb04cf69642e504d2e38dde Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+paws

> Actually, there are two halves to this.
>
> What you're contrasting is a profile name versus a set of configur= ation parameters for the device. Here, I would agree that just having confi= guration parameters is more flexible/extensible.
>
> The other half of the problem is that the DB needs to know that the de= vice will know what to do with the answers it returns.
>
> Suppose a device has been certified for FCC-2013, but FCC-2015 adds so= me additional device requirements where, if satisfied, would allow enhanced= spectrum usage:
> =A0- Device contacts DB telling it is compliant with FCC-2013
> =A0- DB will not ask the device for new required parameters under FCC-= 2015 rules
> =A0- DB responds with "degraded" spectrum compliant with FCC= -2013 rules

What about:

=A0- Device contacts DB telling it that it understands requirements [A, B, = C, P, Q, J]
=A0- DB will not ask the device for new required parameters under FCC-2015 = rules (which added requirement X, Y and Z)
=A0- DB responds with "degraded" spectrum compliant with FCC= -2013 rules

This way only the DB needs to know about profiles. If I make a white = space compatible hairbrush I really don't want to have to know about al= l of the different countries required profiles, and don't want to have = to roll new profile sets every time a regulator adds a new requirement to t= heir set.
If the requirements / parameters are something like a menu in a restaurant = then regulators can pick and choose (and change) their requirements as they= see fit=85

>
> (Assuming regulator allows both types of devices to continue to operat= e)
>
> These named rulesets may also allow new regulators to simply adopt an = existing ruleset. E.g., Regulator B will allow FCC-2015 devices.

Well, kinda. If Regulator B wants to support FCC-2015 except that the= y don't want Subsection 3, Clause 12.2.8.3 they are kinda stuck. Or, if= they want a superset of FCC-2015 and Ofcom-2013 or=85 Simply doing a capab= ility exchange with available (numbered or names) parameters allows regulat= ors to build *their* preferred profile without device manufacturers to know= about it.

FCC and Ofcom and Telkom and and and can still publish "profiles"= somewhere (maybe in the same IANA registry), but the profile would look mo= re like:

FCC-2013: Required [ A, B, C, J] Optional [ P, Q]
FCC-2015: Required [ A, B, C, J, P] Optional [Q, =A0X, Y, Z]

Ofcom-2013: Required [ A, B, C, J ] Optional [ P, R, X, Y ]

Telkom-1886: Required [ A ]


Building and transmitting a list of supported parameters is easy, tracking = every regulators set of requirements in their profiles is "hard" = :-P

W

Some more thoughts:

=A01. It may be to the best interest of a regulator= to adopt an existing rule set, because all those devices would just work.<= /font>
=A0 =A0If a = regulator chooses to modify the rules, then it takes on the burden of certi= fying that a device still works correctly, since:
=A0 a. The device may ne= ver have operated in that particular configuration before

=A0 b. Or, conversely, it's a burden to have th= e device manufactures test the device in all possible combinations of requi= rements, just in case some regulator might want to use it in a particular c= onfiguration.

=A0 c. There is no guarantee th= at a mix-and-match of requirements still results in the right behavior. It = might result in refactoring of requirements, which will make this a really = complex system to understand.


<= div class=3D"gmail_extra">=A02. Also, there are=A0<= /font>regulatory rules that involve only= the device and is not (and probably should not be) reflected in the protoc= ol or Database. (E.g., how a device must select channels and powers from th= e available spectrum list provided by the Database). The assertion of which= rule set the device supports allows the Database to determine easily wheth= er it can service that device.

Are you c= onfident that one can always decompose a set of regulations into a set of o= rthogonal requirements allowing mix and match?



--
-vince
--047d7bb04cf69642e504d2e38dde-- From nbravin@earthlink.net Wed Jan 9 23:58:22 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6E221F88EA for ; Wed, 9 Jan 2013 23:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WE5FTWwSu8XT for ; Wed, 9 Jan 2013 23:58:20 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA8D21F880E for ; Wed, 9 Jan 2013 23:58:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qaPbEvmcRt7/HLF6Q/eOWNnKcL1jCYimSzBLLraU3ZowNnv2LRqFVY9SANZ5fD0t; h=Received:From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.8]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TtD1h-0007CJ-Lp; Thu, 10 Jan 2013 02:58:13 -0500 From: Nancy Bravin Content-Type: multipart/alternative; boundary="Apple-Mail=_C9405ABD-E284-4BAF-BF88-A7E2CC37D3C7" Date: Wed, 9 Jan 2013 23:58:11 -0800 Message-Id: <5B78FA04-8033-4D92-82CB-D4FBD2E79C25@earthlink.net> To: Anthony Mancuso , Gabor Bajko Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86221119752580db856f850cd55041ff26350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: [paws] what is missing and does it matter? 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, 10 Jan 2013 07:58:22 -0000 --Apple-Mail=_C9405ABD-E284-4BAF-BF88-A7E2CC37D3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I just can't help myself, here are my thoughts: 1. Do we, by combining use cases, leave a hole that needs to be plugged = by the FCC regulations? 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as in = supporting documents, "rural and remote", have we addressed remote as a = use case and should we? To me it seems that we should for there needs to be = an inexpensive way to service these areas globally. 3. Not being an engineer, I do not know how to model, leave room for = extensions nor do I know if this is the time to do so, or in fact,=20 will much of that be done by the DB's and not as much on the WSD side. I = think both, but there seems to be views on both sides.=20 I think the protocol is really super=85I ask for more response from = those who may still be on the reflector,=20 and or involved on their own for guidance and input. Sincerely, Nancy =93He who breaks a thing to find out what it is, has left the path of = wisdom.=94 J.R.R. Tolkien= --Apple-Mail=_C9405ABD-E284-4BAF-BF88-A7E2CC37D3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I = just can't help myself, here are my thoughts:

1. Do = we, by combining use cases, leave a hole that needs to be plugged by the = FCC regulations?
2. In the FCC NPRM that is out now, "remote" = is mentioned, as well as in supporting documents, "rural and remote", = have we addressed remote as a use
case and should we? To me it = seems that we should for there needs to be an inexpensive way to service = these areas globally.
3. Not being an engineer, I do not know = how to model, leave room for extensions nor do I know if this is the = time to do so, or in fact, 
will much of that be done by = the DB's and not as much on the WSD side. I think both, but there seems = to be views on both sides. 

I think the = protocol is really super=85I ask for more response from those who may = still be on the reflector, 
and or involved on their own = for guidance and input.

Sincerely, = Nancy

=93=94
= --Apple-Mail=_C9405ABD-E284-4BAF-BF88-A7E2CC37D3C7-- From amancuso@google.com Thu Jan 10 09:19:39 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D2221F8A0C for ; Thu, 10 Jan 2013 09:19:39 -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 F-Wd-9JDXovA for ; Thu, 10 Jan 2013 09:19:38 -0800 (PST) Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3394121F8935 for ; Thu, 10 Jan 2013 09:19:38 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id d16so562742vcd.19 for ; Thu, 10 Jan 2013 09:19:37 -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=qTwhRATDcHHtZCmfs+urFbg0dxZwmtfDW/6j3acINUY=; b=T6EEo1a1z3oBdDKyMwhJd1tudhoKnfFzQ4SCeD7DwcVyw8K8QlVC5j4EQtcWi+uRh9 x30EGv5srh5Vod+StZE0/tnK5P5qQffM+o+JDQzIjzHzPKpH8SODlObHEGGUqPhruSwY fFOnP2GuQzXC16eCSmBJ8EMQnGr5w5BjlcCSKy2q9VgYGyd2rvK39V4en/ptyQFfE94V fLzLVa6ju+yQUF4ChVb10NqhuIzmNn1k2E3Zk1hg8xfFAcP40J8+ChC8aWZFv7VtBmKp XwMqVJWBJSs8uG5JGAxQXyBkkF2eU9oEQPgZBDsgohsNKMlXZS43K2LbfayyJz3ZeIk3 Wtpg== 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=qTwhRATDcHHtZCmfs+urFbg0dxZwmtfDW/6j3acINUY=; b=LmraxH7fDRDuJDcu1fGZcPPCjcL628OYuKKFSwt+jQQKX+sPZGUpUsjN/yqD/zc2Tl Qz1CYAzkPL4Xq+N3K2ZPkGeOM8PMXW+BxnXzdwOzXNW43BG4gvDxtw0Hd+2slyXryG70 LGXSqjQx4KPeKJz2iX7D81dCiDugFkQUxc969uvFlX8ohbH9pmOu3spMlwzLgOD7WKgK pymbW00Np/w9T3/usy02/L2DCQ3wlYlj9Oh8aKwFIX57l16joMEVKzLZa7tnC3dZVJk5 31tkMkWuJQCTeg6BDMqkeN03XxZJA0O8+7q5SkgDLYv6CeoGDd6ptDseaTc4K1rpdh59 evKg== MIME-Version: 1.0 Received: by 10.52.172.195 with SMTP id be3mr81769572vdc.54.1357838377448; Thu, 10 Jan 2013 09:19:37 -0800 (PST) Received: by 10.220.253.66 with HTTP; Thu, 10 Jan 2013 09:19:37 -0800 (PST) In-Reply-To: <5B78FA04-8033-4D92-82CB-D4FBD2E79C25@earthlink.net> References: <5B78FA04-8033-4D92-82CB-D4FBD2E79C25@earthlink.net> Date: Thu, 10 Jan 2013 09:19:37 -0800 Message-ID: From: Anthony Mancuso To: Nancy Bravin Content-Type: multipart/alternative; boundary=bcaec51b14cd26730504d2f262f4 X-Gm-Message-State: ALoCoQkhYeVZLVq21V9szwtyeW6WQvV3siNzXV4GCeDYS6WVIBYsZIcWMcSzTg8jsgdmskLAe25RZ4CqsrkXYN4Kw91P1L4zEu9XbJI1zxiKwQZN0gM7vIZTS618FhZw7dgEaE50WAlKdld9/tjxWIojl1I2LooPih6iyp856QcF3Ba/3EWKzZTGqC3lou4Sy7h0BsoNIplk Cc: paws@ietf.org Subject: Re: [paws] what is missing and does it matter? 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, 10 Jan 2013 17:19:39 -0000 --bcaec51b14cd26730504d2f262f4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Nancy, I've edited the latest working draft (not yet posted to IETF while I wait for other comments): "There are many potential use cases for white space spectrum - for example, providing broadband Internet access in urban and densely-populated hotspots as well as rural and remote, underserved areas." and "There are a number of common scenarios in which a master white space device will act as proxy or mediator for one or more slave devices using its connection to the Internet to query the database for available spectrum for itself and for one or more slave devices. These slave devices may be fixed or mobile, in close proximity with each other (indoor network or urban hotspot), or at a distance (rural or remote WAN)." I hope these changes help address some of your concerns. Also, since rural and remote WANs and the other use cases listed share a common architecture and protocol messages, I grouped them together (following Pete Resnik's suggestions). Tony On Wed, Jan 9, 2013 at 11:58 PM, Nancy Bravin wrote= : > I just can't help myself, here are my thoughts: > > 1. Do we, by combining use cases, leave a hole that needs to be plugged b= y > the FCC regulations? > 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as in > supporting documents, "rural and remote", have we addressed remote as a u= se > case and should we? To me it seems that we should for there needs to be a= n > inexpensive way to service these areas globally. > 3. Not being an engineer, I do not know how to model, leave room for > extensions nor do I know if this is the time to do so, or in fact, > will much of that be done by the DB's and not as much on the WSD side. I > think both, but there seems to be views on both sides. > > I think the protocol is really super=85I ask for more response from those > who may still be on the reflector, > and or involved on their own for guidance and input. > > Sincerely, Nancy > > =93He who breaks a thing to find out what it is, has left the path of > wisdom. > =94 > J.R.R. Tolkien > --bcaec51b14cd26730504d2f262f4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Nancy,

I&#= 39;ve edited the latest working draft (not yet posted to IETF while I wait = for other comments):

"There are many potential use cases for white space spectrum - fo= r example, providing broadband Internet access in urban and densely-populat= ed hotspots as well as rural and remote, underserved areas."

and

"There are a number of common scenarios in wh= ich a master white space device will act as proxy or mediator for one or mo= re slave devices using its connection to the Internet to query the database= for available spectrum for itself and for one or more slave devices. These= slave devices may be fixed or mobile, in close proximity with each other (= indoor network or urban hotspot), or at a distance (rural or remote WAN).&q= uot;

I hope these changes help address some of your concerns. Also, s= ince rural and remote WANs and the other use cases listed share a common ar= chitecture and protocol messages, I grouped them together (following Pete R= esnik's suggestions).

Tony




On Wed, Jan 9, 2013 at 11:58 PM, Nancy Bravin <nbravin@earthlink.net> wrote:
I just can't help myself, here are = my thoughts:

1. Do we, by combining use cases, leave a h= ole that needs to be plugged by the FCC regulations?
2. In the FC= C NPRM that is out now, "remote" is mentioned, as well as in supp= orting documents, "rural and remote", have we addressed remote as= a use
case and should we? To me it seems that we should for there needs to b= e an inexpensive way to service these areas globally.
3. Not bein= g an engineer, I do not know how to model, leave room for extensions nor do= I know if this is the time to do so, or in fact,=A0
will much of that be done by the DB's and not as much on the WSD s= ide. I think both, but there seems to be views on both sides.=A0
=
I think the protocol is really super=85I ask for more respon= se from those who may still be on the reflector,=A0
and or involved on their own for guidance and input.

--bcaec51b14cd26730504d2f262f4-- From peter@spectrumbridge.com Thu Jan 10 13:37:55 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E49921F8525 for ; Thu, 10 Jan 2013 13:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 2Fd3stISl+SJ for ; Thu, 10 Jan 2013 13:37:54 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id BCBFE21F886B for ; Thu, 10 Jan 2013 13:37:51 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 10 Jan 2013 16:37:50 -0500 From: Peter Stanforth To: Nancy Bravin , Anthony Mancuso , Gabor Bajko Date: Thu, 10 Jan 2013 16:37:48 -0500 Thread-Topic: [paws] what is missing and does it matter? Thread-Index: Ac3verznjNV/g7pQQ+2tn6Laa7KXfQ== Message-ID: In-Reply-To: <5B78FA04-8033-4D92-82CB-D4FBD2E79C25@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD149DD351B0peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] what is missing and does it matter? 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, 10 Jan 2013 21:37:55 -0000 --_000_CD149DD351B0peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I ask this question in ignorance of how IETF works. In the last 3 months the FCC has published NPRM (notice of proposed rule ma= king) for 2 new spectrum sharing =96 white space bands. Specifically 4.9GHz= and 3.5GHz. In the case of the former they did not say much about how shar= ing was to be accomplished but in the 3.5GHz NPRM they introduce some new c= oncepts, like secondary and tertiary use. So how far do we want to go with the PAWS requirements? Personally I would = prefer we create a solution for TVWS and then see what changes or additions= are required by new TVWS regulations or regulations in new bands. Otherwis= e I fear we will never get anything done. But is seems there is a bias towa= rds trying to get this completely right the first time and have something t= hat is going to cover all the options. I want to try to make constructive c= omments on the document but I ask for some guidance on where we draw the li= ne on scope. Thanks, Peter S. From: Nancy Bravin > Date: Thursday, January 10, 2013 2:58 AM To: Anthony Mancuso >, Gabo= r Bajko > Cc: "paws@ietf.org" > Subject: [paws] what is missing and does it matter? I just can't help myself, here are my thoughts: 1. Do we, by combining use cases, leave a hole that needs to be plugged by = the FCC regulations? 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as in su= pporting documents, "rural and remote", have we addressed remote as a use case and should we? To me it seems that we should for there needs to be an = inexpensive way to service these areas globally. 3. Not being an engineer, I do not know how to model, leave room for extens= ions nor do I know if this is the time to do so, or in fact, will much of that be done by the DB's and not as much on the WSD side. I th= ink both, but there seems to be views on both sides. I think the protocol is really super=85I ask for more response from those w= ho may still be on the reflector, and or involved on their own for guidance and input. Sincerely, Nancy =93He who breaks a thing to find out what it is, has left the path of wisdo= m.=94 J.R.R. Tolkien --_000_CD149DD351B0peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I ask this question in ignoranc= e of how IETF works.
In the last 3 months the FCC has published N= PRM (notice of proposed rule making) for 2 new spectrum sharing =96 white s= pace bands. Specifically 4.9GHz and 3.5GHz. In the case of the former they = did not say much about how sharing was to be accomplished but in the 3.5GHz= NPRM they introduce some new concepts, like secondary and tertiary use.
So how far do we want to go with the PAWS requirements? Personally = I would prefer we create a solution for TVWS and then see what changes or a= dditions are required by new TVWS regulations or regulations in new bands. = Otherwise I fear we will never get anything done. But is seems there is a b= ias towards trying to get this completely right the first time and have som= ething that is going to cover all the options. I want to try to make constr= uctive comments on the document but I ask for some guidance on where we dra= w the line on scope.
Thanks,
Peter S.

From: Nancy Bravin <nbravin@earthlink.net>
Date: Thursday, January 10, 2013 2:58 = AM
To: Anthony Mancuso <amancuso@google.com>, Gabor Bajko= <Gabor.Bajko@nokia.com>=
Cc: "paws@ietf.org" <p= aws@ietf.org>
Subject: [= paws] what is missing and does it matter?

I just can't help myself, here are my thoughts:

1. Do we, by combining use cases, leave a hole that nee= ds to be plugged by the FCC regulations?
2. In the FCC NPRM that = is out now, "remote" is mentioned, as well as in supporting docum= ents, "rural and remote", have we addressed remote as a use
=
case and should we? To me it seems that we should for there needs to b= e an inexpensive way to service these areas globally.
3. Not bein= g an engineer, I do not know how to model, leave room for extensions nor do= I know if this is the time to do so, or in fact, 
will much= of that be done by the DB's and not as much on the WSD side. I think both,= but there seems to be views on both sides. 

= I think the protocol is really super=85I ask for more response from those w= ho may still be on the reflector, 
and or involved on their = own for guidance and input.

Sincerely, Nancy
=

--_000_CD149DD351B0peterspectrumbridgecom_-- From nbravin@earthlink.net Thu Jan 10 15:00:09 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9403221F84F1 for ; Thu, 10 Jan 2013 15:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rR7IsS0VHjmL for ; Thu, 10 Jan 2013 15:00:08 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3834521F8497 for ; Thu, 10 Jan 2013 15:00:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=JN66GOoKh16W0RcfOXKiqSH1OEHEgDQtRH66vt0U30kpLjsONCtkmAe8GsSmYdm3; 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-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TtR5u-0005rB-6y; Thu, 10 Jan 2013 17:59:30 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0BF0581B-714A-4C93-A427-6284DCCD7302" From: Nancy Bravin In-Reply-To: Date: Thu, 10 Jan 2013 14:59:27 -0800 Message-Id: <4C848C64-4E47-47F9-8C3A-1FC4A2A793B5@earthlink.net> References: To: Peter Stanforth , Gabor Bajko , Pete Resnick X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8610ebe66be90b88c4e660ed5121813dbb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] what is missing and does it matter? 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, 10 Jan 2013 23:00:09 -0000 --Apple-Mail=_0BF0581B-714A-4C93-A427-6284DCCD7302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I can give no guidance on scope, but if creating a solution for TVWS = allows for us to not have to continually change what has been done, to the ability to wait until guidance comes with say spectrum sharing, new = FCC rules in the NPRM now, or in the future, then I agree that my comments are probably looking to solve some issues that we do not = have to at this point if we address things as solutions to TVWS.=20 Sincerely, Nancy On Jan 10, 2013, at 1:37 PM, Peter Stanforth wrote: > I ask this question in ignorance of how IETF works. > In the last 3 months the FCC has published NPRM (notice of proposed = rule making) for 2 new spectrum sharing =96 white space bands. = Specifically 4.9GHz and 3.5GHz. In the case of the former they did not = say much about how sharing was to be accomplished but in the 3.5GHz NPRM = they introduce some new concepts, like secondary and tertiary use. > So how far do we want to go with the PAWS requirements? Personally I = would prefer we create a solution for TVWS and then see what changes or = additions are required by new TVWS regulations or regulations in new = bands. Otherwise I fear we will never get anything done. But is seems = there is a bias towards trying to get this completely right the first = time and have something that is going to cover all the options. I want = to try to make constructive comments on the document but I ask for some = guidance on where we draw the line on scope. > Thanks, > Peter S. >=20 > From: Nancy Bravin > Date: Thursday, January 10, 2013 2:58 AM > To: Anthony Mancuso , Gabor Bajko = > Cc: "paws@ietf.org" > Subject: [paws] what is missing and does it matter? >=20 > I just can't help myself, here are my thoughts: >=20 > 1. Do we, by combining use cases, leave a hole that needs to be = plugged by the FCC regulations? > 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as = in supporting documents, "rural and remote", have we addressed remote as = a use > case and should we? To me it seems that we should for there needs to = be an inexpensive way to service these areas globally. > 3. Not being an engineer, I do not know how to model, leave room for = extensions nor do I know if this is the time to do so, or in fact,=20 > will much of that be done by the DB's and not as much on the WSD side. = I think both, but there seems to be views on both sides.=20 >=20 > I think the protocol is really super=85I ask for more response from = those who may still be on the reflector,=20 > and or involved on their own for guidance and input. >=20 > Sincerely, Nancy >=20 > =93He who breaks a thing to find out what it is, has left the path of = wisdom.=94 > J.R.R. Tolkien --Apple-Mail=_0BF0581B-714A-4C93-A427-6284DCCD7302 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I can = give no guidance on scope, but if creating a solution for TVWS allows = for us to not have to continually change what has been done, to
the = ability to wait until guidance comes with say spectrum sharing, new FCC = rules in the NPRM now, or in the future, then I agree that
my = comments are probably looking to solve some issues that we do not have = to at this point if we address things as solutions to = TVWS. 

Sincerely, = Nancy

On Jan = 10, 2013, at 1:37 PM, Peter Stanforth wrote:

From: Nancy Bravin <nbravin@earthlink.net>
Date: Thursday, January 10, 2013 = 2:58 AM
To: Anthony Mancuso = <amancuso@google.com>, = Gabor Bajko <Gabor.Bajko@nokia.com>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] what is missing and = does it matter?

I just can't help myself, here are my thoughts:

1. Do we, by combining use cases, leave a hole that = needs to be plugged by the FCC regulations?
2. In the FCC NPRM = that is out now, "remote" is mentioned, as well as in supporting = documents, "rural and remote", have we addressed remote as a = use
case and should we? To me it seems that we should for = there needs to be an inexpensive way to service these areas = globally.
3. Not being an engineer, I do not know how to = model, leave room for extensions nor do I know if this is the time to do = so, or in fact, 
will much of that be done by the DB's = and not as much on the WSD side. I think both, but there seems to be = views on both sides. 

I think the protocol = is really super=85I ask for more response from those who may still be on = the reflector, 
and or involved on their own for guidance = and input.

Sincerely, = Nancy

=93 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:13:50 -0000 --f46d0401240b51ac6304d309c555 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In response to earlier comments, I also updated my working use case and requirements doc to make it clear that the mention of WI-Fi in the backhaul use case was intended as an an example, and was non-exclusive, as follows: "In this use case, an Internet connectivity service is provided to users over a common wireless standard, such as Wi-Fi, with a white space master/slave network providing backhaul connectivity to the Internet. Note that Wi-Fi is referenced in Figure 4 and the following discussion, but any other technology can be substituted in its place." On Thu, Jan 10, 2013 at 9:19 AM, Anthony Mancuso wrote= : > Hi Nancy, > > I've edited the latest working draft (not yet posted to IETF while I wait > for other comments): > > "There are many potential use cases for white space spectrum - for > example, providing broadband Internet access in urban and densely-populat= ed > hotspots as well as rural and remote, underserved areas." > > and > > "There are a number of common scenarios in which a master white space > device will act as proxy or mediator for one or more slave devices using > its connection to the Internet to query the database for available spectr= um > for itself and for one or more slave devices. These slave devices may be > fixed or mobile, in close proximity with each other (indoor network or > urban hotspot), or at a distance (rural or remote WAN)." > > I hope these changes help address some of your concerns. Also, since rura= l > and remote WANs and the other use cases listed share a common architectur= e > and protocol messages, I grouped them together (following Pete Resnik's > suggestions). > > Tony > > > > > On Wed, Jan 9, 2013 at 11:58 PM, Nancy Bravin wrot= e: > >> I just can't help myself, here are my thoughts: >> >> 1. Do we, by combining use cases, leave a hole that needs to be plugged >> by the FCC regulations? >> 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as in >> supporting documents, "rural and remote", have we addressed remote as a = use >> case and should we? To me it seems that we should for there needs to be >> an inexpensive way to service these areas globally. >> 3. Not being an engineer, I do not know how to model, leave room for >> extensions nor do I know if this is the time to do so, or in fact, >> will much of that be done by the DB's and not as much on the WSD side. I >> think both, but there seems to be views on both sides. >> >> I think the protocol is really super=85I ask for more response from thos= e >> who may still be on the reflector, >> and or involved on their own for guidance and input. >> >> Sincerely, Nancy >> >> =93He who breaks a thing to find out what it is, has left the path of >> wisdom. >> =94 >> J.R.R. Tolkien >> > > --f46d0401240b51ac6304d309c555 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
In response to earlier comments, I also updated my working= use case and requirements doc to make it clear that the mention of WI-Fi i= n the backhaul use case was intended as an an example, and was non-exclusiv= e, as follows:

"In this use case, an Internet connectivity servic= e is provided to users over a common wireless standard, such as Wi-Fi, with= a white space master/slave network providing backhaul connectivity to the = Internet. Note that Wi-Fi is referenced in Figure 4 and the following discu= ssion, but any other technology can be substituted in its place."



On Thu, Jan 10, 2013 at 9:19 AM, Anthony Mancuso <amancuso= @google.com> wrote:
Hi Nancy,

I've edited the latest working draft (not yet posted to IETF while I wa= it for other comments):

"T= here are many potential use cases for white space spectrum - for example, p= roviding broadband Internet access in urban and densely-populated hotspots = as well as rural and remote, underserved areas."

a= nd

"There are a number of common scenarios in which a master white space= device will act as proxy or mediator for one or more slave devices using i= ts connection to the Internet to query the database for available spectrum = for itself and for one or more slave devices. These slave devices may be fi= xed or mobile, in close proximity with each other (indoor network or urban = hotspot), or at a distance (rural or remote WAN)."

I= hope these changes help address some of your concerns. Also, since rural a= nd remote WANs and the other use cases listed share a common architecture a= nd protocol messages, I grouped them together (following Pete Resnik's = suggestions).

Tony


=


On Wed, Jan 9, 2013 at 11:58 PM, Nancy Bravin <nbravin@earthlink.net> wrote:
I just can't help myself, here are = my thoughts:

1. Do we, by combining use cases, leave a h= ole that needs to be plugged by the FCC regulations?
2. In the FC= C NPRM that is out now, "remote" is mentioned, as well as in supp= orting documents, "rural and remote", have we addressed remote as= a use
case and should we? To me it seems that we should for there needs to b= e an inexpensive way to service these areas globally.
3. Not bein= g an engineer, I do not know how to model, leave room for extensions nor do= I know if this is the time to do so, or in fact,=A0
will much of that be done by the DB's and not as much on the WSD s= ide. I think both, but there seems to be views on both sides.=A0
=
I think the protocol is really super=85I ask for more respon= se from those who may still be on the reflector,=A0
and or involved on their own for guidance and input.


--f46d0401240b51ac6304d309c555-- From peter@spectrumbridge.com Fri Jan 11 13:28:21 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523FB21F892C for ; Fri, 11 Jan 2013 13:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 zji1RFcsuwVL for ; Fri, 11 Jan 2013 13:28:20 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id EE68C21F8903 for ; Fri, 11 Jan 2013 13:28:19 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 11 Jan 2013 16:28:19 -0500 From: Peter Stanforth To: "paws@ietf.org" Date: Fri, 11 Jan 2013 16:28:21 -0500 Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt Thread-Index: Ac3wQpLqoLPzmWMEQKSb1yg98+mmBg== Message-ID: In-Reply-To: <20121221171051.15437.46207.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.2.5.121010 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD15ED96527Bpeterspectrumbridgecom_" MIME-Version: 1.0 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: Fri, 11 Jan 2013 21:28:21 -0000 --_000_CD15ED96527Bpeterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First of all I apologize for taking so long to review this. Good Job! Whi= le I could poke at a couple of areas I like the fact that this is concise a= nd to the point so I would much prefer to leave it alone and move on. Regards, Peter S. From: "internet-drafts@ietf.org" > Date: Friday, December 21, 2012 12:10 PM To: "i-d-announce@ietf.org" > Cc: "paws@ietf.org" > Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.= txt 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 Gro= up 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-rqmt= s 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/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CD15ED96527Bpeterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
First of all I apologize= for taking so  long to review this.  Good Job! While I could pok= e at a couple of areas I like the fact that this is concise and to the poin= t so I would much prefer to leave it alone and move on.
Regards,<= /div>
Peter S.

From: "internet-draft= s@ietf.org" <internet-dr= afts@ietf.org>
Date: Fri= day, December 21, 2012 12:10 PM
To: "i-d-announce@ietf.org" &= lt;i-d-announce@ietf.org>Cc: "paws@ietf.org" <paws@ietf.org= >
Subject: [paws] I-D Ac= tion: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

=

A New Internet-Draft is available from = the on-line Internet-Drafts directories.
This draft is a work it= em 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
=             &nb= sp;            =  Basavaraj Patil
Filename       &nb= sp;: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
Pages  &n= bsp;        : 27
Date   = ;         : 2012-12-21

Abstract:
   [Editor's Note: This ver= sion is submitted for review.  A final, post-
 &nb= sp; review version is anticipated that will supersede this version].
<= div>
   Portions of the radio spectrum that are ass= igned to a particular use
   but are unused or unoccupi= ed at specific locations and times are
   defined as "w= hite 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 ad= ditional transmissions do not interfere
   with the ass= igned use of the spectrum.  One approach to using white
   space spectrum at a given time and location is to verify spec= trum
   availability with a database that manages spect= rum sharing and
   provides spectrum-availability infor= mation.

   This document describes a num= ber of possible use cases of white space
   spectrum an= d technology as well as a set of requirements for the
  = ; database query protocol.  The concept of white spaces is descri= bed
   along with the problems that need to be addresse= d 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.

<= br>

The IETF datatracker status page for this draf= t is:

There's also a= htmlized version available at:

A diff from the previous version is available at:


Internet-Dra= fts are also available by anonymous FTP at:

_______________________________________________
= paws mailing list

--_000_CD15ED96527Bpeterspectrumbridgecom_-- From nbravin@earthlink.net Fri Jan 11 13:53:25 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD3F21F8A50 for ; Fri, 11 Jan 2013 13:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 YbdTDX5CqaGE for ; Fri, 11 Jan 2013 13:53:24 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6D721F86C9 for ; Fri, 11 Jan 2013 13:53:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZeIyjyU0Q//nmeVIWWGcU1hfabGXYmFTWbp8yWAcXPgrS6lNj9BDUAjuQHMxdB8G; 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-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1TtmXQ-0000pI-Rn; Fri, 11 Jan 2013 16:53:21 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_EFD15096-FF8F-46ED-9D1A-14C6E7570EC5" From: Nancy Bravin In-Reply-To: Date: Fri, 11 Jan 2013 13:53:19 -0800 Message-Id: <76679487-64DE-491F-983D-3ECEE095C9E2@earthlink.net> References: <5B78FA04-8033-4D92-82CB-D4FBD2E79C25@earthlink.net> To: Anthony Mancuso X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86798e1284f6ec8b0378c75e1107a4fbd8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] what is missing and does it matter? 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, 11 Jan 2013 21:53:25 -0000 --Apple-Mail=_EFD15096-FF8F-46ED-9D1A-14C6E7570EC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks Anthony, seems good to me=85yes, lets move on and submit = =85Sincerely, Nancy On Jan 11, 2013, at 1:13 PM, Anthony Mancuso wrote: > In response to earlier comments, I also updated my working use case = and requirements doc to make it clear that the mention of WI-Fi in the = backhaul use case was intended as an an example, and was non-exclusive, = as follows: >=20 > "In this use case, an Internet connectivity service is provided to = users over a common wireless standard, such as Wi-Fi, with a white space = master/slave network providing backhaul connectivity to the Internet. = Note that Wi-Fi is referenced in Figure 4 and the following discussion, = but any other technology can be substituted in its place." >=20 >=20 >=20 > On Thu, Jan 10, 2013 at 9:19 AM, Anthony Mancuso = wrote: > Hi Nancy, >=20 > I've edited the latest working draft (not yet posted to IETF while I = wait for other comments): >=20 > "There are many potential use cases for white space spectrum - for = example, providing broadband Internet access in urban and = densely-populated hotspots as well as rural and remote, underserved = areas." >=20 > and >=20 > "There are a number of common scenarios in which a master white space = device will act as proxy or mediator for one or more slave devices using = its connection to the Internet to query the database for available = spectrum for itself and for one or more slave devices. These slave = devices may be fixed or mobile, in close proximity with each other = (indoor network or urban hotspot), or at a distance (rural or remote = WAN)." >=20 > I hope these changes help address some of your concerns. Also, since = rural and remote WANs and the other use cases listed share a common = architecture and protocol messages, I grouped them together (following = Pete Resnik's suggestions). >=20 > Tony >=20 >=20 >=20 >=20 > On Wed, Jan 9, 2013 at 11:58 PM, Nancy Bravin = wrote: > I just can't help myself, here are my thoughts: >=20 > 1. Do we, by combining use cases, leave a hole that needs to be = plugged by the FCC regulations? > 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as = in supporting documents, "rural and remote", have we addressed remote as = a use > case and should we? To me it seems that we should for there needs to = be an inexpensive way to service these areas globally. > 3. Not being an engineer, I do not know how to model, leave room for = extensions nor do I know if this is the time to do so, or in fact,=20 > will much of that be done by the DB's and not as much on the WSD side. = I think both, but there seems to be views on both sides.=20 >=20 > I think the protocol is really super=85I ask for more response from = those who may still be on the reflector,=20 > and or involved on their own for guidance and input. >=20 > Sincerely, Nancy >=20 > =93He who breaks a thing to find out what it is, has left the path of = wisdom.=94 > J.R.R. Tolkien >=20 >=20 --Apple-Mail=_EFD15096-FF8F-46ED-9D1A-14C6E7570EC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On Jan 11, 2013, at 1:13 PM, Anthony Mancuso = wrote:

In response to earlier comments, I also = updated my working use case and requirements doc to make it clear that = the mention of WI-Fi in the backhaul use case was intended as an an = example, and was non-exclusive, as follows:

"In this use case, an Internet connectivity service = is provided to users over a common wireless standard, such as Wi-Fi, = with a white space master/slave network providing backhaul connectivity = to the Internet. Note that Wi-Fi is referenced in Figure 4 and the = following discussion, but any other technology can be substituted in its = place."



On Thu, Jan 10, 2013 at 9:19 AM, Anthony Mancuso = <amancuso@google.com> wrote:
Hi Nancy,

I've edited the latest working draft (not yet posted to IETF while I = wait for other comments):

"There= are many potential use cases for white space spectrum - for example, = providing broadband Internet access in urban and densely-populated = hotspots as well as rural and remote, underserved areas."

and

"There = are a number of common scenarios in which a master white space device = will act as proxy or mediator for one or more slave devices using its = connection to the Internet to query the database for available spectrum = for itself and for one or more slave devices. These slave devices may be = fixed or mobile, in close proximity with each other (indoor network or = urban hotspot), or at a distance (rural or remote WAN)."

I hope these changes help address some of your = concerns. Also, since rural and remote WANs and the other use cases = listed share a common architecture and protocol messages, I grouped them = together (following Pete Resnik's suggestions).

Tony




On Wed, Jan 9, 2013 at 11:58 PM, Nancy Bravin <nbravin@earthlink.net> = wrote:
I just can't help myself, here are = my thoughts:

1. Do we, by combining use cases, leave = a hole that needs to be plugged by the FCC regulations?
2. In = the FCC NPRM that is out now, "remote" is mentioned, as well as in = supporting documents, "rural and remote", have we addressed remote as a = use
case and should we? To me it seems that we should for there needs = to be an inexpensive way to service these areas globally.
3. = Not being an engineer, I do not know how to model, leave room for = extensions nor do I know if this is the time to do so, or in = fact, 
will much of that be done by the DB's and not as much on the WSD = side. I think both, but there seems to be views on both = sides. 

I think the protocol is really = super=85I ask for more response from those who may still be on the = reflector, 
and or involved on their own for guidance and = input.

Sincerely, Nancy

J.R.R. Tolkien



= --Apple-Mail=_EFD15096-FF8F-46ED-9D1A-14C6E7570EC5-- From Gabor.Bajko@nokia.com Mon Jan 14 13:20:16 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FDA21F8B1A for ; Mon, 14 Jan 2013 13:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 462Ywqplq9A7 for ; Mon, 14 Jan 2013 13:20:12 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7321F8AE0 for ; Mon, 14 Jan 2013 13:20:11 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (in-mx.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0ELK8tf014271 for ; Mon, 14 Jan 2013 23:20:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jan 2013 23:20:08 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.102]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0318.003; Mon, 14 Jan 2013 21:20:08 +0000 From: To: Thread-Topic: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt Thread-Index: AQHN8EKXcsmMjx9ol0eRolVSkkHZwJhJVilQ Date: Mon, 14 Jan 2013 21:20:07 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2013 21:20:08.0966 (UTC) FILETIME=[EE40DA60:01CDF29C] X-Nokia-AV: Clean 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: Mon, 14 Jan 2013 21:20:16 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for everyone who reviewed the draft. It seems the draft is acceptabl= e as it is, so let's go for the AD review. Tony already mentioned that he made some minor wording changes to the draft= to capture Nancy's comments, once Tony uploads the new version, we'll ask = our AD to review it again. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Peter Stanforth Sent: Friday, January 11, 2013 1:28 PM To: paws@ietf.org Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts= -09.txt First of all I apologize for taking so long to review this. Good Job! Whi= le I could poke at a couple of areas I like the fact that this is concise a= nd to the point so I would much prefer to leave it alone and move on. Regards, Peter S. From: "internet-drafts@ietf.org" > Date: Friday, December 21, 2012 12:10 PM To: "i-d-announce@ietf.org" > Cc: "paws@ietf.org" > Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.= txt 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 Gro= up of the IETF. Title : Protocol to Access White Space (PAWS) Dat= abase: Use Cases and Requirements Author(s) : Anthony Mancuso Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqm= ts-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-rqmt= s 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/ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for everyone who r= eviewed the draft. It seems the draft is acceptable as it is, so let’= s go for the AD review.

Tony already mentioned th= at he made some minor wording changes to the draft to capture Nancy’s= comments, once Tony uploads the new version, we’ll ask our AD to review it again.

 <= /p>

- =          Gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter Stanforth
Sent: Friday, January 11, 2013 1:28 PM
To: paws@ietf.org
Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecase= s-rqmts-09.txt

 

First of all I apologize fo= r taking so  long to review this.  Good Job! While I could poke a= t a couple of areas I like the fact that this is concise and to the point so I would much prefer to leave it alone and move on.

Regards,<= /p>

Peter S.<= /p>

 

From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
Date: Friday, December 21, 2012 12:10 PM
To: "i-d-announce@ietf= .org" <i-d-announce@ie= tf.org>
Cc: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rq= mts-09.txt

 

 

A New Internet-Draft is ava= ilable from the on-line Internet-Drafts directories.

This draft is a work item o= f the Protocol to Access WS database Working Group of the IETF.<= /span>

 

            = ;    Title     &= nbsp;     : Protocol to Access White Space (PAWS) Datab= ase: Use Cases and Requirements

            = ;    Author(s)    &nb= sp;  : Anthony Mancuso

    &nb= sp;            =          Basavaraj Patil<= /o:p>

            = ;    Filename    &nbs= p;   : draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

            = ;    Pages     &= nbsp;     : 27

            = ;    Date     &n= bsp;      : 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 th= e radio spectrum that are assigned to a particular use

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

   defined as &qu= ot;white space."  The concept of allowing additional

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

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

   requirement is= that these additional transmissions do not interfere

   with the assig= ned use of the spectrum.  One approach to using white<= /span>

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

   availability w= ith a database that manages spectrum sharing and

   provides spect= rum-availability information.

 

   This document = describes a number of possible use cases of white space

   spectrum and t= echnology 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 assi= gned 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:

 

There's also a htmlized ver= sion available at:

 

A diff from the previous ve= rsion is available at:

 

 

Internet-Drafts are also av= ailable by anonymous FTP at:

 

___________________________= ____________________

paws mailing list

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Mon Jan 14 13:23:49 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D689321F8AD4 for ; Mon, 14 Jan 2013 13:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.113, 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 nO1yDw3OxTwv for ; Mon, 14 Jan 2013 13:23:44 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 29FDD21F85B4 for ; Mon, 14 Jan 2013 13:23:43 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0ELNW0V011665; Mon, 14 Jan 2013 23:23:35 +0200 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); Mon, 14 Jan 2013 23:17:33 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.102]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0318.003; Mon, 14 Jan 2013 21:17:32 +0000 From: To: , , Thread-Topic: [paws] what is missing and does it matter? Thread-Index: AQHN7whDdbApNAc6tkiwU5LbAcgPCphDF2cAgAZB0iA= Date: Mon, 14 Jan 2013 21:17:31 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E26@008-AM1MPN1-006.mgdnok.nokia.com> References: <5B78FA04-8033-4D92-82CB-D4FBD2E79C25@earthlink.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E26008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jan 2013 21:17:33.0202 (UTC) FILETIME=[91692720:01CDF29C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] what is missing and does it matter? 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, 14 Jan 2013 21:23:50 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E26008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Usually it is a compromise between moving forward and capturing as much as = possible into the current versions. There is no defined recipe for this in = ietf, as far as I know of. A common sense, in my opinion would be to move f= orward with the current set of requirements; then when the FCC and other ru= les on NPRM settle down, we could do an analysis on how much would that cha= nge the current requirements on our protocol, or how many new requirements = it would mean (which would result in a change of existing, or addition of n= ew features) to the protocol. If the delta is significant enough, a new rev= ision of the document can be created (which would progress on its own track= , possibly become a new RFC to update the previous one). - Gabor From: ext Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Thursday, January 10, 2013 1:38 PM To: Nancy Bravin; Anthony Mancuso; Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] what is missing and does it matter? I ask this question in ignorance of how IETF works. In the last 3 months the FCC has published NPRM (notice of proposed rule ma= king) for 2 new spectrum sharing - white space bands. Specifically 4.9GHz a= nd 3.5GHz. In the case of the former they did not say much about how sharin= g was to be accomplished but in the 3.5GHz NPRM they introduce some new con= cepts, like secondary and tertiary use. So how far do we want to go with the PAWS requirements? Personally I would = prefer we create a solution for TVWS and then see what changes or additions= are required by new TVWS regulations or regulations in new bands. Otherwis= e I fear we will never get anything done. But is seems there is a bias towa= rds trying to get this completely right the first time and have something t= hat is going to cover all the options. I want to try to make constructive c= omments on the document but I ask for some guidance on where we draw the li= ne on scope. Thanks, Peter S. From: Nancy Bravin > Date: Thursday, January 10, 2013 2:58 AM To: Anthony Mancuso >, Gabo= r Bajko > Cc: "paws@ietf.org" > Subject: [paws] what is missing and does it matter? I just can't help myself, here are my thoughts: 1. Do we, by combining use cases, leave a hole that needs to be plugged by = the FCC regulations? 2. In the FCC NPRM that is out now, "remote" is mentioned, as well as in su= pporting documents, "rural and remote", have we addressed remote as a use case and should we? To me it seems that we should for there needs to be an = inexpensive way to service these areas globally. 3. Not being an engineer, I do not know how to model, leave room for extens= ions nor do I know if this is the time to do so, or in fact, will much of that be done by the DB's and not as much on the WSD side. I th= ink both, but there seems to be views on both sides. I think the protocol is really super...I ask for more response from those w= ho may still be on the reflector, and or involved on their own for guidance and input. Sincerely, Nancy "He who breaks a thing to find out what it is, has left the path of wisdom.= " J.R.R. Tolkien --_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E26008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peter,

Usually it is a compromis= e between moving forward and capturing as much as possible into the current= versions. There is no defined recipe for this in ietf, as far as I know of. A common sense, in my opinion would be to move forwar= d with the current set of requirements; then when the FCC and other rules o= n NPRM settle down, we could do an analysis on how much would that change t= he current requirements on our protocol, or how many new requirements it would mean (which would result in a change= of existing, or addition of new features) to the protocol. If the delta is= significant enough, a new revision of the document can be created (which w= ould progress on its own track, possibly become a new RFC to update the previous one).

- =          Gabor<= /span>

 <= /p>

From: ext Pete= r Stanforth [mailto:peter@spectrumbridge.com]
Sent: Thursday, January 10, 2013 1:38 PM
To: Nancy Bravin; Anthony Mancuso; Bajko Gabor (Nokia-CIC/SiliconVal= ley)
Cc: paws@ietf.org
Subject: Re: [paws] what is missing and does it matter?

 

I ask this question in igno= rance of how IETF works.

In the last 3 months the FC= C has published NPRM (notice of proposed rule making) for 2 new spectrum sh= aring – white space bands. Specifically 4.9GHz and 3.5GHz. In the case of the former they did not say much about how sharing was to b= e accomplished but in the 3.5GHz NPRM they introduce some new concepts, lik= e secondary and tertiary use.

So how far do we want to go= with the PAWS requirements? Personally I would prefer we create a solution= for TVWS and then see what changes or additions are required by new TVWS regulations or regulations in new bands. Otherwise I fear we w= ill never get anything done. But is seems there is a bias towards trying to= get this completely right the first time and have something that is going = to cover all the options. I want to try to make constructive comments on the document but I ask for some gu= idance on where we draw the line on scope.

Thanks,

Peter S.<= /p>

 

From: Nancy Bravin <nbravin@earthlink.net>
Date: Thursday, January 10, 2013 2:58 AM
To: Anthony Mancuso <amanc= uso@google.com>, Gabor Bajko <Gabor.Bajko@nokia.com>
Cc: "paws@ietf.org" &= lt;paws@ietf.org>
Subject: [paws] what is missing and does it matter?

 

I just can't help myself, h= ere are my thoughts:

 

1. Do we, by combining use = cases, leave a hole that needs to be plugged by the FCC regulations?

2. In the FCC NPRM that is = out now, "remote" is mentioned, as well as in supporting document= s, "rural and remote", have we addressed remote as a use

case and should we? To me i= t seems that we should for there needs to be an inexpensive way to service = these areas globally.

3. Not being an engineer, I= do not know how to model, leave room for extensions nor do I know if this = is the time to do so, or in fact, 

will much of that be done b= y the DB's and not as much on the WSD side. I think both, but there seems t= o be views on both sides. 

 

I think the protocol is rea= lly super…I ask for more response from those who may still be on the = reflector, 

and or involved on their ow= n for guidance and input.

 

Sincerely, Nancy=

 

J.R.R. To= lkien

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476020F9E26008AM1MPN1006mg_-- From internet-drafts@ietf.org Mon Jan 14 14:14:35 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA421F8906; Mon, 14 Jan 2013 14:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 iiALIZtacPBJ; Mon, 14 Jan 2013 14:14:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD4221F8B37; Mon, 14 Jan 2013 14:14:34 -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: <20130114221434.29834.26464.idtracker@ietfa.amsl.com> Date: Mon, 14 Jan 2013 14:14:34 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-10.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, 14 Jan 2013 22:14:35 -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-10.txt Pages : 27 Date : 2013-01-14 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 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From amancuso@google.com Mon Jan 14 14:17:03 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E2A21F8B47 for ; Mon, 14 Jan 2013 14:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=-0.113, 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 JtGgRUSM3cO3 for ; Mon, 14 Jan 2013 14:17:02 -0800 (PST) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4D94B21F8B46 for ; Mon, 14 Jan 2013 14:17:01 -0800 (PST) Received: by mail-la0-f47.google.com with SMTP id fh20so4377032lab.20 for ; Mon, 14 Jan 2013 14:16:58 -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=KJwdqMPtlwqRx+Hr0RTm+6r1H8DZtfzcnD4TJ5teIlM=; b=ODDyalWB1Gn1FoKDslVLPFF07NDzD65D2Fb/GEFi2CoxCq6chN9EM/9U1jhpylfEvY vvy9ENalaDj5uYvokOH4rB1VIN2KYuODwwCEAle9IqqzbGS/3cWVHKovVKja0ZmOQA1I TPdfdAqZ83ddEQtG47BAJGeKrcYeGJKN6zalYBDmrhQqWe+dHq0cW6Oq88qNwulEmvUl LsV6ly/n+TveQPK16GCln8yuS3esQbMZ5X0FshxdlDraV1UYPSIBsE85wfDs3t//CnjO 2cW8T5wc0Ng9+3JrFceXPQ3Y8+oTUZBXplewDPc30MyCvBtGkfr/86ZlBhrWb6viL15O ui7w== 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=KJwdqMPtlwqRx+Hr0RTm+6r1H8DZtfzcnD4TJ5teIlM=; b=gPkHFsw7zFN8K5ZX0bpCsB/ZqP0AfvD4HysKFX3aPqLAEQe2UkECpYmS025LdZUE4r AVbYBwzpe1hoETNHeAfqLUeKvA912WIZSWxJlBV8ghIG5uGhyJUfA1PpgXFuDnqQrz39 gUGKbE9uFwqFOyuVn4t+zOypjOW/DGyE17MoDa3aX0KwN539/U5hpoq3cSGaz3T/3O+j dWv99nc/L/6Xh715Qtc4gfY9odcMwhoQ7sC7ftL/fgkyV/AGoYefbSBgiOho3kNMYBPK zHnQP9X2tEIXwuyRp+A6gY+8ZgiQ+XOB+rwNHR1p23Tx0a6e99eNVctup5wyo77Qsfab Ijqg== MIME-Version: 1.0 Received: by 10.152.123.77 with SMTP id ly13mr28088994lab.4.1358201817924; Mon, 14 Jan 2013 14:16:57 -0800 (PST) Received: by 10.112.39.67 with HTTP; Mon, 14 Jan 2013 14:16:57 -0800 (PST) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> Date: Mon, 14 Jan 2013 14:16:57 -0800 Message-ID: From: Anthony Mancuso To: Gabor Bajko Content-Type: multipart/alternative; boundary=f46d043bda68e4034104d3470034 X-Gm-Message-State: ALoCoQkNuvGytu55bRYs63fV3sYRlo5hOumkMyi9QhDJlH/qgKAWvSXWdpmgbVdzu+WobDwpKnm53xWtEKl7adlsPlln/aX3TkcTj6Jpt1GA7eHly1dquoTRJZcGnYnF3NMp8lhTXi6FUp/Q9vqGVglbMgVw87M+g+bMnRhoONN1KYEB4AH7Myl1Ht8SFpHGfbpVbrjhU6gQ 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: Mon, 14 Jan 2013 22:17:03 -0000 --f46d043bda68e4034104d3470034 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Gabor, I just uploaded v. 10 to IETF for AD review. Thanks to all for their review and comments. Tony On Mon, Jan 14, 2013 at 1:20 PM, wrote: > Thanks for everyone who reviewed the draft. It seems the draft is > acceptable as it is, so let=92s go for the AD review.**** > > Tony already mentioned that he made some minor wording changes to the > draft to capture Nancy=92s comments, once Tony uploads the new version, w= e=92ll > ask our AD to review it again.**** > > ** ** > > **- **Gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Peter Stanforth > *Sent:* Friday, January 11, 2013 1:28 PM > *To:* paws@ietf.org > *Subject:* Re: [paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt**** > > ** ** > > First of all I apologize for taking so long to review this. Good Job! > While I could poke at a couple of areas I like the fact that this is > concise and to the point so I would much prefer to leave it alone and mov= e > on.**** > > Regards,**** > > Peter S.**** > > ** ** > > *From: *"internet-drafts@ietf.org" > *Date: *Friday, December 21, 2012 12:10 PM > *To: *"i-d-announce@ietf.org" > *Cc: *"paws@ietf.org" > *Subject: *[paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt**** > > ** ** > > ** ** > > 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-rq= mts > **** > > ** ** > > 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-= 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 > > --f46d043bda68e4034104d3470034 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Gabor,

I jus= t uploaded v. 10 to IETF for AD review.

Thanks to all for their review and= comments.

Tony


On Mon, Jan 14, 2013 at 1:20 PM, <Gabor.Bajko@nokia.com> wrote:

Thanks for everyone who r= eviewed the draft. It seems the draft is acceptable as it is, so let=92s go= for the AD review.

Tony already mentioned th= at he made some minor wording changes to the draft to capture Nancy=92s com= ments, once Tony uploads the new version, we=92ll ask our AD to review it again.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor<= /span>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Peter Stanforth
Sent: Friday, January 11, 2013 1:28 PM
To: paws@ietf.org=
Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecase= s-rqmts-09.txt

=A0

First of all I apologize for taking so = =A0long to review this. =A0Good Job! While I could poke at a couple of area= s I like the fact that this is concise and to the point so I would much prefer to leave it alone and move on.<= /span>

Regards,

Peter S.

=A0

From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>=
Date: Friday, December 21, 2012 12:10 PM
To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Cc: "paws@ie= tf.org" <paw= s@ietf.org>
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rq= mts-09.txt

=A0

=A0

A New Internet-Draft is available from = the on-line Internet-Drafts directories.

This draft is a work item of the Protoc= ol to Access WS database Working Group of the IETF.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Protocol t= o Access White Space (PAWS) Database: Use Cases and Requirements<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 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=A0=A0Basavaraj Patil=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0=A0: draft-ietf-paw= s-problem-stmt-usecases-rqmts-09.txt

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 27<= u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2012-1= 2-21

=A0

Abstract:

=A0=A0 [Editor's Note: This version= is submitted for review.=A0=A0A final, post-

=A0=A0 review version is anticipated th= at will supersede this version].

=A0

=A0=A0 Portions of the radio spectrum t= hat are assigned to a particular use

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

=A0=A0 defined as "white space.&qu= ot;=A0=A0The concept of allowing additional

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

=A0=A0 technique to "unlock" = existing spectrum for new use.=A0=A0An obvious

=A0=A0 requirement is that these additi= onal transmissions do not interfere

=A0=A0 with the assigned use of the spe= ctrum.=A0=A0One approach to using white

=A0=A0 space spectrum at a given time a= nd location is to verify spectrum

=A0=A0 availability with a database tha= t manages spectrum sharing and

=A0=A0 provides spectrum-availability i= nformation.

=A0

=A0=A0 This document describes a number= of possible use cases of white space

=A0=A0 spectrum and technology as well = as a set of requirements for the

=A0=A0 database query protocol.=A0=A0Th= e concept of white spaces is described

=A0=A0 along with the problems that nee= d to be addressed to enable white

=A0=A0 space spectrum for additional us= es without causing interference to

=A0=A0 currently assigned use.=A0=A0Use= of white space is enabled by querying a

=A0=A0 database that stores information= about spectrum availability at any

=A0=A0 given location and time.<= u>

=A0

=A0

=A0

The IETF datatracker status page for th= is draft is:

=A0

There's also a htmlized version ava= ilable at:

=A0

A diff from the previous version is ava= ilable at:

=A0

=A0

Internet-Drafts are also available by a= nonymous FTP at:

=A0

_______________________________________= ________

paws mailing list<= /p>

=A0


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


--f46d043bda68e4034104d3470034-- From presnick@qti.qualcomm.com Mon Jan 14 14:25:08 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6431821F8AC3 for ; Mon, 14 Jan 2013 14:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Kr+eyjLA0mA7 for ; Mon, 14 Jan 2013 14:25:06 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD5C21F89E5 for ; Mon, 14 Jan 2013 14:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1358200478; x=1389736478; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Bh+HkvNFR7QcTqOoaDHVLZqiubi3luOadqHK8mry6k4=; b=WjfJqK+O/sFHddQlbhuvJO9Y6L3YUHR1zrVh2Y5aC64Ts2uYgdg5dh6o kDhMBgWdmHh0A9ZTps5VUHajqfLIbEfDrAatcUiuwc07RM3jdF0KdYc5W SPkTRtwWbZpSyosVaCXQew9y3EQeWWIHF0wu6LKKPgD/25RTLQ1B0k93u k=; X-IronPort-AV: E=Sophos;i="4.84,468,1355126400"; d="scan'208,217";a="16122218" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 14 Jan 2013 13:54:38 -0800 X-IronPort-AV: E=Sophos;i="4.84,468,1355126400"; d="scan'208,217";a="377232644" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 14 Jan 2013 14:25:04 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 14 Jan 2013 14:25:04 -0800 Message-ID: <50F485BD.7050709@qti.qualcomm.com> Date: Mon, 14 Jan 2013 16:25:01 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Anthony Mancuso References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010106080700060509040204" X-Originating-IP: [172.30.48.1] 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: Mon, 14 Jan 2013 22:25:08 -0000 --------------010106080700060509040204 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I'm on it. On 1/14/13 4:16 PM, Anthony Mancuso wrote: > Gabor, > > I just uploaded v. 10 to IETF for AD review. > > Thanks to all for their review and comments. > > Tony > > > On Mon, Jan 14, 2013 at 1:20 PM, > wrote: > > Thanks for everyone who reviewed the draft. It seems the draft is > acceptable as it is, so let's go for the AD review. > > Tony already mentioned that he made some minor wording changes to > the draft to capture Nancy's comments, once Tony uploads the new > version, we'll ask our AD to review it again. > > - Gabor > > *From:* paws-bounces@ietf.org > [mailto:paws-bounces@ietf.org ] *On > Behalf Of *ext Peter Stanforth > *Sent:* Friday, January 11, 2013 1:28 PM > *To:* paws@ietf.org > *Subject:* Re: [paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt > > First of all I apologize for taking so long to review this. Good > Job! While I could poke at a couple of areas I like the fact that > this is concise and to the point so I would much prefer to leave > it alone and move on. > > Regards, > > Peter S. > > *From: *"internet-drafts@ietf.org > " > > *Date: *Friday, December 21, 2012 12:10 PM > *To: *"i-d-announce@ietf.org " > > > *Cc: *"paws@ietf.org " > > *Subject: *[paws] I-D Action: > draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt > > 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 > > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------010106080700060509040204 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I'm on it.

On 1/14/13 4:16 PM, Anthony Mancuso wrote:
Gabor,

I just uploaded v. 10 to IETF for AD review.

Thanks to all for their review and comments.

Tony


On Mon, Jan 14, 2013 at 1:20 PM, <Gabor.Bajko@nokia.com> wrote:

Thanks for everyone who reviewed the draft. It seems the draft is acceptable as it is, so let’s go for the AD review.

Tony already mentioned that he made some minor wording changes to the draft to capture Nancy’s comments, once Tony uploads the new version, we’ll ask our AD to review it again.

 

-          Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Peter Stanforth
Sent: Friday, January 11, 2013 1:28 PM
To: paws@ietf.org
Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

 

First of all I apologize for taking so  long to review this.  Good Job! While I could poke at a couple of areas I like the fact that this is concise and to the point so I would much prefer to leave it alone and move on.

Regards,

Peter S.

 

From: "internet-drafts@ietf.org" <internet-drafts@ietf.org>
Date: Friday, December 21, 2012 12:10 PM
To: "i-d-announce@ietf.org" <i-d-announce@ietf.org>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

 

 

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:

 

There's also a htmlized version available at:

 

A diff from the previous version is available at:

 

 

Internet-Drafts are also available by anonymous FTP at:

 

_______________________________________________

paws mailing list

 


_______________________________________________
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
  

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------010106080700060509040204-- From amancuso@google.com Tue Jan 15 08:07:41 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1707221F845F for ; Tue, 15 Jan 2013 08:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 CxShMyWL6dZ1 for ; Tue, 15 Jan 2013 08:07:35 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7440A21F8632 for ; Tue, 15 Jan 2013 08:07:34 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id l5so276847lbo.23 for ; Tue, 15 Jan 2013 08:07:33 -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=ZRG68tEFLEIs2b4RjyKK4FY02wEkupP0dzHt8dBwgUM=; b=V6Yi2bLKkSiD2miHOKSZeus3JA4OtDIGJ/fputBYvlvwe0DPh0B+b7r0/qWl8ar9yn /yFLCy/B8+bLVgZtcz8+fVMQ0T8uUgu9qWql08yOs5+ObvQvN+6NoMUYZRZrww7dhzVK rr91i6pxfK2poBjipWykQ1J/YQz1mmCZsCWSgEWjLwedqlcGzTcvJAb8mV/oXqMFiIkU QaEaiCY82EBuQ+FzUGOUz/tmoYyNr0oeilQiXknuMQfvqzu5o0IAFzH2wxiXZsfaJoqk dK3K8X8J7h7f7m/FUoK8Nn/5c9wmEvfurGCBDnakGqj9WNHpH2/fmAsDG3ELU4ti6Xp/ 8HOg== 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=ZRG68tEFLEIs2b4RjyKK4FY02wEkupP0dzHt8dBwgUM=; b=eOYBeGh/4J8E0ov/LOTn70JZoalDozX0FM52rMgiQttcLCa4pcLmNqhlg82aROV1TK 9Sf1UixU62/OSsSEhotXX7xlPSuinx7JQvDPi2/dpI44awQRN+ekLwLz/coaPDA6Rshn NcNAHte8HkzgtKe7M6BMaidzC2LSIDFKyVqLwpOPn+ZJT+qoLEpW9td1+9cGKHcvaq/G /OYGwgyK/0GDxCxjIcxm+3rBmysitrK6KgA3Ml6noLcmn/nzScEMdO0vwvzMCiGtlB9e UarjczeGjMAGXL02hQlJ5HPlNyci0ME2dPoCHYbxp8lS0gSQKYSIDpSbCBRENL3C0Frk jcAw== MIME-Version: 1.0 Received: by 10.112.99.2 with SMTP id em2mr28200711lbb.11.1358266053029; Tue, 15 Jan 2013 08:07:33 -0800 (PST) Received: by 10.112.39.67 with HTTP; Tue, 15 Jan 2013 08:07:32 -0800 (PST) In-Reply-To: <50F485BD.7050709@qti.qualcomm.com> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> <50F485BD.7050709@qti.qualcomm.com> Date: Tue, 15 Jan 2013 08:07:32 -0800 Message-ID: From: Anthony Mancuso To: Pete Resnick Content-Type: multipart/alternative; boundary=f46d0401f97199f0a004d355f5d2 X-Gm-Message-State: ALoCoQmHwMfZc+kEYkG80kq5hem2gbTI3Y0OPtQtpJcNc1shFPAT74mkFeBsQvwwpqlHzxTthhDdiqpdEXPIi3jXM+fXBLn0BqT1D11YHlipa8Y5Wn2FEYqlVIrnujvw78pXHGqStwbneVgH2D59K6b13peoKWIwrB7ldD5zP0crf85XGOdcIyzlkVN2GnSQrz5gnd1rU3io 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: Tue, 15 Jan 2013 16:07:41 -0000 --f46d0401f97199f0a004d355f5d2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Pete, Here are my detailed notes on what I did for version 9 in response to your earlier comments (current version 10 made a few changes in response to Nancy's recent comments). Vince also made changes in the Section 5 Requirements subsections. I thought I had sent this out to the list, but apparently I only sent a summary of the changes I made (as shown in the sumary section below). Sorry for the late post (it's a long one). Tony Note: Use Case & Requirements Doc edits: Summary of what I did to create version 9: Created xml version 09 (copied and pasted and organized 08 text file to create xml version 09) Deleted threat 5 - we don't want to try to protect spectrum. Other threats are mostly man in the middle, which HTTPS will help protect against. 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: consistent use of primary, secondary users, changed "channel" availability references to "spectrum" availability where appropriate changed "the database" to "a database" to avoid implication of one white space databae deleted references specific to TV band and generalized these to radio spectrum eliminated unnecessary references to regulatory domain cleaned up language and syntax throughout. Specific Responses to Pete Resnicks comments: http://www.ietf.org/mail-archive/web/paws/current/msg01316.html 1.1. Introduction to white space Academia and Industry have studied multiple cognitive radio mechanisms for use in such a scenario. "Cognitive Radio" is undefined. -- Added link to article. Spectrum useable for data communications, especially wireless Internet communications, is scarce. ... I think everything up to the last two sentences of this paragraph is unnecessary and doesn't add to the document Any entity that is assigned spectrum that is not densely used may be asked to give it up in one way or another for more intensive use. Providing a mechanism by which additional users share the spectrum with the assigned user is attractive in many bands in many countries. That's fine -- made recommended deletion. Television transmission until now has primarily been analog. ... This paragraph and the figure are completely unneeded. -- made recommended deletion The fundamental issue is how to determine for a specific location and specific time if any of the spectrum is available for additional use. ... I'm not sure whether the above is necessary or not. I don't see what it adds. -- Deleted. 1.2.1. In Scope This document applies only to communications required for basic service in TV white spaces. That sentence is just wrong. First, it's worded as if this document is about *communications* in TV white spaces. It's obviously not about that at all; it applies to *database access for discovery of whitespace allocations*. But even there, it's also not at all clear that this document applies only to TV white spaces. This protocol is applicable to any shared spectrum, whether it is coming from TV white space or otherwise. What I think you mean to say is, "This document lays out the requirements for accessing a database of information about available spectrum, with a specific eye to the use case of TV white spaces. Requirements outside of that use case are not accounted for." We don't want to say that this document *can't* be used for other such databases; it just isn't taking those requirements into account. -- Rephrased the sentence to: "This document covers the requirements for a protocol to allow a device to access a database to obtain spectrum availability information. Such a protocol should allow a device to perform the following actions:" 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains, but is not limited to, You say, "not limited to". What other kinds of things might be in there? -- see next response. current information as required by by the regulatory policies... The phrase "as required by regulatory policies" is unneeded. The information in the database might be required by regulators, or it might not. Regulatory policies have nothing to do with the requirements of the protocol. -- rephrased to: "The database is an entity that contains current information about available spectrum at any given location and time as well as other types of information related to spectrum availability and usage." Device Class Identifies classes of devices defined by Regional Regulators, ... Again, "defined by Regional Regulators" should be removed. -- made recommended deletion. including fixed, mobile, portable, etc... May also indicate if the device is indoor or outdoor. Slave Device A device which uses the spectrum made available by a master device, and cannot query the database directly. Do you mean "cannot" or "does not"? In other words, if a device has direct Internet access and is able to communicate with the database, is it by definition a master device? -- Rephrased to: A device that queries the database through a Master Device= . -- Also deleted regulatory reference in definition of White Space Device; rephrased to: "A device that uses white space spectrum as a secondary user. A white space device can be an access point, base station, a portable device, a wireless microphone, or other type of device." 3. Prior Work I didn't find section 3 at all useful. Could someone explain what this adds to the document? An understanding of this did not help me in section 6, which is what I would expect. -- Deleted Section 3. 4. Use cases and protocol services There are many potential use cases that could be considered for the TV white space spectrum. ... So my basic issue with this section (and this paragraph) is that many of the use cases are architecturally identical for purposes of the requirements. I think a good deal of compression could be done in this section. 4.1.1. White space database discovery ... The master device will need to discover a trusted database in the relevant regulatory domain, using the following steps: "Regulatory domain" is unnecessary. -- made recommended deletion 1. The master device is connected to the Internet by any means... That's fine. ...other than using the white space radio. A local regulator may identify exception cases where a master may initialize over white space (e.g. the FCC allows a master to initialize over the TV white space in certain conditions). The rest of this is out of band and not relevant to the protocol. -- made recommended deletion. Optionally the radio device is pre-programmed with the Internet address of at least one trusted database. The device can establish contact with a trusted database using one of the pre-programmed Internet addresses and establish a white space network (as described in one of the following use cases). OK. Optionally the initial query will be made to a listing approved by the national regulator for the domain of operation (e.g. a website either hosted by or under control of the national regulator) which maintains a list of WS databases and their Internet addresses. The query results in the list of databases and their Internet addresses being sent to the master, which then evaluates the response to determine if a trusted database can be identified where the master device is able to register and receive service from the database. The above seems identical to the previous paragraph. Can't this paragraph be removed? -- made recommended deletion 4.1.2. Device registration with trusted Database Registration may be preliminary to creating a radio network using white space; in some regulatory domains, for some device types, it is a prerequisite to the use cases below. The radio network is created by a master device. Before the master device can transmit in white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. The above is confusing to me. What does it mean to create the radio network before transmitting? And again, why is this relevant to the protocol? -- Simplified the above paragraph and removed reference to creating a radio network: "In some regulatory domains, the master device must register with the trusted database before it queries the database for available spectrum. aDifferent regulatory domains may have different device registration requirements." \|/ ---------- | |Database| | .---. /--------- |-|---------| ( ) / \|/ | Master | / \ | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Interne= t ) | / |-----------| \ / +-|----+ (AirIF) ( ) |Master| / (----) | | / +------+ Figure 2: Example illustration of registration requirement in white space use-case Master appears twice is this diagram. Are there two masters in this model? I don't understand what this means. -- removed second master connected through air to other master. A simplified operational scenario showing registration consists of the following steps: 1. The master device must register with its most current and up-to- date information. Typically the master device will register prior to operating in white space for the first time after power up, after changing location by a predetermined distance, and after regular time intervals. Is the above simply an authentication step? -- No, this is simply data transfer. 2. The master device shall provide to the database during registration all information required according to local regulatory requirements. This information may include, but is not limited to, the Device ID, serial number assigned by the manufacturer the device's location, device antenna height above ground, name of the individual or business that owns the device, name of a contact person responsible for the device's operation address for the contact person, email address for the contact person and phone number of the contact person. Is the above to be specified by the protocol, or is this simply a blob of information that has only local meaning? For instance, will the database announce the information it needs for registration, or will the device simply have to know this out of band? I don't see anything in section 6 regarding this. -- Section 5, D1 - D6 show that the protocol must support the transmission of this data (in the protocol specification doc, these are the required fields if the device transmits a registration request message). No requirement for the DB to announce the required information to the device. 3. The database shall respond to the registration request with an acknowledgement code to indicate the success or failure of the registration request. Additional information may be provided according to local regulator requirements. Are there semantics to the acknowldgement code beyond "Registered" and "Not registered"? If so, is the IETF defining those? -- I reworded to show that the acknowledgment occurs on success; else error. The actual values for acknowledgment and error are specified in the protocol doc. 4.2. Use cases 4.2.1. Hotspot: urban Internet connectivity service First let me say that I can find no difference architecturally between this use case and wide-area/rural deployment in 4.2.2. Indeed, the diagrams are almost identical. So I see no need to separate this out into two sections; they should at least be combined. That said: combine use cases 3.2.1 (Urban hotspot), 3.2.2 (rural WAN), 3.2.6 (Mobility), 3.2.7 (Indoor Networking) 3.2.8 (Machine to Machine) In this use case Internet connectivity service is provided in a "hotspot" to local users. Typical deployment scenarios include urban areas where Internet connectivity is provided to local businesses and residents, and campus environments where Internet connectivity is provided to local buildings and relatively small outdoor areas. The above seems unimportant. Whether it's a hotspot, or provider to campus or local buildings, or wide-area/rural is not important to the architecture. They key an Internet access point that wants to talk to devices over whitespace spectrum discovering which spectrum to use by querying the database. -- Rephrased the paragraph and combined uses cases 1 and 2 (urban hotspot and rural WAN). This deployment scenario is typically characterized by multiple masters ... If this is typical, why is only one master shown in the figure. You'd think that would be important to the diagram. However, I suspect it isn't important to the architecture and that this discussion about multiple masters can be removed. -- made recommended deletion to refer to only one master in the simple case depicted. (APs or hotspots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology. Each master/AP has a connection to the Internet and may provide Internet connectivity to other master and slave devices. TDD is undefined. AP is undefined. And again, I see nothing in the above important to the architecture being discussed. -- Deleted use of these terms in the discussion. Figure 3: Slaves are labeled as "device". That's confusing. -- Changed to "slave device". 1. ...A local regulator may identify exception cases where a master may initialize over white space (e.g. the FCC allows a master to initialize over TV white space in certain conditions). This sounds like a different deployment scenario, not the same one. -- deleted referrence to init over WS. 3. The master/AP registers with the trusted database according to regulatory domain requirements (see Section 4.1.2). Regulatory domain requirement are irrelevent. You can strike that part. -- stricken as recommended. 4. ...The complete set of parameters to be provided from the master to the database is specified by the local regulator. No, it's provided by database policy. Local regulators may specify their particular database policy, but that's outside of the protocol. -- deleted reference to regulator policies. 5. If the master/AP has met all regulatory domain requirements (e.g. been previously authenticated, etc)... Is there anything beyond authentication here? Importantly, neither the master nor the database can understand the semantics of "regulatory domain requirements"can they? That's all out of band. -- deleted reference to regulatory requirements. 6. Once the master/AP has met all regulatory domain requirements (e.g. authenticated the WS channel list response message from the database, etc)... Same as above. -- deleted as above. ...the AP selects one or more available WS channels from the list. Prior to initiating transmission, if required by local regulation... It's not "local regulation", it's protocol that would require the answer, right? -- Deleted reference to regulatory domain. 7-13. Except for relaying information about the slaves to the database and how frequencies/channels are determined, isn't everything thing else in 7-13 what a normal device/AP interaction would look like? This can all be reduced to one or two points it seems to me. 4.2.2. Wide-Area or Rural Internet broadband access As I said above, this appears architecturally identical to 4.2.1. A typical deployment scenario is a wide area or rural area, where Internet broadband access is provided to local businesses and residents from a master (i.e., BS) connected to the Internet. BS is undefined. Probably best to define it. :-) -- eliminated this separate treatent of rural WAN (including base stations)= ; -- as noted in Pete's general remarks and later remarks on use cases, consolidated common architectural/topological use cases (hotpots, WAN, mobility, indoor network) into one common case and rewrote the description and tightened up the step. 4.2.3. Offloading: moving traffic to a white space network This example is obfuscated by the mention of "3G" and "YouTube". First of all, there is nothing about 3G that is unique to this scenario; the desire to use white space instead of any kind of more costly internet connection (metered wire service, metered wireless service, metered satellite service) is what's relevant. Second, using a widget or an online service is also irrelevant; the key is that a high-bandwidth or other costly service is to be used. (The mention of "YouTube" is, I think, especially inappropriate.) This entire section could use some rewriting. -- Rewrote and re-drew the figure as recommended. 4.2.4. White space serving as backhaul In this use case Internet connectivity service is provided to users over a more common wireless standard such as Wi-Fi with white space entities providing backhaul connectivity to the Internet. In a typical deployment scenario an end user has a device with a radio such as Wi-Fi. An Internet service provider or a small business owner wants to provide Wi-Fi Internet connectivity service to their customers. The location where Internet connectivity service via Wi-Fi is to be provided is within the coverage area of a white space master (e.g. Hotspot or Wide-Area/Rural network). The service provider installs a white space slave device and connects it to the Wi-Fi access point(s). Wi-Fi access points with an integrated white space slave component may also be used. This deployment scenario is typically characterized by a WS master/AP/BS providing local coverage. The master/AP has a connection to the Internet and provides Internet connectivity to slave devices that are within its coverage area. The WS slave device is 'bridged' to a Wi-Fi network thereby enabling Internet connectivity service to Wi-Fi devices. The WS Master/AP/BS which has some form of Internet connectivity (wired or wireless) queries the database and obtains available channel information. It then provides service using those channels to slave devices which are within its coverage area. Figure 6 shows an example deployment of this scenario. \|/ white \|/ \|/ Wi-Fi \|/ | space | | | | | | |-|----| |--------| |-|---------| |-|------|-| | Wi-Fi| | | | Master | | Slave | | Dev | |Internet|------| (AP/BS) | | Bridge | |------| | | | | | to Wi-Fi | |--------| |-----------| |----------| \|/ | |-|----| | Wi-Fi| | Dev | |------| Figure 6: WS for backhaul The description of this deployment scenario is not well written, and the figure does nothing to help. Aren't the Wi-fi devices supposed to be connected to the slave, and then the slave talks to the master? This needs some help. 4.2.5. Rapid deployed network for emergency scenario ... This approach does in no way imply such organizations for disaster relief must compete on spectrum allocation with other white spaces users, but they can. ... That sentence seems unnecessary. -- deleted sentence as recommended. 4.2.6. Mobility How does this use case differ architecturally from 4.2.1? Why isn't this case just a subcase of 4.2.1, like 4.2.2? -- Agreed. Combined with master/slave whitespace network 4.2.7. Indoor Networking Isn't this just the same as 4.2.1 without geolocation? Again, seems like it could be combined and shortened. -- Agreed Moved into use case 1 5. Problem Statement In Figure 11, note that there could be multiple databases serving white space devices. The databases are country specific since the regulations and available spectrum may vary. Location specific, not country specific, right? It may be that multiple countries share a database, or it may be that a single country has multiple databases for sub-locales, right? The architecture doesn't depend on "country". -- Changed to regulatory specific (location based was mentioned in earlier sentence). The intent here I think was to indicate that different dbs might follow different regluatory domain (country) rules, but the protocol should be independent from them. 5.1. Global applicability The use of TV white space spectrum is currently approved by the FCC in the United States. However regulatory bodies in other countries are also considering similar use of available spectrum. ... Again, the mention of the regulatory bodies here is unnecessary as it doesn't impact this protocol. -- deleted reference 4. Address regulatory requirements - Each country is likely to have regulations that are unique to that country. The messaging interface needs to be flexible to accommodate the specific needs of a regulatory body in the country where the white space device is operating and connecting to the relevant database. I would rewrite this to say: "4. Flexible and extensible data structures - Different databases are likely to have different requirements for the kinds of data required for registration as well as the kinds of data returned with available white space. For instance, different regulatory bodies might require different information to be passed between the database and the device accessing it." Again, don't make the regulatory body part of the problem statement; the need to accommodate different data is the requirement. -- Rewritten as recommended. 5.4. Data model definition ... Use of XML for specifying a data model is an attractive option. The intent is to evaluate the best option that meets the need for use between white space devices and databases. The mention of XML here is premature. Give it as one example (perhaps including JSON as another) if you think you need such an example. -- deleted reference to XML. No need to mention possible data model implementations here. 6. Requirements ---- Asked Vince to look at these. 6.1. Normative Requirements D. Data Model Requirements: D.1: The Data Model MUST support specifying the location of the WSD, the uncertainty in meters, the height & its uncertainty, and confidence in percentage of the location determination. ... "Location" in the above is ambiguous. You mean the "geographic location", right? --changed to geolocation. ...The Data Model MUST support both North American Datum of 1983 and WGS84. Neither of these has a reference. Also, if NAD is really a requirement, shouldn't there be others listed? D.2: The Data Model MUST support specifying the regulatory domain and its corresponding data requirements. That is poorly written. I don't understand what needs to go in a protocol from the above. Don't you just mean that the Data Model MUST be extensible? D.3: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. The Data Model MUST support specifying information about the type of RAT of the transmitter device. What sort of data is an ID? You probably need to mention that. Also "RAT" is undefined. P. Protocol Requirements: P.1: The protocol MUST provide a mechanism to enable WSD discovery. In some environments, a listing of the approved white space databases is maintained by the national regulator. The protocol MUST support discovery of a database using a listing approved by a national regulator. The "national regulator" portion of the requirement is not the requirement. What is it about the list a national regulator provides that is different, protocol-wise, from any other list from which the WSD is discovered? P.3: The protocol MUST support determination of regulatory domain governing its current location. I don't know what that requirement means. P.8: The protocol MUST support the master device registering with the database. What is "registering" independent of authentication/authorization? P.10: The protocol MUST support a channel query request from the master device to the database. The channel query request message MUST include parameters as required by local regulatory requirement. These parameters MAY include any of the parameters and attributes required to be supported in the Data Model Requirements. Strike the second sentence. Unnecessary. 6.2. Non-normative requirements I don't understand what a non-normative requirement is. Are these just pre-requisites? Please explain. I'm guessing that the 2119 language in this section is misused, but let me understand what the section is meant to say first. O.4: The master device MUST implement at least one connection method to access the database. The master device MAY contact a database directly for service (e.g. as defined by FCC) or the master device MAY contact a listing server first followed by contact to a database (e.g. as defined by Ofcom). References needed for FCC and Ofcom if you insist on noting them. (I don't think they're necessary.) O.5: The master device MUST obtain an indication about the regulatory domain governing operation at its current location, i.e. the master device MUST know if it operates under regulations from FCC, Ofcom, etc... That would be completely out of band, correct? ***************************** TODO: VInce's responses: A couple of thoughts. - If there is an opportunity, we should distinguish between "regulatory domain" and "rule set", where: - regulatory domain is based on where the device is - rule set is a set of requirements that govern device behavior (rather than combining them into a single phrase of "regulatory domain requirements"). A "rule set" may be applicable in multiple domains. In some of Pete's comments, he thinks that how a device behaves within a regulatory domain is out of band. I tend to agree, but it is still useful to have the Database be able to tell the Device which rule set is applicable at its location. Thus, the use-case/requirements should allow for that to be communicated from the Database to the Device. Why? - The Device may know where it is (latitude/longitude), but it most likely will not know which country it's in. - Just knowing the country may not help, if it's one that just approved use of White Space. BUT if a new country (e.g., Brazil) adopts the US rule set, the Database can tell the Device that it can use "FccWhitespace2010" rules, the device will just work. I believe the original doc had some statements like the above, so we don't want to completely delete all text that refer to "regulator". Please also see below for my Normative/Non-Normative answers Perhaps here's an opportunity to say that the database can inform the device of the applicable rule set. A database may support multiple domains and multiple rule sets, so we don't want the phrasing to be too limiting. -- TODO (amancuso): I added ruleset information below in different places. I'll have to go through the doc and see if there are other places where we might want to mention rule set communication by db to device. 5.1. Global applicability The use of TV white space spectrum is currently approved by the FCC in the United States. However regulatory bodies in other countries are also considering similar use of available spectrum. ... Again, the mention of the regulatory bodies here is unnecessary as it doesn't impact this protocol. It does, in the sense that the device needs to know which rule set.... Let's just use WGS84 for the protocol. Delete NAD83. The Database can do any required conversions. --Added in mention of rule set; deleted NAD83 ( http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html) --Added this to the global applicability point 3: "Note that although a device may know its geolocation, it may not know the country or regulatory domain that it is in. Further, even if the device knows this information, it may not be sufficient for the device to know its expected behaviour in its domain of operation since one domain may adopt a rule set for white space device operation from another regulatory domain (Brazil may adopt the "FccWhitespace2010" US rule set). To allow the global use of white space devices in different countries (whatever the regulatory domain), the protocol should support the Database communicating applicable rule set information to the white space device." D.2: The Data Model MUST support specifying the regulatory domain and its corresponding data requirements. That is poorly written. I don't understand what needs to go in a protocol from the above. Don't you just mean that the Data Model MUST be extensible? This somewhat addresses my original point. It's beyond just extensible, since it's beneficial for the Device to know which set of rules to use. Perhaps it's a surprise to Pete, because the need has not been articulated well enough. -- Changed to: "The Data Model MUST support specifying the data and other applicable requirements of the rule set that applies to the white space device at its current location." D.3: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. The Data Model MUST support specifying information about the type of RAT of the transmitter device. What sort of data is an ID? You probably need to mention that. Also "RAT" is undefined. FCC certification ID is an example ID, but there could be other IDs for other certification bodies. Serial Number is also ID. This requirement is really two things: - Fields that identify a device (Serial number, certification IDs) - Fields that describe device characteristics (device class, radio access technology (RAT), etc.) In the Protocol Document, the data model is named "DeviceDescriptor". -- Rewrote: "The Data Model MUST support device description data that identifies a device (serial number, certification IDs, etc.) and describes device characteristics (device class, Radio Access technology (RAT), etc.).= " P. Protocol Requirements: P.1: The protocol MUST provide a mechanism to enable WSD discovery. In some environments, a listing of the approved white space databases is maintained by the national regulator. The protocol MUST support discovery of a database using a listing approved by a national regulator. The "national regulator" portion of the requirement is not the requirement. What is it about the list a national regulator provides that is different, protocol-wise, from any other list from which the WSD is discovered? I would agree with Pete... Just stating that "listing service" is an option is sufficient. There's no requirement that the "listing approved by a national regulator" be used for discovery. It can be use to validate. In other words, the Device can contact a database it knows about and, in parallel, contact the national regulator to make sure that database is listed. This way, we can avoid chicken/egg. The need to contact a listing service is "baked into" the Device. It is just behavior that it needs to implement. It's not part of the protocol. -- I rolled this up into one requirement and reworded to: "The address of a database (e.g., in form 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. The master device may validate the database against a list of approved database maintained by a regulatory body." P.3: The protocol MUST support determination of regulatory domain governing its current location. I don't know what that requirement means. This is explained above with the need to know the set of governing rules. So it must support a Database informing the Device of regulatory domain and governing rules. --- Changed this to: "he protocol must support the database informing the master of the regulatory rules (rule set) that applies to the master device (or any slave devices on whose behalf the master is contacting the database) at the current location or the master (or slave) device(s)." -- Note that in view of the earlier comments, I didn't see a need to mention a db requirement to inform the device of the regulatory body (since the determinative data is the ruleset (may be the current or a "foreign" domain). P.8: The protocol MUST support the master device registering with the database. What is "registering" independent of authentication/authorization? As explained elsewhere, (could back-reference?) this is contact information of owner/operator, device geolocation, antenna characteristics, etc. It is orthogonal to authentication/authorization. I think Pete realized this at the F2F, so it should not be controversial. -- added xref to registration section. P.10: The protocol MUST support a channel query request from the master device to the database. The channel query request message MUST include parameters as required by local regulatory requirement. These parameters MAY include any of the parameters and attributes required to be supported in the Data Model Requirements. Strike the second sentence. Unnecessary Change channel to "available spectrum". -- done here and in next available spectrum response paragraph. 6.2. Non-normative requirements I don't understand what a non-normative requirement is. Are these just pre-requisites? Please explain. I'm guessing that the 2119 language in this section is misused, but let me understand what the section is meant to say first. These are trying to describe the system as a whole, containing requirements / behavior on the Device and Database, independent of the Protocol. That should be explained, then ask for guidance on how to frame these and whether they are needed. -- Added this lead-in sentence: "This section contains functional characteristics of the white space database/devices system, independent of the specific requriements of the protocol for communication between the white space database and devices." O.4: The master device MUST implement at least one connection method to access the database. The master device MAY contact a database directly for service (e.g. as defined by FCC) or the master device MAY contact a listing server first followed by contact to a database (e.g. as defined by Ofcom). References needed for FCC and Ofcom if you insist on noting them. (I don't think they're necessary.) Agree with Pete. Again, this is a requirement on the device. -- deleted references to regulators. OK to talk about device requriements here now that the intent of this section is clearer. O.5: The master device MUST obtain an indication about the regulatory domain governing operation at its current location, i.e. the master device MUST know if it operates under regulations from FCC, Ofcom, etc... That would be completely out of band, correct? Not completely, as I explained above. It is beneficial to have the Device know which rule set to use. In particular, if it gets a ruleset it does not understand, it cannot operate. -- Changed this to "The master device MUST obtain an information on the rule set of the regulatory body that applies to the master device at its current location (and/or the location of any slave devices on whose behalf the master device is operating)." On Mon, Jan 14, 2013 at 2:25 PM, Pete Resnick wr= ote: > ** > I'm on it. > > > On 1/14/13 4:16 PM, Anthony Mancuso wrote: > > Gabor, > > I just uploaded v. 10 to IETF for AD review. > > Thanks to all for their review and comments. > > Tony > > > On Mon, Jan 14, 2013 at 1:20 PM, wrote: > >> Thanks for everyone who reviewed the draft. It seems the draft is >> acceptable as it is, so let=92s go for the AD review. >> >> Tony already mentioned that he made some minor wording changes to the >> draft to capture Nancy=92s comments, once Tony uploads the new version, = we=92ll >> ask our AD to review it again. >> >> >> >> - Gabor >> >> >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *ext Peter Stanforth >> *Sent:* Friday, January 11, 2013 1:28 PM >> *To:* paws@ietf.org >> *Subject:* Re: [paws] I-D Action: >> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt >> >> >> >> First of all I apologize for taking so long to review this. Good Job! >> While I could poke at a couple of areas I like the fact that this is >> concise and to the point so I would much prefer to leave it alone and mo= ve >> on. >> >> Regards, >> >> Peter S. >> >> >> >> *From: *"internet-drafts@ietf.org" >> *Date: *Friday, December 21, 2012 12:10 PM >> *To: *"i-d-announce@ietf.org" >> *Cc: *"paws@ietf.org" >> *Subject: *[paws] I-D Action: >> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt >> >> >> >> >> >> 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-r= qmts >> >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-0= 9 >> >> >> >> A diff from the previous version is available at: >> >> >> http://www.ietf.org/rfcdiff?url2=3Ddraft-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 >> >> > > _______________________________________________ > paws mailing listpaws@ietf.orghttps://www.ietf.org/mailman/listinfo/paws > > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --f46d0401f97199f0a004d355f5d2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Pete,

Here = are my detailed notes on what I did for version 9 in response to your earli= er comments (current version 10 made a few changes in response to Nancy'= ;s recent comments). Vince also made changes in the Section 5 Requirements = subsections. I thought I had sent this out to the list, but apparently I on= ly sent a summary of the changes I made (as shown in the sumary section bel= ow). Sorry for the late post (it's a long one).

Tony Note: Use Case & Requirements Do= c edits:

Summary of what I did to create version 9:

Created xml version 09 (copied and= pasted and organized 08 text file to create xml version 09)
Deleted threat 5 - we don't want to try to protect spectrum. Other thre= ats are mostly man in the middle, which HTTPS will help protect against.
Added language to security considerations t= o match the protocol security considerations that have evolved in the WG.
Clarified protocol normative requirement 6.3 t= o: "The protocol MUST support determination of regulatory domain gover= ning its current location."
Cleaned = up language:
=A0 consistent use of primary, secondary users= ,=A0
=A0 changed "channel" avai= lability references to "spectrum" availability where appropriate<= /div>
=A0 changed "the database" to "a database" to avoid imp= lication of one white space databae
=A0 d= eleted references specific to TV band and generalized these to radio spectr= um
=A0 eliminated unnecessary references to regul= atory domain
=A0 cleaned up language and = syntax throughout.

Specific Responses to Pete Resnicks comments: http://www.ietf.org/mail-arc= hive/web/paws/current/msg01316.html
<= br>

1= .1. =A0Introduction to white space

=A0 =A0Academia and Industry have studied<= /div>
=A0 =A0multiple cognitive radio mechanisms for use in such a scenario.

"= Cognitive Radio" is undefined.=A0
-- Added link to article.

=A0 =A0Spectrum useabl= e for data communications, especially wireless
=A0 =A0Internet communications, is scarce. ...

I think= everything up to the last two sentences of this paragraph is unnecessary a= nd doesn't add to the document

=A0 =A0Any entity that is assigned
=A0 =A0spectrum that is not densely used may be aske= d to give it up in one
=A0 =A0way or anot= her for more intensive use. =A0Providing a mechanism by
=A0 =A0which additional users share the spectr= um with the assigned user is
=A0 =A0attra= ctive in many bands in many countries.
That's fine

-- made recommended deletion.

=A0 =A0Television transmission un= til now has primarily been analog. ...

This pa= ragraph and the figure are completely unneeded.

-- made recommended deletion<= /div>

=A0 =A0= The fundamental issue is how to determine for a specific location and
=
=A0 =A0specific time if any of the spectrum is= available for additional use.
=A0 =A0...
<= br>
I'm not sure whether the above is= necessary or not. I don't see what it adds.

-- Deleted.

1.2.1. =A0In Scope

=A0 =A0Th= is document applies only to communications required for basic
=A0 =A0service in TV white spaces.

That sentence= is just wrong. First, it's worded as if this document is about *commun= ications* in TV white spaces. It's obviously not about that at all; it = applies to *database access for discovery of whitespace allocations*. But e= ven there, it's also not at all clear that this document applies only t= o TV white spaces. This protocol is applicable to any shared spectrum, whet= her it is coming from TV white space or otherwise. What I think you mean to= say is, "This document lays out the requirements for accessing a data= base of information about available spectrum, with a specific eye to the us= e case of TV white spaces. Requirements outside of that use case are not ac= counted for." We don't want to say that this document *can't* = be used for other such databases; it just isn't taking those requiremen= ts into account.

-- Reph= rased the sentence to: "This document covers the requirements for a pr= otocol to allow a device to access a database to obtain spectrum availabili= ty information. Such a protocol should allow a device to perform the follow= ing actions:"

2.2. = =A0Terminology

=A0 =A0Database

=A0 =A0 =A0 In the context of white space and cognitive radio technologies,=
=A0 =A0 =A0 the database is an entity wh= ich contains, but is not limited to,

=
You say, "not limited to". What other kinds of things might be in= there?

-- see next response.

=A0 =A0 =A0 current information as required by by the regulatory policies..= .

= The phrase "as required by regulatory policies" is unneeded. The = information in the database might be required by regulators, or it might no= t. Regulatory policies have nothing to do with the requirements of the prot= ocol.

-- reph= rased to: "The database is an entity that contains current information= about available spectrum at any given location and time as well as other t= ypes of information related to spectrum availability and usage."


=A0 =A0Device Class

=A0 =A0 =A0 Identifies cl= asses of devices defined by Regional Regulators,
=A0 =A0 =A0 ...

Again, "defined by Regional= Regulators" should be removed.

=
-- made recommended deletion.

<= div class=3D"gmail_default">=A0 =A0 =A0 including fixed, mobile, portable, = etc... =A0May also indicate if
=A0 =A0 = =A0 the device is indoor or outdoor.

=A0 =A0= Slave Device

=A0 =A0 =A0 A device which uses the spectrum made available by a= master
=A0 =A0 =A0 device, and cannot query the database directly.

Do you mean "= ;cannot" or "does not"? In other words, if a device has dire= ct Internet access and is able to communicate with the database, is it by d= efinition a master device?

-- Reph= rased to: A device that queries the database through a Master Device.
=

-- Also= deleted regulatory reference in definition of White Space Device; rephrase= d to: "A device that uses white space spectrum as a secondary user. A = white space device can be an access point, base station, a portable device,= a wireless microphone, or other type of device."

3. =A0P= rior Work

I didn't find section 3 at all useful. Could someone explain wh= at this adds to the document? An understanding of this did not help me in s= ection 6, which is what I would expect.

-- Dele= ted Section 3.

4. =A0Use cases and protocol services

=A0 =A0There are many potential use = cases that could be considered for the
= =A0 =A0TV white space spectrum. =A0...
So my basic issue with this section (and this paragraph) is that many of th= e use cases are architecturally identical for purposes of the requirements.= I think a good deal of compression could be done in this section.

4.1.1. = =A0White space database discovery

=A0 =A0... =A0The master device will need t= o discover a
=A0 =A0trusted database in the relevant regula= tory domain, using the
=A0 =A0following s= teps:

"Regulatory domain" is unnecessary.

-- made= recommended deletion

=A0 =A01. =A0The master device is connected to the Inte= rnet by any means...

That= 9;s fine.

=A0 =A0 =A0 =A0...other
=A0 =A0 = =A0 =A0than using the white space radio. =A0A local regulator may identify<= /div>
=A0 =A0 =A0 =A0exception cases where a master = may initialize over white space
=A0 =A0 = =A0 =A0(e.g. the FCC allows a master to initialize over the TV white
<= div class=3D"gmail_default"> =A0 =A0 =A0 =A0space in certain conditions).

The rest of this is out of band = and not relevant to the protocol.
-- made= recommended deletion.

=A0 =A0= Optionally the radio device is pre-programmed with the Internet
=A0 =A0address of at least one trusted database. =A0= The device can establish
=A0 =A0contact with a trusted database using o= ne of the pre-programmed
=A0 =A0Internet = addresses and establish a white space network (as described
=A0 =A0in one of the following use cases).

OK.

=A0 =A0Optionally the initial qu= ery will be made to a listing approved by
=A0 =A0the national regulator for the domain o= f operation (e.g. a website
=A0 =A0either= hosted by or under control of the national regulator) which
=A0 =A0maintains a list of WS databases and their Internet addresses. =A0Th= e
=A0 =A0query results in the list of dat= abases and their Internet addresses
=A0 = =A0being sent to the master, which then evaluates the response to
=A0 =A0determine if a trusted database can be = identified where the master
=A0 =A0device= is able to register and receive service from the database.



The above seems identical to the = previous paragraph. Can't this paragraph be removed?

-- made recommended deletion

4.1.2. = =A0Device registration with trusted Database

=A0 =A0Registration may be preliminary t= o creating a radio network using
=A0 =A0w= hite space; in some regulatory domains, for some device types, it is
<= div class=3D"gmail_default"> =A0 =A0a prerequisite to the use cases below. =A0The radio network is creat= ed
=A0 =A0by a master device. =A0Before t= he master device can transmit in white
= =A0 =A0space spectrum, it must contact a trusted database where the device<= /div>
=A0 =A0can learn if any channels are available= for it to use.

The above is confusing to me. What does it mean to create the= radio network before transmitting? And again, why is this relevant to the = protocol?

-- Simp= lified the above paragraph and removed reference to creating a radio networ= k: "In some regulatory domains, the master device must register with t= he trusted database before it queries the database for available spectrum. = aDifferent regulatory domains may have different device registration requir= ements."


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 \|/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0----------
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 |Database|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 .---. =A0 /---= ------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0|-|---------| =A0 =A0 =A0 =A0 =A0( =A0 =A0 ) /
=A0 =A0 =A0\|/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Master =A0 | = =A0 =A0 =A0 =A0 / =A0 =A0 =A0 \
=A0 =A0 = =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0| =A0 =A0 =A0 =A0 =A0 |=3D= =3D=3D=3D=3D=3D=3D=3D( Internet )
=A0 =A0= =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ =A0 |-----------| =A0 =A0 =A0 = =A0 \ =A0 =A0 =A0 =A0/
=A0 =A0 +-|----+ =A0 (AirIF) =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0( =A0 =A0 =A0)
=A0 =A0 |Master| =A0/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(----)
=A0 =A0 | =A0 =A0 =A0| /
=A0 =A0 +------+

=A0 =A0 Figure 2: Example illus= tration of registration requirement in white
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 space use-c= ase


Master appears twice is this diagram. Are t= here two masters in this model? I don't understand what this means.

-- remo= ved second master connected through air to other master.

=A0 =A0A simplified = operational scenario showing registration consists of
=A0 =A0the following steps:

=A0 =A01. =A0The mas= ter device must register with its most current and up-to-
=A0 =A0 =A0 =A0date information. =A0Typically the master device will regist= er
=A0 =A0 =A0 =A0prior to operating in w= hite space for the first time after power
=A0 =A0 =A0 =A0up, after changing location by a predetermined distance, an= d
=A0 =A0 =A0 =A0after regular time intervals.

Is = the above simply an authentication step?
= -- No, this is simply data transfer.

=A0 =A0= 2. =A0The master device shall provide to the database during
=A0 =A0 =A0 =A0registration all information required ac= cording to local
=A0 =A0 =A0 =A0regulatory requirements. =A0Thi= s information may include, but is
=A0 =A0= =A0 =A0not limited to, the Device ID, serial number assigned by the
<= div class=3D"gmail_default"> =A0 =A0 =A0 =A0manufacturer the device's location, device antenna heigh= t above
=A0 =A0 =A0 =A0ground, name of th= e individual or business that owns the device,
=A0 =A0 =A0 =A0name of a contact person responsible for the device= 9;s operation
=A0 =A0 =A0 =A0address for the contact person,= email address for the contact
=A0 =A0 = =A0 =A0person and phone number of the contact person.

Is the above to be specified by the protocol, = or is this simply a blob of information that has only local meaning? For in= stance, will the database announce the information it needs for registratio= n, or will the device simply have to know this out of band? I don't see= anything in section 6 regarding this.

-- Sect= ion 5, D1 - D6 show that the protocol must support the transmission of this= data (in the protocol specification doc, these are the required fields if = the device transmits a registration request message). No requirement for th= e DB to announce the required information to the device.

=A0 =A0= 3. =A0The database shall respond to the registration request with an
<= div class=3D"gmail_default">=A0 =A0 =A0 =A0acknowledgement code to indicate= the success or failure of the
=A0 =A0 =A0 =A0registration request. =A0Additi= onal information may be provided
=A0 =A0 = =A0 =A0according to local regulator requirements.

Are there semantics to the acknowldgement code beyond "Registered"= ; and "Not registered"? If so, is the IETF defining those?
<= div class=3D"gmail_default">
-- I rew= orded to show that the acknowledgment occurs on success; else error. The ac= tual values for acknowledgment and error are specified in the protocol doc.=

4.2. = =A0Use cases

4.2.1. =A0Hotspot: urban Internet connectivity service

First let me say that I can find no = difference architecturally between this use case and wide-area/rural deploy= ment in 4.2.2. Indeed, the diagrams are almost identical. So I see no need = to separate this out into two sections; they should at least be combined. T= hat said:

combine= use cases 3.2.1 (Urban hotspot), 3.2.2 (rural WAN), 3.2.6 (Mobility), 3.2.= 7 (Indoor Networking) 3.2.8 (Machine to Machine)

=A0 =A0In this use case Internet con= nectivity service is provided in a
=A0 = =A0"hotspot" to local users. =A0Typical deployment scenarios incl= ude urban
=A0 =A0areas where Internet connectivity is pr= ovided to local businesses and
=A0 =A0res= idents, and campus environments where Internet connectivity is
=A0 =A0provided to local buildings and relatively small outdoor areas.

The ab= ove seems unimportant. Whether it's a hotspot, or provider to campus or= local buildings, or wide-area/rural is not important to the architecture. = They key an Internet access point that wants to talk to devices over whites= pace spectrum discovering which spectrum to use by querying the database.

-- Reph= rased the paragraph and combined uses cases 1 and 2 (urban hotspot and rura= l WAN).

=A0 =A0This
=A0 =A0deployment scenario is= typically characterized by multiple masters
=A0 =A0...

If this is typical, why is only one master shown in the figure= . You'd think that would be important to the diagram. However, I suspec= t it isn't important to the architecture and that this discussion about= multiple masters can be removed.

-- made= recommended deletion to refer to only one master in the simple case depict= ed.

=A0 =A0(APs or hotspots) in close proximity, with low antenna height, cel= ls
=A0 =A0with relatively small radius (a few kil= ometers or less), and limited
=A0 =A0numb= ers of available radio channels. =A0Many of the masters/APs are
=A0 =A0assumed to be individually deployed and operated, i.e. there is no
=A0 =A0coordination between many of the ma= sters/APs. =A0The masters/APs in
=A0 =A0t= his scenario use a TDD radio technology. =A0Each master/AP has a
=A0 =A0connection to the Internet and may prov= ide Internet connectivity to
=A0 =A0other= master and slave devices.

TDD is undefined. AP is undefined. And again, I see nothing in the above im= portant to the architecture being discussed.

-- Deleted use of these terms in= the discussion.

=A0 =A0= =A0 =A0 =A0 Figure 3:

Slaves are labeled as "device". That's c= onfusing.
-- Changed to "slave device".
<= div class=3D"gmail_default">
=A0 1. = =A0 ...A local
=A0 =A0 =A0 =A0 regulator = may identify exception cases where a master may
=A0 =A0 =A0 =A0 initialize over white space (e= .g. the FCC allows a master to
=A0 =A0 = =A0 =A0 initialize over TV white space in certain conditions).

This sounds like a different deploym= ent scenario, not the same one.

-- deleted referrence to init over WS.
<= div class=3D"gmail_default">
=A0 =A03. =A0 The master/AP register= s with the trusted database according to
= =A0 =A0 =A0 =A0 regulatory domain requirements (see Section 4.1.2).

Regulatory domain requirement are ir= relevent. You can strike that part.

<= /div>
-- stricken as recommended.

=A0 =A04. =A0 ...The complete set of= parameters to be provided
=A0 =A0 =A0 = =A0 from the master to the database is specified by the local
=A0 =A0 =A0 =A0 regulator.

No, it's provided by database policy. Local re= gulators may specify their particular database policy, but that's outsi= de of the protocol.

-- dele= ted reference to regulator policies.

=
=A0 =A05. =A0 If the master/AP has met a= ll regulatory domain requirements
=A0 =A0 =A0 =A0 (e.g. been previously authenti= cated, etc)...

Is there anything beyond authentication here? Importantly, nei= ther the master nor the database can understand the semantics of "regu= latory domain requirements"can they? That's all out of band.

-- dele= ted reference to regulatory requirements.=A0

=A0 =A06. =A0 Once the master/AP= has met all regulatory domain requirements
=A0 =A0 =A0 =A0 (e.g. authenticated the WS cha= nnel list response message from
=A0 =A0 = =A0 =A0 the database, etc)...

<= div class=3D"gmail_default"> Same as above.

-- deleted as above.

=A0 =A0 =A0 =A0 ...the AP selects one or mo= re available WS
=A0 =A0 =A0 =A0 channels from the list. =A0Pri= or to initiating transmission, if
=A0 =A0= =A0 =A0 required by local regulation...
=
It's not "local regulation", it's protocol that would req= uire the answer, right?

-- Deleted reference to regulatory domain.

=A0 =A07-13.

Except for relaying infor= mation about the slaves to the database and how frequencies/channels are de= termined, isn't everything thing else in 7-13 what a normal device/AP i= nteraction would look like? This can all be reduced to one or two points it= seems to me.

4.2.2. = =A0Wide-Area or Rural Internet broadband access

As I said above, this appears= architecturally identical to 4.2.1.

=A0 =A0= A typical deployment scenario is a wide area or rural area, where
=A0 =A0Internet broadband access is provided to lo= cal businesses and
=A0 =A0residents from a master (i.e., BS) conn= ected to the Internet.

BS is undefined. Probably best to define it. :-)
=

-- eliminated this separate treatent= of rural WAN (including base stations);
= -- as noted in Pete's general remarks and later remarks on use cases, c= onsolidated common architectural/topological use cases (hotpots, WAN, mobil= ity, indoor network) into one common case and rewrote the description and t= ightened up the step.

4.2.3. = =A0Offloading: moving traffic to a white space network

This example is obfusc= ated by the mention of "3G" and "YouTube". First of all= , there is nothing about 3G that is unique to this scenario; the desire to = use white space instead of any kind of more costly internet connection (met= ered wire service, metered wireless service, metered satellite service) is = what's relevant. Second, using a widget or an online service is also ir= relevant; the key is that a high-bandwidth or other costly service is to be= used. (The mention of "YouTube" is, I think, especially inapprop= riate.) This entire section could use some rewriting.

-- Rewr= ote and re-drew the figure as recommended.

4.2.4. =A0White space serving as b= ackhaul

=A0 =A0= In this use case Internet connectivity service is provided to users
=A0 =A0over a more common wireless standard such= as Wi-Fi with white space
=A0 =A0entities providing backhaul connectivit= y to the Internet. =A0In a
=A0 =A0typical= deployment scenario an end user has a device with a radio
=A0 =A0such as Wi-Fi. =A0An Internet service provider or a small business
=A0 =A0owner wants to provide Wi-Fi Intern= et connectivity service to their
=A0 =A0c= ustomers. =A0The location where Internet connectivity service via
=A0 =A0Wi-Fi is to be provided is within the c= overage area of a white space
=A0 =A0mast= er (e.g. =A0Hotspot or Wide-Area/Rural network). =A0The service
=A0 =A0provider installs a white space slave device and connects it to the<= /div>
=A0 =A0Wi-Fi access point(s). =A0Wi-Fi ac= cess points with an integrated white
=A0 = =A0space slave component may also be used. =A0This deployment scenario is
=A0 =A0typically characterized by a WS master/= AP/BS providing local
=A0 =A0coverage. = =A0The master/AP has a connection to the Internet and
=A0 =A0provides Internet connectivity to slave devices that ar= e within its
=A0 =A0coverage area. =A0The WS slave device i= s 'bridged' to a Wi-Fi network
= =A0 =A0thereby enabling Internet connectivity service to Wi-Fi devices. =A0= The
=A0 =A0WS Master/AP/BS which has some form of Internet connectivity (wired<= /div>
=A0 =A0or wireless) queries the database = and obtains available channel
=A0 =A0info= rmation. =A0It then provides service using those channels to slave
=A0 =A0devices which are within its coverage a= rea.

=A0 =A0Figure 6 shows an example deployment of this scenario.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \|/ =A0 =A0 white =A0 = =A0\|/ =A0 =A0\|/ =A0 Wi-Fi \|/
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0space =A0 =A0 | =A0= =A0 =A0| =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0| =A0 =A0 =A0 =A0 |-|-= ---|
=A0 =A0 =A0 =A0|--------| =A0 =A0 = =A0|-|---------| =A0 =A0|-|------|-| =A0 =A0 =A0 | Wi-Fi|
=A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0| =A0 =A0 =A0| Master =A0 =A0| =A0 =A0| =A0= Slave =A0 | =A0 =A0 =A0 | Dev =A0|
=A0 = =A0 =A0 =A0|Internet|------| (AP/BS) =A0 | =A0 =A0| =A0Bridge =A0| =A0 =A0 = =A0 |------|
=A0 =A0 =A0 =A0| =A0 =A0 =A0= =A0| =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 | =A0 =A0| to Wi-Fi |
=A0 =A0 =A0 =A0|--------| =A0 =A0 =A0|--------= ---| =A0 =A0|----------| =A0 =A0 =A0 =A0\|/
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|-|----|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | Wi-Fi|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0| Dev =A0|
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|------|

=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 6: WS for backhaul

The description of this deployment scena= rio is not well written, and the figure does nothing to help. Aren't th= e Wi-fi devices supposed to be connected to the slave, and then the slave t= alks to the master? This needs some help.

4.2.5. = =A0Rapid deployed network for emergency scenario

=A0 =A0... =A0This
=A0 =A0approach does in no way imply such organizations for disaster relief=
=A0 =A0must compete on spectrum allocati= on with other white spaces users,
=A0 =A0= but they can. ...

That se= ntence seems unnecessary.

-- deleted sentence as recommended.

4.2.6. =A0Mobility

How does this use= case differ architecturally from 4.2.1? Why isn't this case just a sub= case of 4.2.1, like 4.2.2?

-- Agre= ed. Combined with master/slave whitespace network


4.2.7. =A0Indoor Networking

Isn't this just the same as 4.2.1 without geo= location? Again, seems like it could be combined and shortened.

-- Agreed Moved into use case 1

5. =A0= Problem Statement

=A0 =A0In Figure 11, note that there could be multiple databases serving
=A0 =A0white space devices. =A0The database= s are country specific since the
=A0 =A0r= egulations and available spectrum may vary.

Locatio= n specific, not country specific, right? It may be that multiple countries = share a database, or it may be that a single country has multiple databases= for sub-locales, right? The architecture doesn't depend on "count= ry".

-- Chan= ged to regulatory specific (location based was mentioned in earlier sentenc= e). The intent here I think was to indicate that different dbs might follow= different regluatory domain (country) rules, but the protocol should be in= dependent from them.

5.1. = =A0Global applicability

=A0 =A0The use of TV white space spectrum is currentl= y approved by the FCC
=A0 =A0in the United States. =A0However regula= tory bodies in other countries
=A0 =A0are= also considering similar use of available spectrum. =A0...

Again, the mention of the regulatory= bodies here is unnecessary as it doesn't impact this protocol.

-- delete= d reference

=A0 =A0= 4. =A0Address regulatory requirements - Each country is likely to have
=A0 =A0 =A0 =A0regulations that are unique to= that country. =A0The messaging
=A0 =A0 =A0 =A0interface needs to be flexible = to accommodate the specific needs
=A0 =A0= =A0 =A0of a regulatory body in the country where the white space device
=A0 =A0 =A0 =A0is operating and connecting to the relevant database.
<= div class=3D"gmail_default">
I would = rewrite this to say: "4. Flexible and extensible data structures - Dif= ferent databases are likely to have different requirements for the kinds of= data required for registration as well as the kinds of data returned with = available white space. For instance, different regulatory bodies might requ= ire different information to be passed between the database and the device = accessing it." Again, don't make the regulatory body part of the p= roblem statement; the need to accommodate different data is the requirement= .

-- Rewr= itten as recommended.

5.4. =A0Data model definition

=A0 =A0...
=A0 =A0Use of XML for specifying a data model is an attractive opt= ion. =A0The
=A0 =A0intent is to evaluate = the best option that meets the need for use
=A0 =A0between white space devices and databas= es.

The mention of XML here is premature. Give it as one example (perhaps inc= luding JSON as another) if you think you need such an example.

-- dele= ted reference to XML. No need to mention possible data model implementation= s here.


6. =A0Requirements

---- Asked Vince = to look at these.

6.1. =A0Normative Requirements

=
=A0 =A0 =A0 D. Data Model Requirements:
<= div class=3D"gmail_default">
=A0 =A0 = =A0 D.1: =A0The Data Model MUST support specifying the location of the
=A0 =A0 =A0 =A0 =A0 =A0 WSD, the uncertainty i= n meters, the height & its
=A0 =A0 = =A0 =A0 =A0 =A0 uncertainty, and confidence in percentage of the location
=A0 =A0 =A0 =A0 =A0 =A0 determination. ...

"Location" in the above = is ambiguous. You mean the "geographic location", right?

--changed to geolocation.

=A0 =A0 =A0 = =A0 =A0 =A0 ...The Data Model MUST support both North
=A0 =A0 =A0 =A0 =A0 =A0 American Datum of 1983 and WGS84.

Neither= of these has a reference. Also, if NAD is really a requirement, shouldn= 9;t there be others listed?

=A0 =A0 =A0 D.2: =A0The Data Model MUST support specifying the regulatory d= omain
=A0 =A0 =A0 =A0 =A0 =A0 and its cor= responding data requirements.

<= div class=3D"gmail_default"> That is poorly written. I don't understand what needs to go in a protoc= ol from the above. Don't you just mean that the Data Model MUST be exte= nsible?

=A0 =A0 =A0 D.3: =A0The Data Model MUST support specifying an ID of the
=A0 =A0 =A0 =A0 =A0 =A0 transmitter device. = =A0This ID would contain the ID of the
= =A0 =A0 =A0 =A0 =A0 =A0 transmitter device that has been certified by a reg= ulatory
=A0 =A0 =A0 =A0 =A0 =A0 body for its regulator= y domain. =A0The Data Model MUST support
= =A0 =A0 =A0 =A0 =A0 =A0 a device class. =A0The Data Model MUST support spec= ifying
=A0 =A0 =A0 =A0 =A0 =A0 information about the type of RAT of the transmitte= r device.

What sort of data is an ID? You probably need to mention that. Also= "RAT" is undefined.

=A0 =A0= =A0 =A0P. Protocol Requirements:

=A0 =A0 =A0 P.1: =A0 The protocol MUST prov= ide a mechanism to enable WSD
=A0 =A0 =A0 =A0 =A0 =A0 =A0discovery. =A0In so= me environments, a listing of the approved
=A0 =A0 =A0 =A0 =A0 =A0 =A0white space databases is maintained by the nat= ional
=A0 =A0 =A0 =A0 =A0 =A0 =A0regulator. =A0The protocol MUST support discover= y of a
=A0 =A0 =A0 =A0 =A0 =A0 =A0databas= e using a listing approved by a national regulator.

The "national regulator" portion of the requirement is not the re= quirement. What is it about the list a national regulator provides that is = different, protocol-wise, from any other list from which the WSD is discove= red?

=A0 =A0= =A0 P.3: =A0 The protocol MUST support determination of regulatory
=A0 =A0 =A0 =A0 =A0 =A0 =A0domain governing its = current location.

I don't know what that requireme= nt means.

=A0 =A0 =A0 P.8: =A0 The protocol MUST support the master device re= gistering
=A0 =A0 =A0 =A0 =A0 =A0 =A0with the database.<= /div>

Wh= at is "registering" independent of authentication/authorization?<= /div>

=A0 =A0 =A0 P.10: =A0The protocol MU= ST support a channel query request from the
=A0 =A0 =A0 =A0 =A0 =A0 =A0master device to the database. =A0The channel= query request
=A0 =A0 =A0 =A0 =A0 =A0 =A0message MUST include parameters as required by l= ocal
=A0 =A0 =A0 =A0 =A0 =A0 =A0regulator= y requirement. =A0These parameters MAY include any
=A0 =A0 =A0 =A0 =A0 =A0 =A0of the parameters and attributes requi= red to be supported
=A0 =A0 =A0 =A0 =A0 =A0 =A0in the Data Model R= equirements.

Strike the second sentence. Unnecessary.

6.2. =A0Non-normative requirements

I don't u= nderstand what a non-normative requirement is. Are these just pre-requisite= s? Please explain.

I'm= guessing that the 2119 language in this section is misused, but let me und= erstand what the section is meant to say first.

=A0 =A0O.4: =A0 The master device MU= ST implement at least one connection
=A0 = =A0 =A0 =A0 =A0 method to access the database. =A0The master device MAY con= tact
=A0 =A0 =A0 =A0 =A0 a database directly for service (e.g. as defined by FCC= ) or
=A0 =A0 =A0 =A0 =A0 the master devic= e MAY contact a listing server first followed
=A0 =A0 =A0 =A0 =A0 by contact to a database (e.g. as defined by Ofcom= ).

Referen= ces needed for FCC and Ofcom if you insist on noting them. (I don't thi= nk they're necessary.)

=A0 =A0O.5: =A0 The master device MUST obtain an indication about the
=
=A0 =A0 =A0 =A0 =A0 regulatory domain governin= g operation at its current location,
=A0 = =A0 =A0 =A0 =A0 i.e. the master device MUST know if it operates under
=A0 =A0 =A0 =A0 =A0 regulations from FCC, Ofco= m, etc...

That would be completely out of band, correct?

*****************************
<= div class=3D"gmail_default">
TODO: VI= nce's responses:
A couple of thoughts= .
=A0- If there is an opportunity, we should dis= tinguish between "regulatory domain" and "rule set", wh= ere:
=A0 =A0- regulatory domain is based = on where the device is
=A0 =A0- rule set is a set of requirements tha= t govern device behavior

(rather than combining them into a single phrase of = "regulatory domain requirements"). A "rule set" may be = applicable in multiple domains.

In some= of Pete's comments, he thinks that how a device behaves within a regul= atory domain is out of band. I tend to agree, but it is still useful to hav= e the Database be able to tell the Device which rule set is applicable at i= ts location. Thus, the use-case/requirements should allow for that to be co= mmunicated from the Database to the Device. Why?

=A0- Th= e Device may know where it is (latitude/longitude), but it most likely will= not know which country it's in.
=A0-= Just knowing the country may not help, if it's one that just approved = use of White Space. BUT if a new country
=A0 =A0(e.g., Brazil) adopts the US rule set, = the Database can tell the Device that it can use "FccWhitespace2010&qu= ot; rules,
=A0 =A0the device will just wo= rk.

I belie= ve the original doc had some statements like the above, so we don't wan= t to completely delete all text that refer to "regulator".
<= div class=3D"gmail_default">
Please also see below for my Normati= ve/Non-Normative answers


Perhaps here&= #39;s an opportunity to say that the database can inform the device of the = applicable rule set.
A database may support multiple domains and mu= ltiple rule sets, so we don't want the phrasing to be too limiting.

-- TO= DO (amancuso): I added ruleset information below in different places. I'= ;ll have to go through the doc and see if there are other places where we m= ight want to mention rule set communication by db to device.

5.1. = =A0Global applicability

=A0 =A0The use of TV white space spectrum is currentl= y approved by the FCC
=A0 =A0in the United States. =A0However regula= tory bodies in other countries
=A0 =A0are= also considering similar use of available spectrum. =A0...

Again, the mention of the regulatory= bodies here is unnecessary as it doesn't impact this protocol.

It does, = in the sense that the device needs to know which rule set....
Let's just use WGS84 for the protocol. Del= ete NAD83. The Database can do any required conversions.

--Added in mention o= f rule set; deleted NAD83 (http://earth-info.nga.mil/GandG/publication= s/tr8350.2/tr8350_2.html)
--Added this to the global applicability point= 3:

"Note that although a device may know its geolocation, it may not kn= ow the country or regulatory domain that it is in. Further, even if the dev= ice knows this information, it may not be sufficient for the device to know= its expected behaviour in its domain of operation since one domain may ado= pt a rule set for white space device operation from another regulatory doma= in (Brazil may adopt the "FccWhitespace2010" US rule set). To all= ow the global use of white space devices in different countries (whatever t= he regulatory domain), the protocol should support the Database communicati= ng applicable rule set information to the white space device."


=A0

<= /div>
=A0 =A0 =A0 D.2: =A0The Data Model MUST s= upport specifying the regulatory domain
=A0 =A0 =A0 =A0 =A0 =A0 and its corresponding = data requirements.

That is poorly written. I don't understand what need= s to go in a protocol from the above. Don't you just mean that the Data= Model MUST be extensible?

This so= mewhat addresses my original point. It's beyond just extensible, since = it's beneficial for the Device to know which set of rules to use. Perha= ps it's a surprise to Pete, because the need has not been articulated w= ell enough.

-- Chan= ged to: "The Data Model MUST support specifying the data and other app= licable requirements of the rule set that applies to the white space device= at its current location."

=A0

=A0 = =A0 =A0 D.3: =A0The Data Model MUST support specifying an ID of the
=A0 =A0 =A0 =A0 =A0 =A0 transmitter device. =A0This ID would contain the ID= of the
=A0 =A0 =A0 =A0 =A0 =A0 transmitt= er device that has been certified by a regulatory
=A0 =A0 =A0 =A0 =A0 =A0 body for its regulatory domain. =A0The Dat= a Model MUST support
=A0 =A0 =A0 =A0 =A0 =A0 a device class. =A0The= Data Model MUST support specifying
=A0 = =A0 =A0 =A0 =A0 =A0 information about the type of RAT of the transmitter de= vice.

What sort of data is an ID? You prob= ably need to mention that. Also "RAT" is undefined.

FCC certificati= on ID is an example ID, but there could be other IDs for other certificatio= n bodies.
Serial Number is also ID.

This requirement is re= ally two things:
=A0- Fields that identif= y a device (Serial number, certification IDs)
=A0- Fields that describe device characteristi= cs (device class, radio access technology (RAT), etc.)

In the Protocol Docume= nt, the data model is named "DeviceDescriptor".

=A0-- R= ewrote: "The Data Model MUST support device description data that iden= tifies a device (serial number, certification IDs, etc.) and describes devi= ce characteristics (device class, Radio Access technology (RAT), etc.).&quo= t;

=A0 =A0= =A0 =A0P. Protocol Requirements:

=A0 =A0 =A0 P.1: =A0 The protocol MUST prov= ide a mechanism to enable WSD
=A0 =A0 =A0 =A0 =A0 =A0 =A0discovery. =A0In so= me environments, a listing of the approved
=A0 =A0 =A0 =A0 =A0 =A0 =A0white space databases is maintained by the nat= ional
=A0 =A0 =A0 =A0 =A0 =A0 =A0regulator. =A0The protocol MUST support discover= y of a
=A0 =A0 =A0 =A0 =A0 =A0 =A0databas= e using a listing approved by a national regulator.

The "national regulator" portion of the requirement is not the re= quirement. What is it about the list a national regulator provides that is = different, protocol-wise, from any other list from which the WSD is discove= red?

I would= agree with Pete... Just stating that "listing service" is an opt= ion is sufficient.

There's no requirement that the "listing approved by a national re= gulator" be used for discovery. It can be use to validate.

In other word= s, the Device can contact a database it knows about and, in parallel, conta= ct the national regulator to make sure that database is listed. This way, w= e can avoid chicken/egg.

The nee= d to contact a listing service is "baked into" the Device. It is = just behavior that it needs to implement. It's not part of the protocol= .

-- I ro= lled this up into one requirement and reworded to: "The address of a d= atabase (e.g., in form of a URI) can be preconfigured in a master device. T= he master device MUST be able to contact a database using a pre-configured = database address. The master device may validate the database against a lis= t of approved database maintained by a regulatory body."
=A0

=A0 =A0 =A0 P.3: =A0 The protocol MUST suppo= rt determination of regulatory
=A0 =A0 = =A0 =A0 =A0 =A0 =A0domain governing its current location.

I don&#= 39;t know what that requirement means.
This is explained above with the need = to know the set of governing rules. So it must support a Database informing= the Device of regulatory domain and governing rules.

--- Cha= nged this to: "he protocol must support the database informing the mas= ter of the regulatory rules (rule set) that applies to the master device (o= r any slave devices on whose behalf the master is contacting the database) = at the current location or the master (or slave) device(s)."

-- Note= that in view of the earlier comments, I didn't see a need to mention a= db requirement to inform the device of the regulatory body (since the dete= rminative data is the ruleset (may be the current or a "foreign" = domain).
=A0

=A0 =A0 =A0 P.8: =A0 The protocol MUST suppo= rt the master device registering
=A0 =A0 = =A0 =A0 =A0 =A0 =A0with the database.

What is= "registering" independent of authentication/authorization?
=

As expl= ained elsewhere, (could back-reference?) this is contact information of own= er/operator, device geolocation, antenna characteristics, etc. It is orthog= onal to authentication/authorization. I think Pete realized this at the F2F= , so it should not be controversial.
=A0
-- added= xref to registration section.

=
=A0 =A0 =A0 P.10: =A0The protocol MUST support= a channel query request from the
=A0 =A0 =A0 =A0 =A0 =A0 =A0master device to th= e database. =A0The channel query request
= =A0 =A0 =A0 =A0 =A0 =A0 =A0message MUST include parameters as required by l= ocal
=A0 =A0 =A0 =A0 =A0 =A0 =A0regulatory requirement. =A0These parameters MAY = include any
=A0 =A0 =A0 =A0 =A0 =A0 =A0of= the parameters and attributes required to be supported
=A0 =A0 =A0 =A0 =A0 =A0 =A0in the Data Model Requirements.

Strike = the second sentence. Unnecessary

Change channel to "available spectrum&q= uot;.
=A0
-- done = here and in next available spectrum response paragraph.
=A0
6.2. =A0Non-normative = requirements

I don&#= 39;t understand what a non-normative requirement is. Are these just pre-req= uisites? Please explain.

I'm guessing that the 2119 language in this section is misused, but let= me understand what the section is meant to say first.

These are trying to de= scribe the system as a whole, containing requirements / behavior on the Dev= ice and Database, independent of the Protocol. That should be explained, th= en ask for guidance on how to frame these and whether they are needed.

-- Adde= d this lead-in sentence: "This section contains functional characteris= tics of the white space database/devices system, independent of the specifi= c requriements of the protocol for communication between the white space da= tabase and devices."
=A0

=A0 =A0O.4: =A0 The master device MUST imple= ment at least one connection
=A0 =A0 =A0 = =A0 =A0 method to access the database. =A0The master device MAY contact
=A0 =A0 =A0 =A0 =A0 a database directly for se= rvice (e.g. as defined by FCC) or
=A0 =A0= =A0 =A0 =A0 the master device MAY contact a listing server first followed<= /div>
=A0 =A0 =A0 =A0 =A0 by contact to a database (e.g. as defined by Ofcom).

Refe= rences needed for FCC and Ofcom if you insist on noting them. (I don't = think they're necessary.)

Agree w= ith Pete. Again, this is a requirement on the device.

-- deleted references t= o regulators. OK to talk about device requriements here now that the intent= of this section is clearer.
=A0

=A0 =A0O.5: =A0 The master device MUST obtai= n an indication about the
=A0 =A0 =A0 =A0= =A0 regulatory domain governing operation at its current location,
=A0 =A0 =A0 =A0 =A0 i.e. the master device MUS= T know if it operates under
=A0 =A0 =A0 = =A0 =A0 regulations from FCC, Ofcom, etc...

That would be completely out of band, correct?

Not completely, as I explained= above. It is beneficial to have the Device know which rule set to use.
In particular, if it gets a ruleset it does no= t understand, it cannot operate.=A0

<= /div>
-- Changed this to "The master devic= e MUST obtain an information on the rule set of the regulatory body that ap= plies to the master device at its current location (and/or the location of = any slave devices on whose behalf the master device is operating)."




On Mon, Jan 14, 2013 a= t 2:25 PM, Pete Resnick <presnick@qti.qualcomm.com> = wrote:
=20
I'm on it.


On 1/14/13 4:16 PM, Anthony Mancuso wrote:
Gabor,

I just uploaded v. 10 to IETF for AD review.

Thanks to all for their review and comments.

Tony


On Mon, Jan 14, 2013 at 1:20 PM, <Gabor.B= ajko@nokia.com> wrote:

Thanks for everyone who reviewed the draft. It seems the draft is acceptable as it is, so let=92s go for the AD review.

Tony already mentioned that he made some minor wording changes to the draft to capture Nancy=92s comments, once Tony uploads the new version, we=92ll ask our AD to review it again.

=A0

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor

=A0

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Peter Stanforth
Sent: Friday, January 11, 2013 1:28 PM
To: paws@ietf= .org
Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

=A0

First of all I apologize for taking so =A0long to review this. =A0Good Job! While I could poke at a couple of areas I like the fact that this is concise and to the point so I would much prefer to leave it alone and move on.

Regards,

Peter S.

=A0

From: "internet-drafts@ietf.org" <internet-drafts@ietf.org&g= t;
Date: Friday, December 21, 2012 12:10 PM
To: "i-d-announce@ietf.org" <i-d-announce= @ietf.org>
Cc: "paw= s@ietf.org" <paws@ietf.org>
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

=A0

=A0

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.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Protocol to Access White Space (PAWS) Database: Use Cases and Requirements

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 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=A0=A0Basavaraj Patil

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0=A0: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 27

=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0: 2012-12-21

=A0

Abstract:

=A0=A0 [Editor's Note: This version is submitted for review.=A0=A0A final, pos= t-

=A0=A0 review version is anticipated that will supersede this version].

=A0

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

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

=A0=A0 defined as "white space."=A0=A0The concept of allowing additional=

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

=A0=A0 technique to "unlock" existing spectrum for new use.=A0=A0An obvi= ous

=A0=A0 requirement is that these additional transmissions do not interfere<= /p>

=A0=A0 with the assigned use of the spectrum.=A0=A0One approach to using white

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

=A0=A0 availability with a database that manages spectrum sharing and

=A0=A0 provides spectrum-availability information.

=A0

=A0=A0 This document describes a number of possible use cases of white space

=A0=A0 spectrum and technology as well as a set of requirements for the

=A0=A0 database query protocol.=A0=A0The concept of white spaces is described

=A0=A0 along with the problems that need to be addressed to enable white

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

=A0=A0 currently assigned use.=A0=A0Use of white space is enabled by querying a

=A0=A0 database that stores information about spectrum availability at any<= /p>

=A0=A0 given location and time.

=A0

=A0

=A0

The IETF datatracker status page for this draft is:

=A0

There's also a htmlized version available at:

=A0

A diff from the previous version is available at:

=A0

=A0

Internet-Drafts are also available by anonymous FTP at:

=A0

___________________________________= ____________

paws mailing list

=A0


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



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

--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

--f46d0401f97199f0a004d355f5d2-- From budden@nps.edu Tue Jan 15 10:53:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC4F11E80C5 for ; Tue, 15 Jan 2013 10:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[AWL=-1.357, BAYES_50=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 0yRBfWTXy2Kt for ; Tue, 15 Jan 2013 10:53:43 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id E76C521F84F9 for ; Tue, 15 Jan 2013 10:53:40 -0800 (PST) X-ASG-Debug-ID: 1358276020-036c92475a15f20001-Z0ZA9G Received: from skytrain.ern.nps.edu (skytrain.ern.nps.edu [172.20.24.112]) by mule.nps.edu with ESMTP id RPEC8zIk8tRI1ZWs; Tue, 15 Jan 2013 10:53:40 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.112) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 15 Jan 2013 10:53:39 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt To: Anthony Mancuso In-Reply-To: References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> <50F485BD.7050709@qti.qualcomm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 15 Jan 2013 10:52:28 -0800 Message-ID: <1358275948.2201.1111.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: skytrain.ern.nps.edu[172.20.24.112] X-Barracuda-Start-Time: 1358276020 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.119948 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org, Pete Resnick 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: Tue, 15 Jan 2013 18:53:44 -0000 Tony, On Tue, 2013-01-15 at 08:07 -0800, Anthony Mancuso wrote: > changed "channel" availability references to "spectrum" availability > where appropriate I don't think we want to grasp this one in this version, but keep the extensibility options open: most of the protocols that we'd imagine in this space use TDMA MACs (IEEE 802.16, TIA LTE, ...). So 'availability' might not be different channel or spectrum, but rather an unused timeslice. From amancuso@google.com Tue Jan 15 12:23:35 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028B311E80BA for ; Tue, 15 Jan 2013 12:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.806 X-Spam-Level: X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 TmPjisAXB9Vl for ; Tue, 15 Jan 2013 12:23:30 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6C321F8512 for ; Tue, 15 Jan 2013 12:23:21 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id n8so474589lbj.16 for ; Tue, 15 Jan 2013 12:23:20 -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=Kdst0ZC+LGzlGAqdnhVS901ZPELatsgbTwEzpNS4Afc=; b=OcL29WbIBHE161Ma8LdpjENVl63pcLQ7RpbTs+CumGq2yfKZp3UNJoIACKvGmm45lN j3VJuvr8AugTGG882mZ96BmgiWZMDa6hypK+ElmnTE7X1LTbb3njX0RQ8tuyJekrYHO/ Hsm3sx+1YgQ42Sj5wBXMPi/ccj/T8f3BwUhhWyk78qXIvESsw3BzzRgYj5Ys8HAfwH8n bBs1CLSXD51PSoD8zXFGc5Sz7RaW5dKS632ELQXz5oIQsVvEJdDpciBrq0kFD+zbx7E9 CdF+xOSYkS02UlvYi3NVEANODt0UoEyjjzph/778z0kE5TZYD2YuIHHxvo6Lru8z0pK0 gUgg== 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=Kdst0ZC+LGzlGAqdnhVS901ZPELatsgbTwEzpNS4Afc=; b=jHpSfe6pLFljX0ZIn+fLx/hSkdVWSTaT5tchK2uaFxEOoiIhc4Ck78q/LWaInEmhI3 Q/9sEHsgmE5S3S4FCYkat3sPB3NV2NX19i2DPWsCtsEKh0L29/0xSwJfUxDS9BR1Yx56 yTQGkNV0c1WNdPdZEoMQaXb7iR/N6H0Diyj45zHanZHthPOPk8UNBWVwe75EHtn7E4UO uagdvVq4yEraynFvHnA0JNW3wW04ZoIo9nd2kdUQWATGrw0k9cO3FWJaEkzyctqFmSN7 NYWJ7aZzfAvMZC6iTBQZrZXE8+gL6Pl8FzZgHIowMQYAKjVFD7V7bk87oQNqrUd5boke yiow== MIME-Version: 1.0 Received: by 10.112.11.33 with SMTP id n1mr37941565lbb.18.1358281400439; Tue, 15 Jan 2013 12:23:20 -0800 (PST) Received: by 10.112.9.234 with HTTP; Tue, 15 Jan 2013 12:23:20 -0800 (PST) In-Reply-To: <1358275948.2201.1111.camel@localhost.localdomain> References: <20121221171051.15437.46207.idtracker@ietfa.amsl.com> <1ECAFF543A2FED4EA2BEB6CACE08E476020F9E33@008-AM1MPN1-006.mgdnok.nokia.com> <50F485BD.7050709@qti.qualcomm.com> <1358275948.2201.1111.camel@localhost.localdomain> Date: Tue, 15 Jan 2013 12:23:20 -0800 Message-ID: From: Anthony Mancuso To: Rex Buddenberg Content-Type: multipart/alternative; boundary=e0cb4efe2a3060d49e04d359886c X-Gm-Message-State: ALoCoQmJWvMwC9fl6tr9op2z/sPDoGvBrtCRNIeynx09CVDWCo4W+RKzkWu9vDTgtir6/zaF3yX/syFnxTff13mhcABIpRd3bS5C1JGfJRPQQA8XWn+BLClSgWBJ5ojW+mkVxS0t1R1xpLWofzE9Grj8hmB7VOpcVoc87+ErQEGvgoBlAZ6dXhDMguW9qbrP0fbfC2UxFTUa Cc: paws@ietf.org, Pete Resnick 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: Tue, 15 Jan 2013 20:23:35 -0000 --e0cb4efe2a3060d49e04d359886c Content-Type: text/plain; charset=ISO-8859-1 Thanks Rex. This is a important clarification that I agree we should keep in mind (and keep our options open). On Tue, Jan 15, 2013 at 10:52 AM, Rex Buddenberg wrote: > Tony, > > On Tue, 2013-01-15 at 08:07 -0800, Anthony Mancuso wrote: > > changed "channel" availability references to "spectrum" availability > > where appropriate > > I don't think we want to grasp this one in this version, but keep the > extensibility options open: most of the protocols that we'd imagine in > this space use TDMA MACs (IEEE 802.16, TIA LTE, ...). So 'availability' > might not be different channel or spectrum, but rather an unused > timeslice. > > --e0cb4efe2a3060d49e04d359886c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Rex. This is a i= mportant clarification that I agree we should keep in mind (and keep our op= tions open).


On Tue, Jan 15, 2013 at 10:52 AM, Rex Buddenberg <budden@nps.navy.mil> wrote:
Tony,

On Tue, 2013-01-15 at 08:07 -0800, Anthony Mancuso wrote:
> =A0 changed "channel" availability references to "spect= rum" availability
> where appropriate

I don't think we want to grasp this one in this version, but keep= the
extensibility options open: =A0most of the protocols that we'd imagine = in
this space use TDMA MACs (IEEE 802.16, TIA LTE, ...). =A0So 'availabili= ty'
might not be different channel or spectrum, but rather an unused
timeslice.


--e0cb4efe2a3060d49e04d359886c-- From vchen@google.com Tue Jan 15 17:30:06 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736B221F862B for ; Tue, 15 Jan 2013 17:30:06 -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 vEKXRT3xBOXX for ; Tue, 15 Jan 2013 17:30:05 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 46DEC21F84FC for ; Tue, 15 Jan 2013 17:30:05 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id o1so2955908wic.17 for ; Tue, 15 Jan 2013 17:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=exXAnUeE5fuNG/6PbXV1PaMb+6MKe77mJa704/lT7J8=; b=KtVoBtzuONHa8prQa+Ri7kDqs1GSjnUGaBd43jNJD8MDEKDTFVXPCP04sRYSMkwDhg cwrw70vE3+V+5ZF7T5dXEkkvjPi/6nhMtwL4cqyxZMdL+PtvVq/SbiYxJv+t+tdyz0Qo YPR+WrPCNZjbydi18fQN0+9d88sGAIObtlPcT4AuOVInqYBxrKI4OpkE0KXGghjNe/Kq mBZW0H/lG2Xcw9CKNjT+J9ERP5JI9pnqaKwSDQlq3gVRsCfHXCKM8YPTnZ1Ort1Dz9o8 +pJaFivM1N+kku8AJ79YkvmzlKXXAvng7BHNF4Uuldj/QzrBt/Jtin5s0+dm8PUf8E9G zGAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=exXAnUeE5fuNG/6PbXV1PaMb+6MKe77mJa704/lT7J8=; b=dYJrmeMOUntHTA4wwDIEKLjbvNczBnrIFphnjjQBhfRch1HF7gj2dUUtzGCDQ5m+8+ jaWa/1kSoAcpUb4VMx3Psi8BSPdGKtltgfI7w6OhliKSCtpRyZBOzUW9DIosLoCcG7AP GOvzKeLhJoVDhnv+jefRACFl1zrwNJUCon23i29yJXl/nnTMynja/kwZj37o2zXNdSEF pWj1Ia5CpVHxbA2x8a7pWJTA82FQ4zyAvzfLJnkGpuHGI8ZzdF1a9v8wRYt1fHKlu6wV Y9xeOVptsaJUAZzdmzMaWHqfYte6lNKIgZdHM8BEqO5lSpW0lZHEQJPpJElkOlvLaB7g fQnA== MIME-Version: 1.0 Received: by 10.180.80.230 with SMTP id u6mr6792018wix.20.1358299804362; Tue, 15 Jan 2013 17:30:04 -0800 (PST) Received: by 10.194.118.195 with HTTP; Tue, 15 Jan 2013 17:30:04 -0800 (PST) Date: Tue, 15 Jan 2013 17:30:04 -0800 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=f46d04428ace5669dd04d35dd19a X-Gm-Message-State: ALoCoQlSYmVV84tWuzpXn+1vPxTdKqgz2HcmnCMF48hfQwLSAIkfOFhYHKa3g6xu69LVwQZNr+rHZ2kFuiQrz7ntk9WfjRcBb/+3d++iRcOmcPq0EAixfcNb9W7kCK0fq+/unGyn1TOfV+zVwIpP9rt53Dc+Rctrv+SUPev7kkyeVfSQiEq5TWd4S1oli2ryYBNjGBZohVjG Subject: [paws] PAWS Protocol: Extensibility 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, 16 Jan 2013 01:30:06 -0000 --f46d04428ace5669dd04d35dd19a Content-Type: text/plain; charset=ISO-8859-1 All, I'd like to propose the following for addressing the extensibility of the protocol. *Regulatory rules (roughly) fall under three areas: - Database-only rules, such as how spectrum availability must be computed - Device-only rules that govern its behavior, e.g., - Maximum-power levels that depend on how many channels the Device chooses to use - Conditions under which the Device must contact the Database - Rules that impact both, such as, - Device parameters that are needed to determine spectrum availability - Spectrum-availability information that must be provided by the Database - Spectrum utilization reporting (in jurisdictions that require it) The following proposals assumes that it will not be practical to have the Database be responsible for communicating Device-only rules to the devices, because: - It is impractical to encode all device behavior via a set of declarative parameters - The device will be subject to a certification process to determine correct device behavior for each set of regulatory rules Interaction model The Device must include a "Device Descriptor" with each request to the Database. The descriptor contains fields that identify the device, its configuration, its certification tags, and any other parameters required by regulators, such as device type, device class, etc. 1. The Device makes a request with as many of the Device Descriptor fields as it chooses to populate, plus its location 2. The Database determines if all required parameters are provided. If not, it returns an error with a list of the missing parameters. 1. The list of missing parameters may depend on the certification tags provided by the Device 2. If certification tags are specified, but the Database does not allow any of them, it returns a UNAUTHORIZED error 3. The Device may make the request again with the missing parameters. If the Device cannot supply the missing parameters, it will not be able to use the Database. 4. When the request is valid, the Database includes in its response the certification tag that corresponds to the applicable rule set. A "certification tag" represents the certification a device has been certified by a certification body (does not necessarily have to be a regulator?). A device may be configured with multiple certification tags. Valid values for the certification tag, as well as valid Device Descriptor fields, will be extensible via appropriate IANA tables. NOTE: In order for new regulators to leverage existing devices to operate within their jurisdictions, regulators might be motivated adopt existing certifications, rather than defined create new rules and new certification processes. If that is true, there should not be a proliferation of certification tags. * Is something like this workable? -- -vince --f46d04428ace5669dd04d35dd19a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I'd = like to propose the following for addressing the extensibility of the proto= col.

Regulatory rules (roughly) fall under three areas:<= /span>
  • Database-only rules, such as how spectrum ava= ilability must be computed
  • Device-only rules= that govern its behavior, e.g.,
    • Maximum-power levels that depend on how man= y channels the Device chooses to use
    • Conditions unde= r which the Device must contact the Database
  • Rules that i= mpact both, such as,
    • Device parameters that are needed to determ= ine spectrum availability
    • Spectrum-availa= bility information that must be provided by the Database
    • Spectrum utiliz= ation reporting (in jurisdictions that require it)

The following proposals assumes that it will not be practical t= o have the Database be responsible for communicating Device-only rules to t= he devices, because:
  • It is impractical to encode all device behavi= or via a set of declarative parameters
  • The device will b= e subject to a certification process to determine correct device behavior f= or each set of regulatory rules

Interaction model

  • The Device makes a request with as many of= the Device Descriptor fields as it chooses to populate, plus its location<= /span>
  • The Database d= etermines if all required parameters are provided. If not, it returns an er= ror with a list of the missing parameters.
    1. The list of missing parameters may dep= end on the certification tags provided by the Device
    2. If certifi= cation tags are specified, but the Database does not allow any of them, it = returns a UNAUTHORIZED error
  • The Devic= e may make the request again with the missing parameters. If the Device can= not supply the missing parameters, it will not be able to use the Database.=
  • When the reque= st is valid, the Database includes in its response the certification tag th= at corresponds to the applicable rule set.

    • A "certification tag" represents the certification a devic= e has been certified by a certification body (does not necessarily have to = be a regulator?). A device may be configured with multiple certification ta= gs.



    Is something = like this workable?

    --
    -vince
    --f46d04428ace5669dd04d35dd19a-- From weixinpeng@huawei.com Sun Jan 20 17:45:33 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0721F8600 for ; Sun, 20 Jan 2013 17:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 kgpbEu8a+Trj for ; Sun, 20 Jan 2013 17:45:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 161F121F856D for ; Sun, 20 Jan 2013 17:45:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANS30485; Mon, 21 Jan 2013 01:45:22 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 01:45:15 +0000 Received: from SZXEML461-HUB.china.huawei.com (10.82.67.204) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 21 Jan 2013 01:45:21 +0000 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.24]) by szxeml461-hub.china.huawei.com ([10.82.67.204]) with mapi id 14.01.0323.007; Mon, 21 Jan 2013 09:45:18 +0800 From: Weixinpeng To: Vincent Chen , "paws@ietf.org" Thread-Topic: [paws] PAWS Protocol: Extensibility Thread-Index: AQHN84kHN0Kpphs8X0qDRpTUcGCttphTB3aw Date: Mon, 21 Jan 2013 01:45:17 +0000 Message-ID: References: In-Reply-To: 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_C5C3BB522B1DDF478AA09545169155B43BF54602SZXEML519MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [paws] PAWS Protocol: Extensibility 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, 21 Jan 2013 01:45:33 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43BF54602SZXEML519MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vince, I have a question about the "Interaction model". In your descripti= on, the DB will authenticate the device, but sometimes the device may also needs to authenticate the DB. So maybe a mutu= al authentication need to be considered. --Xinpeng From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: Wednesday, January 16, 2013 9:30 AM To: paws@ietf.org Subject: [paws] PAWS Protocol: Extensibility All, I'd like to propose the following for addressing the extensibility of the p= rotocol. Regulatory rules (roughly) fall under three areas: * Database-only rules, such as how spectrum availability must be comput= ed * Device-only rules that govern its behavior, e.g., * Maximum-power levels that depend on how many channels the Device c= hooses to use * Conditions under which the Device must contact the Database * Rules that impact both, such as, * Device parameters that are needed to determine spectrum availabili= ty * Spectrum-availability information that must be provided by the Dat= abase * Spectrum utilization reporting (in jurisdictions that require it) The following proposals assumes that it will not be practical to have the D= atabase be responsible for communicating Device-only rules to the devices, = because: * It is impractical to encode all device behavior via a set of declarat= ive parameters * The device will be subject to a certification process to determine co= rrect device behavior for each set of regulatory rules Interaction model The Device must include a "Device Descriptor" with each request to the Data= base. The descriptor contains fields that identify the device, its configur= ation, its certification tags, and any other parameters required by regulat= ors, such as device type, device class, etc. 1. The Device makes a request with as many of the Device Descriptor fiel= ds as it chooses to populate, plus its location 2. The Database determines if all required parameters are provided. If n= ot, it returns an error with a list of the missing parameters. * The list of missing parameters may depend on the certification tag= s provided by the Device * If certification tags are specified, but the Database does not all= ow any of them, it returns a UNAUTHORIZED error 1. The Device may make the request again with the missing parameters. If= the Device cannot supply the missing parameters, it will not be able to us= e the Database. 2. When the request is valid, the Database includes in its response the = certification tag that corresponds to the applicable rule set. A "certification tag" represents the certification a device has been certif= ied by a certification body (does not necessarily have to be a regulator?).= A device may be configured with multiple certification tags. Valid values for the certification tag, as well as valid Device Descriptor = fields, will be extensible via appropriate IANA tables. NOTE: In order for new regulators to leverage existing devices to operate w= ithin their jurisdictions, regulators might be motivated adopt existing cer= tifications, rather than defined create new rules and new certification pro= cesses. If that is true, there should not be a proliferation of certificati= on tags. Is something like this workable? -- -vince --_000_C5C3BB522B1DDF478AA09545169155B43BF54602SZXEML519MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Vince,<= o:p>

     &nbs= p;       I have a question about the “I= nteraction model”. In your description, the DB will authenticate the = device, but

    sometimes = the device may also needs to authenticate the DB. So maybe a mutual authent= ication need to be considered.

     = ;

     = ;

    --Xinpeng<= o:p>

     = ;

     = ;

    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vincent Chen
    Sent: Wednesday, January 16, 2013 9:30 AM
    To: paws@ietf.org
    Subject: [paws] PAWS Protocol: Extensibility

     

    All,

     

    I'd like to propose the followi= ng for addressing the extensibility of the protocol.

     

    Regulatory rules (roughly) fall= under three areas:<= /o:p>

    • Database-only rules, such as how spectrum availability must be com= puted
    • Device-only rules that govern its behavior, e.g.,
      • Maximum-power levels that depend on how many channels the Device c= hooses to use
      • Conditions under which the Device must contact the Database
    • Rules that impact both, such as,
      • Device parameters that are needed to determine spectrum availabili= ty
      • Spectrum-availability information that must be provided by the Dat= abase
      • Spectrum utilization reporting (in jurisdictions that require it)<= o:p>


    The following proposals assumes that it will no= t be practical to have the Database be responsible for communicating Device= -only rules to the devices, because:

    • It is impractical to encode all device behavior via a set of decla= rative parameters
    • The device will be subject to a certification process to determine= correct device behavior for each set of regulatory rules=


    Interaction model

    The Device must include a "Device Descript= or" with each request to the Database. The descriptor contains fields = that identify the device, its configuration, its certification tags, and any other parameters required by regulators, such as device type, devi= ce class, etc.=

    1. The Device makes a request with as many of the Device Descriptor f= ields as it chooses to populate, plus its location
      2. The Database determines if all required parameters are provided. I= f not, it returns an error with a list of the missing parameters.
      1. The list of missing parameters may depend on the certification tag= s provided by the Device
      2. If certification tags are specified, but the Database does not all= ow any of them, it returns a UNAUTHORIZED error
    1. The Device may make the request again with the missing parameters.= If the Device cannot supply the missing parameters, it will not be able to= use the Database.
    2. When the request is valid, the Database includes in its response t= he certification tag that corresponds to the applicable rule set.


    A "certification tag" represents the = certification a device has been certified by a certification body (does not= necessarily have to be a regulator?). A device may be configured with multiple certification tags.

    Valid values for the certification tag, as well= as valid Device Descriptor fields, will be extensible via appropriate IANA= tables.

    NOTE: In order for new regulators to leverage e= xisting devices to operate within their jurisdictions, regulators might be = motivated adopt existing certifications, rather than defined create new rules and new certification processes. If that is true, there s= hould not be a proliferation of certification tags.

     

    Is something like this workable= ?

     

    --
    -vince

    --_000_C5C3BB522B1DDF478AA09545169155B43BF54602SZXEML519MBSchi_-- From vchen@google.com Tue Jan 22 08:30:15 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679E721F8A74 for ; Tue, 22 Jan 2013 08:30:15 -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 zCm20rrnq3-g for ; Tue, 22 Jan 2013 08:30:14 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEDD21F8A6E for ; Tue, 22 Jan 2013 08:30:14 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so1423733wgd.28 for ; Tue, 22 Jan 2013 08:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HBl0fzOHTvZBUGRFIOdjNq+ptemKmeiIGT+psV3HOec=; b=lxagAU7MrzUF+7VXNruATwKzXTFG3dn7crG1LDREL3VjZ13kRcRv2nZ0Q2DxyZW0nn asx9IzGR0JfdV3u+VFjPRTK9eTRFqprr+Ts17F1iTpxhT1c8Dexgk7xul+CQM/8uaJ0p MvPLB2fVJXs8aHwtZGSvCjcGEG0cjbv5Bds32E7DX86i8XqKeJxHLgFkl0p1xGs3qOqW mmAVzBByHjYI98T8uir0gHCr105MJhoB1EdEv25WNZc7zlqoJETm5ihtkh7GKKTkMJiN W0DM3HiLR73Ef+pPP9uPpSdSXw7ebeaUqXOke6DBBnOaNUDt0TvxecwtLEYYdQ980XWN Rlyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=HBl0fzOHTvZBUGRFIOdjNq+ptemKmeiIGT+psV3HOec=; b=i5if8i2b7+15Dmx77KH1tzMYas6kyabb3+UE6oF0n7EibGwVDemWxmcnBZT5jqALq5 uVtr2w9UMHmL6RisVLWgmRLFxVsxQk3lmHZnkyBVg2dgjfAqalb2u8Ym828enoH58jOQ qgGscNAeMluMJ6ZAoYYwTBWjVSjNTZE3xuY/1a80QGF03hNF3y5LnfjStbyYwpJv3dCg m7yN8IESJnpZ+1ullRo+3EtDGc+QBo+szJjx5FcCQT6Nc3h7bO5lZ/60kgvpzvYxHXD9 YPWCIsODZoSQo2cdshUFbDkLFiZNQV1xnBsNqaCTb24Y7xj7jBHGt6DiI7GVlj0/8qr3 AERg== MIME-Version: 1.0 X-Received: by 10.194.76.237 with SMTP id n13mr33620924wjw.57.1358872213104; Tue, 22 Jan 2013 08:30:13 -0800 (PST) Received: by 10.194.118.195 with HTTP; Tue, 22 Jan 2013 08:30:13 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Jan 2013 08:30:13 -0800 Message-ID: From: Vincent Chen To: Weixinpeng Content-Type: multipart/alternative; boundary=047d7bfcef748ea64204d3e317bf X-Gm-Message-State: ALoCoQkw2GrhoUa67taBMVO7CoghEfvV1pYKa24zVyzHMrkZWxSYTiZHbjpLdBWMYtN1MvB90tXLDlEtRJtZ+jzTSrzNwPO74hbUf2XG5LT7Vx4ls5pOT8NiDT+fk33D51UAw823Fmjt6lR481lfpmbdMBF/QjazIPDwjzunX2FiUO52dJ/OBwF71tYUImhV78iZHTMcuXIk Cc: "paws@ietf.org" Subject: Re: [paws] PAWS Protocol: Extensibility 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, 22 Jan 2013 16:30:15 -0000 --047d7bfcef748ea64204d3e317bf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Xinpeng, On Sun, Jan 20, 2013 at 5:45 PM, Weixinpeng wrote: > Hi Vince,**** > > I have a question about the =93Interaction model=94. In your > description, the DB will authenticate the device, but**** > > sometimes the device may also needs to authenticate the DB. So maybe a > mutual authentication need to be considered.**** > > ** ** > > ** > Sorry that my description is incomplete. It assumes that authentication of the DB already occurred at the HTTPS layer. -vince > ** > > --Xinpeng**** > > > --047d7bfcef748ea64204d3e317bf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    Xinpeng,


    On Sun, Jan 20, 2013 at 5:45 PM, Weixinpeng <    we= ixinpeng@huawei.com> wrote:

    Hi Vince,<= u>

    =A0=A0=A0= =A0=A0=A0=A0=A0 I have a question about the =93Interaction model=94. In you= r description, the DB will authenticate the device, but

    sometimes = the device may also needs to authenticate the DB. So maybe a mutual authent= ication need to be considered.

    =A0=


    Sorry that my de= scription is incomplete. It assumes that authentication of the DB already o= ccurred at the HTTPS layer.

    -vince
    =A0

    =A0

    --Xinpeng<= u>


    --047d7bfcef748ea64204d3e317bf-- From presnick@qti.qualcomm.com Wed Jan 23 12:53:55 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A3521F8828 for ; Wed, 23 Jan 2013 12:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.015, 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 t-VbjPf-I-As for ; Wed, 23 Jan 2013 12:53:54 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1D48321F8816 for ; Wed, 23 Jan 2013 12:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1358972551; x=1390508551; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=zLErDS/4Ehy3cLlOEjNW5MjL08sXntUXZ8nHrHD0hH8=; b=Fh5h7twtLPLPmdQKqu81YWmSDa/68YnJMa3wXENyV8xQ1JpIeOMS3A3G H6F0s5xXuPFv0uL0I11uxIfGTU1QNSccr2q7x63od4Qf8LK7jdK2pjRYP 5Bkm/s0+6IdN2/Kk7zz+xpvEszMmuhYHNeaqVCjBN1/LD8c2xMgqVrcqB s=; X-IronPort-AV: E=Sophos;i="4.84,523,1355126400"; d="scan'208";a="17698375" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 23 Jan 2013 12:22:27 -0800 X-IronPort-AV: E=Sophos;i="4.84,523,1355126400"; d="scan'208";a="468931995" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jan 2013 12:53:50 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 12:53:49 -0800 Message-ID: <51004DFD.4030001@qti.qualcomm.com> Date: Wed, 23 Jan 2013 14:54:21 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "paws@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Subject: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 20:53:55 -0000 At long last, I got through my AD review of draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that this draft is very much improved. The comments I have below are not (as far as I can tell) showstoppers. I have not had a chance to go through all of the commentary in Anthony's note from last week yet; I wanted to get this out ASAP, so if there are things in the note that answer some of my comments below, let me know. Now: Don't Panic! As I said, none of the issues are showstoppers. But the list is long. I am willing to take direction from the chairs on this: I'll wait at least until tomorrow to issue the IETF wide Last Call. If upon reviewing these, the WG thinks, "Gee, if Pete didn't get the point there, perhaps we should fix the document before issuing the Last Call", let me know that and I'll hold off for a bit. But if you think all of these issues can be handled easily along with the rest of the Last Call comments, I'll go ahead and issue the Last Call and you can put these into your queue along with any new comments received. So, here are the comments. If you can have a look in the next 24 hours, that would be great. ------ Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database." Also add the above to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the database using a well-defined protocol." 2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique? "Device Class" is only used once in section 5.1. No need for the definition here. "Location Based Service" is only used once in section 3. No need for the definition here. "Protected Entity" is only used once in section 4.1. No need for the definition here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the definition here. 3.1 This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections? 3.1 "A complete protocol solution must enable all potential white space services." That seems a bit absolute. How about "must enable many different potential white space services"? 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing. 3.1.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained. 3.1.2: Similar questions regarding regulatory domains. For example, "2. To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary. 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation. 3.2.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order. 3.2.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it? 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it be perfectly reasonable for communication between the master and slaves continue on its original connection and that the white space is only used for other communications the slave wishes to do? 3.2.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain. 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves. 4: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph. 4.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface? 4.1, item 3: Again I suggest changing "operate in any country" to "operate in any locale" and change "country-specific" to "locale-specific". (The other occurrence of "country" seems correct.) 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient? 5.1 and 5.2: I don't understand the distinction between "Normative" and "Non-normative" requirements in this context. Isn't it sufficient that you've separately labeled "Data Model Requirements", "Protocol Requirements", and "Operational Requirements"? P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required? P.5 and P.6: The requirement here is for *message-level* integrity and encryption? That's OK, but I want to make sure that's what you mean. P.8 and P.14: I don't think "result codes" and "response codes" are the requirement here, are they? It sounds like the requirement is "indication of success or failure". P.15: I'm not clear on what this requirement means in practical terms. Some more explanation seems in order. P.16: Shouldn't this be combined with P.9? O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"? O.3: This seems to indicate that database discovery will be out of band, that the WG is not developing protocol to do so. Is that what you meant? If not, this should be turned into a protocol requirement instead of an operational requirement. O.4: This requirement seems a bit overly obvious and silly to state as a requirement. Why is it necessary to say that you need a connection? O.5: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database. O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change "local regulatory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc. Section 7, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules". Threat 7: This doesn't strike me as a security consideration per se. This might make more sense incorporated into an operational requirement. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From amancuso@google.com Wed Jan 23 13:17:24 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E5621F84D9 for ; Wed, 23 Jan 2013 13:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.083 X-Spam-Level: X-Spam-Status: No, score=-101.083 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_HTML_USL_OBFU=1.666, 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 BzZPC85RiLVJ for ; Wed, 23 Jan 2013 13:17:23 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 194A321F8828 for ; Wed, 23 Jan 2013 13:17:22 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id gb23so818181vcb.10 for ; Wed, 23 Jan 2013 13:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fLlOeZX22JzLTVJFo9YrrF+8q7Dkoaj12cB+zIH9Q8s=; b=mUq9Kg2mQ9+LvUDvvwq3ki1gNWDsQ9iN2tNv04iwoIbv4lLcKmc2Ism3YPUflki+3w 5iuD+CkCn8aXt37mypsbhWrMRMsvADaZsIyRmcg47z2YxYZZl7zjVf68jFUO+jHMYLQ0 gYxIe+ju+GPCtVMLfI0h7zcNX6COW45Ggnz7zcLb9RJmAOVh0QFA+SS/p8feG3acOrj0 iHaZ4oQoqyoLEDe/sQD7+UWfaAHufa4wnngce9oxvf8bAYFnn8u8QNkVEJouXFPtpiI7 +2psFXGlZ97IvxPREX9lRKczvall17LvWDVDDNfKGlyY0FbA47ISIc/KscPxWvDlmdPm pJ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=fLlOeZX22JzLTVJFo9YrrF+8q7Dkoaj12cB+zIH9Q8s=; b=YukYh5KVRQSHenf0VXAk0ROvcUMRNb9e3YoEJLG0y6DkqcAlY/P9AXqiVhdpC37Yh0 WHVaL3YLSKc9ZygDdWObU01ElH2LpXnhRXDenTgXIBc853vAC7Y74X9+HOiruDNguF7b l06qLZxRw7BE1YezsN58gbfv/lou+jQDCwnOW/JNyaqVtwMxecDvrmAh7n1Y9OV4b5QD Al73vRa/yqI79Tl47GG5PztYTmAHOkTWPRxORNulDRBg7Rza3iO0M/wO8yskMbLKu+NM mQaqWF4gw5oydykmfrIimVvdD2qpBGyDoXp8Z5Cqb86Etmdqq7RQJ08m7U5P3dysoWtY BGjA== MIME-Version: 1.0 X-Received: by 10.52.69.229 with SMTP id h5mr2718789vdu.127.1358975842137; Wed, 23 Jan 2013 13:17:22 -0800 (PST) Received: by 10.220.141.198 with HTTP; Wed, 23 Jan 2013 13:17:22 -0800 (PST) In-Reply-To: <51004DFD.4030001@qti.qualcomm.com> References: <51004DFD.4030001@qti.qualcomm.com> Date: Wed, 23 Jan 2013 13:17:22 -0800 Message-ID: From: Anthony Mancuso To: Pete Resnick Content-Type: multipart/alternative; boundary=20cf307c9c5254358d04d3fb38b1 X-Gm-Message-State: ALoCoQkJ8rDcLbgsnAsVeHoppcF0sEfpvYlTZWf0pGYlQdEUmUilIR+cdko19lAL0Y7SpJiMPC6f0W4E/VDYy2mFqjhz0TxYmG97NQAdNnfvCX8Iwzu9i5nyRpCleKj4UGqc1uel+Qm3FuFOg1C9NjaOXxnpHzhlkwQY6dj27xPL9/TNgJ8Ty+cZtNWgEsyUFTL9mj/Gtnfx Cc: "paws@ietf.org" Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 21:17:24 -0000 --20cf307c9c5254358d04d3fb38b1 Content-Type: text/plain; charset=ISO-8859-1 Thanks Pete. I went through the list quickly and they seemed like very sensible suggestions and calls for clarification. I will go over these (and any new ones) once we hear back (or don't hear) from the WG as you suggest. Tony On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick wrote: > At long last, I got through my AD review of draft-ietf-paws-problem-stmt-* > *usecases-rqmts. I first want to say that this draft is very much > improved. The comments I have below are not (as far as I can tell) > showstoppers. I have not had a chance to go through all of the commentary > in Anthony's note from last week yet; I wanted to get this out ASAP, so if > there are things in the note that answer some of my comments below, let me > know. > > Now: Don't Panic! As I said, none of the issues are showstoppers. But the > list is long. I am willing to take direction from the chairs on this: I'll > wait at least until tomorrow to issue the IETF wide Last Call. If upon > reviewing these, the WG thinks, "Gee, if Pete didn't get the point there, > perhaps we should fix the document before issuing the Last Call", let me > know that and I'll hold off for a bit. But if you think all of these issues > can be handled easily along with the rest of the Last Call comments, I'll > go ahead and issue the Last Call and you can put these into your queue > along with any new comments received. > > So, here are the comments. If you can have a look in the next 24 hours, > that would be great. > > ------ > > Abstract: End of the first paragraph, perhaps add: "The IETF has > undertaken to develop a protocol for that management database." > > Also add the above to 1.1. > > 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the > database using a well-defined protocol." > > 2.2: For "Device ID", it says, "that identifies the manufacturer, model > number, and serial number." Does the device ID have to identify that > information? Can it simply be unique? > > "Device Class" is only used once in section 5.1. No need for the > definition here. > > "Location Based Service" is only used once in section 3. No need for the > definition here. > > "Protected Entity" is only used once in section 4.1. No need for the > definition here. > > "Protected Contour" is never used. No need for the definition at all. > > "Radio Access Technology" is only used once in section 5.1. No need for > the definition here. > > 3.1 This section (and its subsections) seems oddly placed. It is not use > cases, but general protocol services that cut across use cases. Perhaps 3.1 > and 3.2 should be separate top-level sections? > > 3.1 "A complete protocol solution must enable all potential white space > services." That seems a bit absolute. How about "must enable many different > potential white space services"? > > 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term > "master". These services exist whether a device is acting as a master for > other devices or whether it is acting on its own. Given that there's been > no discussion of slave devices yet (that happens in 3.2), I found the use > of the term "master" confusing in these sections. (I suppose you could > expand the definition of master in 2.2 to explain that it could refer to a > device acting on its own with no slaves, but I still think that might be > confusing. > > 3.1.1, item 2: This says that the device will discover the database "in > the local regulatory domain". How does the device determine the "local > regulatory domain"? I suspect that the phrase "in the local regulatory > domain" is meaningless for purposes of this sentence. If it is not, there's > something that's not explained. > > 3.1.2: Similar questions regarding regulatory domains. For example, "2. > To register with the database, the master device sends the database the > registration information required under regulatory rules." How does the > device determine which regulatory rules it is under and therefore which > information to send to the database. If the answer is, "It queries the > database", then it is not the regulatory rules the device cares about; it > is the information the database is configured to ask for (which will > presumably be in accordance to some regulations, but are out of band of any > protocol work). If the answer is, "It is pre-configured in the device", > then the regulatory rules are again out of band. Either way, mention of > them would be unnecessary. > > 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in > 2.2, it's only a slave for purposes of talking to the database. But there > is an implication in these sections that the slave device uses the master > for internet connectivity. I don't think that's the intent, but either way > there's some clarification that's needed. Further confusing me about this > point is (a) the master device is always the one in the diagrams with the > antenna, but as far as I can tell, a master device doesn't need an antenna, > the slaves do; and (b) most of the links marked "Air" seem to me not to > require an air interface, but could also be wired. I could use some > explanation. > > 3.2.1, item 7: Does the slave provide its location, device identifier, and > antenna height, the same way the master does when it queries? If so > (especially in the case of the master sub-allocating for the slaves), > doesn't the master have to provide the set of locations for all of the > slaves in step 5? Some further explanation might be in order. > > 3.2.1, item 8: It says that the white space is allocated to slaves "for > communication over the network". That's not right is it? In this scenario, > the allocated white space could be used for network (I read "Internet") > communication *or anything else*, can't it? > > 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it > be perfectly reasonable for communication between the master and slaves > continue on its original connection and that the white space is only used > for other communications the slave wishes to do? > > 3.2.2: This scenario was confusing to me because the master seems > completely unnecessary to the example. Please explain. > > 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in > the example, since there are no slaves. > > 4: "Master" seems unnecessary to the example. Also, I suggest in the > second-to-last paragraph, you say "The databases are locale specific" > instead of "country specific", and delete the word "competing" from the > last sentence of that paragraph. > > 4.1, item 1: Is this referring to the Internet connectivity between the WS > device and the database? If so, as above, does it necessarily need to be an > air interface? > > 4.1, item 3: Again I suggest changing "operate in any country" to "operate > in any locale" and change "country-specific" to "locale-specific". (The > other occurrence of "country" seems correct.) > > 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply > "domain" be sufficient? > > 5.1 and 5.2: I don't understand the distinction between "Normative" and > "Non-normative" requirements in this context. Isn't it sufficient that > you've separately labeled "Data Model Requirements", "Protocol > Requirements", and "Operational Requirements"? > > P.1: "The master device may validate the database against a list of > approved databases maintained by a regulatory body." I don't understand > that as a protocol requirement. What is being required? > > P.5 and P.6: The requirement here is for *message-level* integrity and > encryption? That's OK, but I want to make sure that's what you mean. > > P.8 and P.14: I don't think "result codes" and "response codes" are the > requirement here, are they? It sounds like the requirement is "indication > of success or failure". > > P.15: I'm not clear on what this requirement means in practical terms. > Some more explanation seems in order. > > P.16: Shouldn't this be combined with P.9? > > O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required > by the database"? > > O.3: This seems to indicate that database discovery will be out of band, > that the WG is not developing protocol to do so. Is that what you meant? If > not, this should be turned into a protocol requirement instead of an > operational requirement. > > O.4: This requirement seems a bit overly obvious and silly to state as a > requirement. Why is it necessary to say that you need a connection? > > O.5: Again, "regulatory body" seems unnecessary here. Substituting > "database" seems sufficient, since you'll be getting the rule set from the > database. > > O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change > "local regulatory policy" to "the database rule set", "determined by > regulator policy" can be "enumerated in the database rule set", etc. > > Section 7, generally: Same issue with "regulatory". See if there are any > that are more accurately "database rules". > > Threat 7: This doesn't strike me as a security consideration per se. This > might make more sense incorporated into an operational requirement. > > -- > Pete Resnick > > > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > ______________________________**_________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/**listinfo/paws > --20cf307c9c5254358d04d3fb38b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Thanks Pete. I went through the list quickly and they seem= ed like very sensible suggestions and calls for clarification. I will go ov= er these (and any new ones) once we hear back (or don't hear) from the = WG as you suggest.

    Tony


    On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
    At long last, I got through my AD review of = draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say tha= t this draft is very much improved. The comments I have below are not (as f= ar as I can tell) showstoppers. I have not had a chance to go through all o= f the commentary in Anthony's note from last week yet; I wanted to get = this out ASAP, so if there are things in the note that answer some of my co= mments below, let me know.

    Now: Don't Panic! As I said, none of the issues are showstoppers. But t= he list is long. I am willing to take direction from the chairs on this: I&= #39;ll wait at least until tomorrow to issue the IETF wide Last Call. If up= on reviewing these, the WG thinks, "Gee, if Pete didn't get the po= int there, perhaps we should fix the document before issuing the Last Call&= quot;, let me know that and I'll hold off for a bit. But if you think a= ll of these issues can be handled easily along with the rest of the Last Ca= ll comments, I'll go ahead and issue the Last Call and you can put thes= e into your queue along with any new comments received.

    So, here are the comments. If you can have a look in the next 24 hours, tha= t would be great.

    ------

    Abstract: End of the first paragraph, perhaps add: "The IETF has under= taken to develop a protocol for that management database."

    Also add the above to 1.1.

    1.2.1: Are 2 & 3 combinable? "Connect to and optionally register w= ith the database using a well-defined protocol."

    2.2: For "Device ID", it says, "that identifies the manufact= urer, model number, and serial number." Does the device ID have to ide= ntify that information? Can it simply be unique?

    "Device Class" is only used once in section 5.1. No need for the = definition here.

    "Location Based Service" is only used once in section 3. No need = for the definition here.

    "Protected Entity" is only used once in section 4.1. No need for = the definition here.

    "Protected Contour" is never used. No need for the definition at = all.

    "Radio Access Technology" is only used once in section 5.1. No ne= ed for the definition here.

    3.1 This section (and its subsections) seems oddly placed. It is not use ca= ses, but general protocol services that cut across use cases. Perhaps 3.1 a= nd 3.2 should be separate top-level sections?

    3.1 "A complete protocol solution must enable all potential white spac= e services." That seems a bit absolute. How about "must enable ma= ny different potential white space services"?

    3.1.1 & 3.1.2: Throughout this section, there's no need to use the = term "master". These services exist whether a device is acting as= a master for other devices or whether it is acting on its own. Given that = there's been no discussion of slave devices yet (that happens in 3.2), = I found the use of the term "master" confusing in these sections.= (I suppose you could expand the definition of master in 2.2 to explain tha= t it could refer to a device acting on its own with no slaves, but I still = think that might be confusing.

    3.1.1, item 2: This says that the device will discover the database "i= n the local regulatory domain". How does the device determine the &quo= t;local regulatory domain"? I suspect that the phrase "in the loc= al regulatory domain" is meaningless for purposes of this sentence. If= it is not, there's something that's not explained.

    3.1.2: Similar questions regarding regulatory domains. For example, "2= . =A0To register with the database, the master device sends the database th= e registration information required under regulatory rules." How does = the device determine which regulatory rules it is under and therefore which= information to send to the database. If the answer is, "It queries th= e database", then it is not the regulatory rules the device cares abou= t; it is the information the database is configured to ask for (which will = presumably be in accordance to some regulations, but are out of band of any= protocol work). If the answer is, "It is pre-configured in the device= ", then the regulatory rules are again out of band. Either way, mentio= n of them would be unnecessary.

    3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defin= ed in 2.2, it's only a slave for purposes of talking to the database. B= ut there is an implication in these sections that the slave device uses the= master for internet connectivity. I don't think that's the intent,= but either way there's some clarification that's needed. Further c= onfusing me about this point is (a) the master device is always the one in = the diagrams with the antenna, but as far as I can tell, a master device do= esn't need an antenna, the slaves do; and (b) most of the links marked = "Air" seem to me not to require an air interface, but could also = be wired. I could use some explanation.

    3.2.1, item 7: Does the slave provide its location, device identifier, and = antenna height, the same way the master does when it queries? If so (especi= ally in the case of the master sub-allocating for the slaves), doesn't = the master have to provide the set of locations for all of the slaves in st= ep 5? Some further explanation might be in order.

    3.2.1, item 8: It says that the white space is allocated to slaves "fo= r communication over the network". That's not right is it? In this= scenario, the allocated white space could be used for network (I read &quo= t;Internet") communication *or anything else*, can't it?

    3.2.1, item 9: Is this an important part of the scenario? Why wouldn't = it be perfectly reasonable for communication between the master and slaves = continue on its original connection and that the white space is only used f= or other communications the slave wishes to do?

    3.2.2: This scenario was confusing to me because the master seems completel= y unnecessary to the example. Please explain.

    3.2.4 and 3.2.5: Another example of the term "master" seems unnec= essary in the example, since there are no slaves.

    4: "Master" seems unnecessary to the example. Also, I suggest in = the second-to-last paragraph, you say "The databases are locale specif= ic" instead of "country specific", and delete the word "= ;competing" from the last sentence of that paragraph.

    4.1, item 1: Is this referring to the Internet connectivity between the WS = device and the database? If so, as above, does it necessarily need to be an= air interface?

    4.1, item 3: Again I suggest changing "operate in any country" to= "operate in any locale" and change "country-specific" = to "locale-specific". (The other occurrence of "country"= ; seems correct.)

    4.2: Instead of "regulatory-domain", wouldn't either "lo= cale" or simply "domain" be sufficient?

    5.1 and 5.2: I don't understand the distinction between "Normative= " and "Non-normative" requirements in this context. Isn'= t it sufficient that you've separately labeled "Data Model Require= ments", "Protocol Requirements", and "Operational Requi= rements"?

    P.1: "The master device may validate the database against a list of ap= proved databases maintained by a regulatory body." I don't underst= and that as a protocol requirement. What is being required?

    P.5 and P.6: The requirement here is for *message-level* integrity and encr= yption? That's OK, but I want to make sure that's what you mean.
    P.8 and P.14: I don't think "result codes" and "response= codes" are the requirement here, are they? It sounds like the require= ment is "indication of success or failure".

    P.15: I'm not clear on what this requirement means in practical terms. = Some more explanation seems in order.

    P.16: Shouldn't this be combined with P.9?

    O.2: The "required accuracy" is ambiguous. Do you mean, "acc= uracy required by the database"?

    O.3: This seems to indicate that database discovery will be out of band, th= at the WG is not developing protocol to do so. Is that what you meant? If n= ot, this should be turned into a protocol requirement instead of an operati= onal requirement.

    O.4: This requirement seems a bit overly obvious and silly to state as a re= quirement. Why is it necessary to say that you need a connection?

    O.5: Again, "regulatory body" seems unnecessary here. Substitutin= g "database" seems sufficient, since you'll be getting the ru= le set from the database.

    O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change = "local regulatory policy" to "the database rule set", &= quot;determined by regulator policy" can be "enumerated in the da= tabase rule set", etc.

    Section 7, generally: Same issue with "regulatory". See if there = are any that are more accurately "database rules".

    Threat 7: This doesn't strike me as a security consideration per se. Th= is might make more sense incorporated into an operational requirement.

    --
    Pete Resnick<http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

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

    --20cf307c9c5254358d04d3fb38b1-- From peter@spectrumbridge.com Wed Jan 23 13:17:56 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3F421F856D for ; Wed, 23 Jan 2013 13:17:56 -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 5AZv-m8KKUdJ for ; Wed, 23 Jan 2013 13:17:54 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 58B0F21F882E for ; Wed, 23 Jan 2013 13:17:54 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 23 Jan 2013 16:17:53 -0500 From: Peter Stanforth To: Pete Resnick , "paws@ietf.org" Date: Wed, 23 Jan 2013 16:17:47 -0500 Thread-Topic: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thread-Index: Ac35rxqyd8FZCmKvRzu8EUN6nlOahw== Message-ID: In-Reply-To: <51004DFD.4030001@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CD25B97F628Epeterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 21:17:56 -0000 --_000_CD25B97F628Epeterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some observations and comments on your review. Posted inline below, I don't= have any specific issues with what you say. Peter S. From: Pete Resnick > Date: Wednesday, January 23, 2013 3:54 PM To: "paws@ietf.org" > Subject: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 At long last, I got through my AD review of draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that this draft is very much improved. The comments I have below are not (as far as I can tell) showstoppers. I have not had a chance to go through all of the commentary in Anthony's note from last week yet; I wanted to get this out ASAP, so if there are things in the note that answer some of my comments below, let me know. Now: Don't Panic! As I said, none of the issues are showstoppers. But the list is long. I am willing to take direction from the chairs on this: I'll wait at least until tomorrow to issue the IETF wide Last Call. If upon reviewing these, the WG thinks, "Gee, if Pete didn't get the point there, perhaps we should fix the document before issuing the Last Call", let me know that and I'll hold off for a bit. But if you think all of these issues can be handled easily along with the rest of the Last Call comments, I'll go ahead and issue the Last Call and you can put these into your queue along with any new comments received. So, here are the comments. If you can have a look in the next 24 hours, that would be great. ------ Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database." Also add the above to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the database using a well-defined protocol." 2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique? Regulators are asking for manufacturer and model number as they may require= action, enforcement or denial by the DB on the set to manufacturer devices= or a specific model of device "Device Class" is only used once in section 5.1. No need for the definition here. "Location Based Service" is only used once in section 3. No need for the definition here. "Protected Entity" is only used once in section 4.1. No need for the definition here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the definition here. 3.1 This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections? 3.1 "A complete protocol solution must enable all potential white space services." That seems a bit absolute. How about "must enable many different potential white space services"? 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing. Broadcast use case is a master with no slave, at least in the context of a = slave that communicates with or is controlled by a master. 3.1.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained. The location of a device determines it regulatory domain. However the devic= e may understand this or it may be told. For instance our current US implem= entation validates that a device is within the regulatory domain. If not we= deny it service but allowed for the DB to tell the device who or what it s= hould contact. In other words you are now in Canada so you need to talk to = xxx not to and FCC DB. Taken together with the comment below this may need = some thought and additional work 3.1.2: Similar questions regarding regulatory domains. For example, "2. To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary. 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation. The FCC, as an example, has two concepts of a slave. The first is a client = served by a master, think 802.11 client using a channel served by an AP. Th= is is the model for low power devices. If the device is a high power device= the slave must get it's own channel list. It can use a master to do this, = using white space spectrum, if it has no other means of contacting the data= base. 3.2.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order. As above a low power slave, under FCC rule, does not have to provide any of= this information but a high power slave does. 3.2.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it? High power again. A slave may not get the same channel list as the master a= nd may not be able to use the channel the master is currently using so a ne= gotiation will be necessary. 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it be perfectly reasonable for communication between the master and slaves continue on its original connection and that the white space is only used for other communications the slave wishes to do? Same comment as above 3.2.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain. 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves. 4: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph. 4.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface? 4.1, item 3: Again I suggest changing "operate in any country" to "operate in any locale" and change "country-specific" to "locale-specific". (The other occurrence of "country" seems correct.) 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient? The regulatory domain is assumed to be similar to a country domain but need= not be. A database could be permitted to serve a different definition. In= the FCC case they currently limit the domain to the 12mile nautical limit = and, as we speak databases are only permitted to service the NE USA. 5.1 and 5.2: I don't understand the distinction between "Normative" and "Non-normative" requirements in this context. Isn't it sufficient that you've separately labeled "Data Model Requirements", "Protocol Requirements", and "Operational Requirements"? P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required? P.5 and P.6: The requirement here is for *message-level* integrity and encryption? That's OK, but I want to make sure that's what you mean. P.8 and P.14: I don't think "result codes" and "response codes" are the requirement here, are they? It sounds like the requirement is "indication of success or failure". P.15: I'm not clear on what this requirement means in practical terms. Some more explanation seems in order. P.16: Shouldn't this be combined with P.9? O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"? Acceptable Location Accuracy is defined by the regulator and applied to the= calculations of the database O.3: This seems to indicate that database discovery will be out of band, that the WG is not developing protocol to do so. Is that what you meant? If not, this should be turned into a protocol requirement instead of an operational requirement. O.4: This requirement seems a bit overly obvious and silly to state as a requirement. Why is it necessary to say that you need a connection? O.5: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database. General observation about this and the next couple of comments. The FCC Cer= tifies a radio and a database as a "system" Ofcom is not considering a syst= em. Other regulators may have other thoughts. In the case of the FCC some o= f the function is validated/certified, what ever you want to call it for th= e combination not as a function of one or the other. So while it seems logical to have an implementation within a database it is= not necessarily considered as such. O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change "local regulatory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc. Section 7, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules". Threat 7: This doesn't strike me as a security consideration per se. This might make more sense incorporated into an operational requirement. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CD25B97F628Epeterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
    Some observat= ions and comments on your review. Posted inline below, I don't have any spe= cific issues with what you say.
    P= eter S.

    From: Pete R= esnick <presnick@qti.qualco= mm.com>
    Date: Wednesday,= January 23, 2013 3:54 PM
    To: "= paws@ietf.org" <paws@ietf.org>
    Sub= ject: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqm= ts-10

    At long last, I got through my= AD review of
    draft-ietf-paws-problem-stmt-usecases-rqmts. I fir= st want to say that
    this draft is very much improved. The commen= ts I have below are not (as
    far as I can tell) showstoppers. I h= ave not had a chance to go through
    all of the commentary in Anth= ony's note from last week yet; I wanted to
    get this out ASAP, so= if there are things in the note that answer some
    of my comments= below, let me know.

    Now: Don't Panic! As I said, = none of the issues are showstoppers. But
    the list is long. I am = willing to take direction from the chairs on
    this: I'll wait at = least until tomorrow to issue the IETF wide Last
    Call. If upon r= eviewing these, the WG thinks, "Gee, if Pete didn't get
    the poin= t there, perhaps we should fix the document before issuing the
    L= ast Call", let me know that and I'll hold off for a bit. But if you
    <= div>think all of these issues can be handled easily along with the rest of =
    the Last Call comments, I'll go ahead and issue the Last Call an= d you
    can put these into your queue along with any new comments = received.

    So, here are the comments. If you can ha= ve a look in the next 24 hours,
    that would be great.
    <= br>
    ------

    Abstract: End of the first pa= ragraph, perhaps add: "The IETF has
    undertaken to develop a prot= ocol for that management database."

    Also add the a= bove to 1.1.

    1.2.1: Are 2 & 3 combinable? "Con= nect to and optionally register with
    the database using a well-d= efined protocol."

    2.2: For "Device ID", it says, "= that identifies the manufacturer, model
    number, and serial numbe= r." Does the device ID have to identify that
    information? Can it= simply be unique?
    Regulators are asking for manufacturer and model nu= mber as they may require action, enforcement or denial by the DB on the set= to manufacturer devices or a specific model of device
    "Device Class" is only used once in section 5.1. No need for t= he
    definition here.

    "Location Based Ser= vice" is only used once in section 3. No need for the
    definition= here.

    "Protected Entity" is only used once in sec= tion 4.1. No need for the
    definition here.

    <= div>"Protected Contour" is never used. No need for the definition at all.

    "Radio Access Technology" is only used once in sect= ion 5.1. No need for
    the definition here.

    3.1 This section (and its subsections) seems oddly placed. It is not use=
    cases, but general protocol services that cut across use cases.= Perhaps
    3.1 and 3.2 should be separate top-level sections?

    3.1 "A complete protocol solution must enable all pote= ntial white space
    services." That seems a bit absolute. How abou= t "must enable many
    different potential white space services"?

    3.1.1 & 3.1.2: Throughout this section, there's= no need to use the term
    "master". These services exist whether = a device is acting as a master
    for other devices or whether it i= s acting on its own. Given that there's
    been no discussion of sl= ave devices yet (that happens in 3.2), I found
    the use of the te= rm "master" confusing in these sections. (I suppose you
    could ex= pand the definition of master in 2.2 to explain that it could
    re= fer to a device acting on its own with no slaves, but I still think
    <= div>that might be confusing.
    Broadcast use case is a master with no sl= ave, at least in the context of a slave that communicates with or is contro= lled by a master.
    <= div style=3D"color: rgb(0, 0, 0); ">
    3.1.1, item 2: This says that the device will discover the database= "in
    the local regulatory domain= ". How does the device determine the "local
    regulatory domain"? I suspect that the phrase "in the local reg= ulatory
    domain" is meaningless f= or purposes of this sentence. If it is not,
    there's something that's not explained.
    The location of a device determines= it regulatory domain. However the device may understand this or it may be = told. For instance our current US implementation validates that a device is= within the regulatory domain. If not we deny it service but allowed for th= e DB to tell the device who or what it should contact. In other words you a= re now in Canada so you need to talk to xxx not to and FCC DB. Taken togeth= er with the comment below this may need some thought and additional work
    3.1.2: Similar questions reg= arding regulatory domains. For example, "2.  
    To register with the database, the master device sen= ds the database the
    registration= information required under regulatory rules." How does the
    device determine which regulatory rules it is u= nder and therefore which
    informa= tion to send to the database. If the answer is, "It queries the
    database", then it is not the regulatory ru= les the device cares about;
    it i= s the information the database is configured to ask for (which will
    <= div style=3D"color: rgb(0, 0, 0); ">presumably be in accordance to some reg= ulations, but are out of band of
    any protocol work). If the answer is, "It is pre-configured in the
    <= div style=3D"color: rgb(0, 0, 0); ">device", then the regulatory rules are = again out of band. Either way,
    m= ention of them would be unnecessary.

    3.2.1, 3.2.2, and 3.2.3,= in general: When "slave device" is defined in
    2.2, it's only a slave for purposes of talking to the databa= se. But
    there is an implication = in these sections that the slave device uses the
    master for internet connectivity. I don't think that's the= intent, but
    either way there's = some clarification that's needed. Further confusing
    me about this point is (a) the master device is always = the one in the
    diagrams with the= antenna, but as far as I can tell, a master device
    doesn't need an antenna, the slaves do; and (b) most of= the links marked
    "Air" seem to = me not to require an air interface, but could also be
    wired. I could use some explanation.
    The FCC, as= an example, has two concepts of a slave. The first is a client served by a= master, think 802.11 client using a channel served by an AP. This is the m= odel for low power devices. If the device is a high power device the slave = must get it's own channel list. It can use a master to do this, using white= space spectrum, if it has no other means of contacting the database.

    3.2.1, item 7: = Does the slave provide its location, device identifier,
    and antenna height, the same way the master does wh= en it queries? If so
    (especially= in the case of the master sub-allocating for the slaves),
    doesn't the master have to provide the set of lo= cations for all of the
    slaves in= step 5? Some further explanation might be in order.
    As above a low po= wer slave, under FCC rule, does not have to provide any of this information= but a high power slave does.

    3.2.1, item 8: It says that the white space is allocate= d to slaves "for
    communication o= ver the network". That's not right is it? In this
    scenario, the allocated white space could be used for net= work (I read
    "Internet") communi= cation *or anything else*, can't it?
    High power again. A slave may not get the same chann= el list as the master and may not be able to use the channel the master is = currently using so a negotiation will be necessary.

    3.2.1, item 9: Is this an important part of th= e scenario? Why wouldn't
    it be p= erfectly reasonable for communication between the master and
    slaves continue on its original connection and= that the white space is
    only us= ed for other communications the slave wishes to do?
    Same comment as above
    <= div style=3D"color: rgb(0, 0, 0); ">3.2.2: This scenario was confusing to m= e because the master seems
    compl= etely unnecessary to the example. Please explain.

    3.2.4 and 3= .2.5: Another example of the term "master" seems unnecessary
    in the example, since there are no slaves.

    4: "Master" seems unnecessary to the example. Also, I suggest in= the
    second-to-last paragraph, y= ou say "The databases are locale specific"
    instead of "country specific", and delete the word "competing" f= rom the
    last sentence of that pa= ragraph.

    4.1, item 1: Is this referring to the Internet conne= ctivity between the
    WS device an= d the database? If so, as above, does it necessarily need to
    be an air interface?

    4.1, item 3= : Again I suggest changing "operate in any country" to
    "operate in any locale" and change "country-specific= " to
    "locale-specific". (The oth= er occurrence of "country" seems correct.)

    4.2: Instead of "r= egulatory-domain", wouldn't either "locale" or simply
    "domain" be sufficient?
    = The regulatory domain is= assumed to be similar to a country domain but need not be. A database coul= d be permitted to serve  a different definition. In the FCC case they = currently limit the domain to the 12mile nautical limit and, as we speak da= tabases are only permitted to service the NE USA. 
    <= br>
    5.1 and 5.2: I don't understa= nd the distinction between "Normative" and
    "Non-normative" requirements in this context. Isn't it sufficien= t that
    you've separately labeled= "Data Model Requirements", "Protocol
    Requirements", and "Operational Requirements"?

    P.1: "Th= e master device may validate the database against a list of
    approved databases maintained by a regulatory b= ody." I don't understand
    that as= a protocol requirement. What is being required?

    P.5 and P.6:= The requirement here is for *message-level* integrity and
    encryption? That's OK, but I want to make sure t= hat's what you mean.

    P.8 and P.14: I don't think "result code= s" and "response codes" are the
    = requirement here, are they? It sounds like the requirement is
    "indication of success or failure".

    P.15: I'm not clear on what this requirement means in practical terms.=
    Some more explanation seems in = order.

    P.16: Shouldn't this be combined with P.9?

    =
    required by the database"?
    =
    Accept= able Location Accuracy is defined by the regulator and applied to the calcu= lations of the database
    =

    O.3: This seems to indicate that database discovery will be o= ut of band,
    that the WG is not d= eveloping protocol to do so. Is that what you meant?
    If not, this should be turned into a protocol requirem= ent instead of an
    operational re= quirement.

    O.4: This requirement seems a bit overly obvious= and silly to state as a
    require= ment. Why is it necessary to say that you need a connection?

    = O.5: Again, "regulatory body" seems unnecessary here. Substituting
    "database" seems sufficient, since you'l= l be getting the rule set from
    t= he database.
    G= eneral observation about this and the next couple of comments. The FCC Cert= ifies a radio and a database as a "system" Ofcom is not considering a syste= m. Other regulators may have other thoughts. In the case of the FCC some of= the function is validated/certified, what ever you want to call it for the= combination not as a function of one or the other.
    So while it= seems logical to have an implementation within a database it is not necess= arily considered as such.
    O.6 (and O.9 through O.11 and O= .13 through O.15): As above, you can
    change "local regulatory policy" to "the database rule set", "determin= ed
    by regulator policy" can be "= enumerated in the database rule set", etc.

    Section 7, general= ly: Same issue with "regulatory". See if there are any
    that are more accurately "database rules".

    Threat 7: This doesn't strike me as a security consideration per se. <= /div>
    This might make more sense incorp= orated into an operational requirement.

    --
    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________
    paws mailing list

     --_000_CD25B97F628Epeterspectrumbridgecom_-- From nbravin@earthlink.net Wed Jan 23 13:33:34 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAD721F8620 for ; Wed, 23 Jan 2013 13:33:34 -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 to48N1EyGdzb for ; Wed, 23 Jan 2013 13:33:32 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id B019621F85FD for ; Wed, 23 Jan 2013 13:33:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DroolORxiwOGXopyxd3uvurofcbGqLv5A9iLTy9joae97xGjd5zkRMQaoqGHTgYb; 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-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Ty7wU-0007Wn-3o; Wed, 23 Jan 2013 16:33:10 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A8156A0A-936A-4C73-AA21-5B3B162D828B" From: Nancy Bravin In-Reply-To: Date: Wed, 23 Jan 2013 13:33:07 -0800 Message-Id: References: To: Pete Resnick X-Mailer: Apple Mail (2.1283) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86439391d88d9afcdd2728bcaa9e46367a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 21:33:34 -0000 --Apple-Mail=_A8156A0A-936A-4C73-AA21-5B3B162D828B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think since we are dealing with a protocol that can be used globally, = terms such as listed below, with definition, will make it easier to = those countries who are not English speaking, or the translation to words, with no definition can be = confusing. It is not a deal breaker, but consideration for emerging = countries that lack experience in these=20 areas. IMHO "Device Class" is only used once in section 5.1. No need for the definition here. "Location Based Service" is only used once in section 3. No need for the definition here. "Protected Entity" is only used once in section 4.1. No need for the definition here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the definition here. Also, I do agree that air interface is not the only method.=20 Sincerely, N On Jan 23, 2013, at 1:17 PM, Peter Stanforth wrote: > Some observations and comments on your review. Posted inline below, I = don't have any specific issues with what you say. > Peter S. >=20 > From: Pete Resnick > Date: Wednesday, January 23, 2013 3:54 PM > To: "paws@ietf.org" > Subject: [paws] AD review of = draft-ietf-paws-problem-stmt-usecases-rqmts-10 >=20 > At long last, I got through my AD review of > draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that > this draft is very much improved. The comments I have below are not = (as > far as I can tell) showstoppers. I have not had a chance to go through > all of the commentary in Anthony's note from last week yet; I wanted = to > get this out ASAP, so if there are things in the note that answer some > of my comments below, let me know. >=20 > Now: Don't Panic! As I said, none of the issues are showstoppers. But > the list is long. I am willing to take direction from the chairs on > this: I'll wait at least until tomorrow to issue the IETF wide Last > Call. If upon reviewing these, the WG thinks, "Gee, if Pete didn't get > the point there, perhaps we should fix the document before issuing the > Last Call", let me know that and I'll hold off for a bit. But if you > think all of these issues can be handled easily along with the rest of > the Last Call comments, I'll go ahead and issue the Last Call and you > can put these into your queue along with any new comments received. >=20 > So, here are the comments. If you can have a look in the next 24 = hours, > that would be great. >=20 > ------ >=20 > Abstract: End of the first paragraph, perhaps add: "The IETF has > undertaken to develop a protocol for that management database." >=20 > Also add the above to 1.1. >=20 > 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with > the database using a well-defined protocol." >=20 > 2.2: For "Device ID", it says, "that identifies the manufacturer, = model > number, and serial number." Does the device ID have to identify that > information? Can it simply be unique? > Regulators are asking for manufacturer and model number as they may = require action, enforcement or denial by the DB on the set to = manufacturer devices or a specific model of device >=20 > "Device Class" is only used once in section 5.1. No need for the > definition here. >=20 > "Location Based Service" is only used once in section 3. No need for = the > definition here. >=20 > "Protected Entity" is only used once in section 4.1. No need for the > definition here. >=20 > "Protected Contour" is never used. No need for the definition at all. >=20 > "Radio Access Technology" is only used once in section 5.1. No need = for > the definition here. >=20 > 3.1 This section (and its subsections) seems oddly placed. It is not = use > cases, but general protocol services that cut across use cases. = Perhaps > 3.1 and 3.2 should be separate top-level sections? >=20 > 3.1 "A complete protocol solution must enable all potential white = space > services." That seems a bit absolute. How about "must enable many > different potential white space services"? >=20 > 3.1.1 & 3.1.2: Throughout this section, there's no need to use the = term > "master". These services exist whether a device is acting as a master > for other devices or whether it is acting on its own. Given that = there's > been no discussion of slave devices yet (that happens in 3.2), I found > the use of the term "master" confusing in these sections. (I suppose = you > could expand the definition of master in 2.2 to explain that it could > refer to a device acting on its own with no slaves, but I still think > that might be confusing. > Broadcast use case is a master with no slave, at least in the context = of a slave that communicates with or is controlled by a master. >=20 > 3.1.1, item 2: This says that the device will discover the database = "in > the local regulatory domain". How does the device determine the "local > regulatory domain"? I suspect that the phrase "in the local regulatory > domain" is meaningless for purposes of this sentence. If it is not, > there's something that's not explained. > The location of a device determines it regulatory domain. However the = device may understand this or it may be told. For instance our current = US implementation validates that a device is within the regulatory = domain. If not we deny it service but allowed for the DB to tell the = device who or what it should contact. In other words you are now in = Canada so you need to talk to xxx not to and FCC DB. Taken together with = the comment below this may need some thought and additional work > 3.1.2: Similar questions regarding regulatory domains. For example, = "2. =20 > To register with the database, the master device sends the database = the > registration information required under regulatory rules." How does = the > device determine which regulatory rules it is under and therefore = which > information to send to the database. If the answer is, "It queries the > database", then it is not the regulatory rules the device cares about; > it is the information the database is configured to ask for (which = will > presumably be in accordance to some regulations, but are out of band = of > any protocol work). If the answer is, "It is pre-configured in the > device", then the regulatory rules are again out of band. Either way, > mention of them would be unnecessary. >=20 > 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in > 2.2, it's only a slave for purposes of talking to the database. But > there is an implication in these sections that the slave device uses = the > master for internet connectivity. I don't think that's the intent, but > either way there's some clarification that's needed. Further confusing > me about this point is (a) the master device is always the one in the > diagrams with the antenna, but as far as I can tell, a master device > doesn't need an antenna, the slaves do; and (b) most of the links = marked > "Air" seem to me not to require an air interface, but could also be > wired. I could use some explanation. > The FCC, as an example, has two concepts of a slave. The first is a = client served by a master, think 802.11 client using a channel served by = an AP. This is the model for low power devices. If the device is a high = power device the slave must get it's own channel list. It can use a = master to do this, using white space spectrum, if it has no other means = of contacting the database. >=20 > 3.2.1, item 7: Does the slave provide its location, device identifier, > and antenna height, the same way the master does when it queries? If = so > (especially in the case of the master sub-allocating for the slaves), > doesn't the master have to provide the set of locations for all of the > slaves in step 5? Some further explanation might be in order. > As above a low power slave, under FCC rule, does not have to provide = any of this information but a high power slave does. >=20 > 3.2.1, item 8: It says that the white space is allocated to slaves = "for > communication over the network". That's not right is it? In this > scenario, the allocated white space could be used for network (I read > "Internet") communication *or anything else*, can't it? > High power again. A slave may not get the same channel list as the = master and may not be able to use the channel the master is currently = using so a negotiation will be necessary. >=20 > 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't > it be perfectly reasonable for communication between the master and > slaves continue on its original connection and that the white space is > only used for other communications the slave wishes to do? > Same comment as above > 3.2.2: This scenario was confusing to me because the master seems > completely unnecessary to the example. Please explain. >=20 > 3.2.4 and 3.2.5: Another example of the term "master" seems = unnecessary > in the example, since there are no slaves. >=20 > 4: "Master" seems unnecessary to the example. Also, I suggest in the > second-to-last paragraph, you say "The databases are locale specific" > instead of "country specific", and delete the word "competing" from = the > last sentence of that paragraph. >=20 > 4.1, item 1: Is this referring to the Internet connectivity between = the > WS device and the database? If so, as above, does it necessarily need = to > be an air interface? >=20 > 4.1, item 3: Again I suggest changing "operate in any country" to > "operate in any locale" and change "country-specific" to > "locale-specific". (The other occurrence of "country" seems correct.) >=20 > 4.2: Instead of "regulatory-domain", wouldn't either "locale" or = simply > "domain" be sufficient? > The regulatory domain is assumed to be similar to a country domain but = need not be. A database could be permitted to serve a different = definition. In the FCC case they currently limit the domain to the = 12mile nautical limit and, as we speak databases are only permitted to = service the NE USA.=20 >=20 > 5.1 and 5.2: I don't understand the distinction between "Normative" = and > "Non-normative" requirements in this context. Isn't it sufficient that > you've separately labeled "Data Model Requirements", "Protocol > Requirements", and "Operational Requirements"? >=20 > P.1: "The master device may validate the database against a list of > approved databases maintained by a regulatory body." I don't = understand > that as a protocol requirement. What is being required? >=20 > P.5 and P.6: The requirement here is for *message-level* integrity and > encryption? That's OK, but I want to make sure that's what you mean. >=20 > P.8 and P.14: I don't think "result codes" and "response codes" are = the > requirement here, are they? It sounds like the requirement is > "indication of success or failure". >=20 > P.15: I'm not clear on what this requirement means in practical terms. > Some more explanation seems in order. >=20 > P.16: Shouldn't this be combined with P.9? >=20 > O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy > required by the database"? > Acceptable Location Accuracy is defined by the regulator and applied = to the calculations of the database >=20 > O.3: This seems to indicate that database discovery will be out of = band, > that the WG is not developing protocol to do so. Is that what you = meant? > If not, this should be turned into a protocol requirement instead of = an > operational requirement. >=20 > O.4: This requirement seems a bit overly obvious and silly to state as = a > requirement. Why is it necessary to say that you need a connection? >=20 > O.5: Again, "regulatory body" seems unnecessary here. Substituting > "database" seems sufficient, since you'll be getting the rule set from > the database. > General observation about this and the next couple of comments. The = FCC Certifies a radio and a database as a "system" Ofcom is not = considering a system. Other regulators may have other thoughts. In the = case of the FCC some of the function is validated/certified, what ever = you want to call it for the combination not as a function of one or the = other. > So while it seems logical to have an implementation within a database = it is not necessarily considered as such. > O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can > change "local regulatory policy" to "the database rule set", = "determined > by regulator policy" can be "enumerated in the database rule set", = etc. >=20 > Section 7, generally: Same issue with "regulatory". See if there are = any > that are more accurately "database rules". >=20 > Threat 7: This doesn't strike me as a security consideration per se. > This might make more sense incorporated into an operational = requirement. >=20 > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_A8156A0A-936A-4C73-AA21-5B3B162D828B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
    I think since we are dealing with a protocol that can be used = globally, terms such as listed below, with definition, will make it = easier to those countries who are not
    English speaking, or the = translation to words, with no definition can be confusing. It is not a = deal breaker, but consideration for emerging countries that lack = experience in these 
    areas. IMHO

    "Device Class" is only used once in section 5.1. No need for = the
    definition here.

    "Location Based Service" is only = used once in section 3. No need for the
    definition here.
    "Protected Entity" is only used once in section 4.1. No need for = the
    definition here.

    "Protected Contour" is never = used. No need for the definition at all.

    "Radio = Access Technology" is only used once in section 5.1. No need = for
    the definition here.

    Also, I do agree = that air interface is not the only = method. 

    Sincerely, N

    On Jan 23, 2013, at = 1:17 PM, Peter Stanforth wrote:

    Some = observations and comments on your review. Posted inline below, I don't = have any specific issues with what you say.
    Peter S.
    From: Pete Resnick <presnick@qti.qualcomm.com>= ;
    Date: Wednesday, January = 23, 2013 3:54 PM
    To: "paws@ietf.org" <paws@ietf.org>
    Subject: [paws] AD review of = draft-ietf-paws-problem-stmt-usecases-rqmts-10

    At long last, I got through my AD review of =
    draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to = say that
    this draft is very much improved. The comments I = have below are not (as
    far as I can tell) showstoppers. I = have not had a chance to go through
    all of the commentary in = Anthony's note from last week yet; I wanted to
    get this out = ASAP, so if there are things in the note that answer some
    of = my comments below, let me know.

    Now: Don't = Panic! As I said, none of the issues are showstoppers. But =
    the list is long. I am willing to take direction from the = chairs on
    this: I'll wait at least until tomorrow to issue = the IETF wide Last
    Call. If upon reviewing these, the WG = thinks, "Gee, if Pete didn't get
    the point there, perhaps we = should fix the document before issuing the
    Last Call", let me = know that and I'll hold off for a bit. But if you
    think all = of these issues can be handled easily along with the rest of =
    the Last Call comments, I'll go ahead and issue the Last Call = and you
    can put these into your queue along with any new = comments received.

    So, here are the comments. = If you can have a look in the next 24 hours,
    that would be = great.

    ------

    Abstract: = End of the first paragraph, perhaps add: "The IETF has =
    undertaken to develop a protocol for that management = database."

    Also add the above to = 1.1.

    1.2.1: Are 2 & 3 combinable? "Connect = to and optionally register with
    the database using a = well-defined protocol."

    2.2: For "Device ID", = it says, "that identifies the manufacturer, model
    number, and = serial number." Does the device ID have to identify that =
    information? Can it simply be = unique?
    Regulators are asking for manufacturer and model = number as they may require action, enforcement or denial by the DB on = the set to manufacturer devices or a specific model of = device

    "Device Class" is only = used once in section 5.1. No need for the
    definition = here.

    "Location Based Service" is only used = once in section 3. No need for the
    definition = here.

    "Protected Entity" is only used once in = section 4.1. No need for the
    definition = here.

    "Protected Contour" is never used. No = need for the definition at all.

    "Radio Access = Technology" is only used once in section 5.1. No need for
    the = definition here.

    3.1 This section (and its = subsections) seems oddly placed. It is not use
    cases, but = general protocol services that cut across use cases. Perhaps =
    3.1 and 3.2 should be separate top-level = sections?

    3.1 "A complete protocol solution = must enable all potential white space
    services." That seems a = bit absolute. How about "must enable many
    different potential = white space services"?

    3.1.1 & 3.1.2: = Throughout this section, there's no need to use the term =
    "master". These services exist whether a device is acting as = a master
    for other devices or whether it is acting on its = own. Given that there's
    been no discussion of slave devices = yet (that happens in 3.2), I found
    the use of the term = "master" confusing in these sections. (I suppose you
    could = expand the definition of master in 2.2 to explain that it could =
    refer to a device acting on its own with no slaves, but I = still think
    that might be = confusing.
    Broadcast use case is a master with no slave, at least = in the context of a slave that communicates with or is controlled by a = master.

    3.1.1, item 2: This says that the device will discover the = database "in
    the local = regulatory domain". How does the device determine the "local
    regulatory domain"? I suspect that the = phrase "in the local regulatory
    there's something that's not = explained.
    The location of a device determines it regulatory = domain. However the device may understand this or it may be told. For = instance our current US implementation validates that a device is within = the regulatory domain. If not we deny it service but allowed for the DB = to tell the device who or what it should contact. In other words you are = now in Canada so you need to talk to xxx not to and FCC DB. Taken = together with the comment below this may need some thought and = additional work
    3.1.2: = Similar questions regarding regulatory domains. For example, = "2.  
    To register = with the database, the master device sends the database the
    registration information required under = regulatory rules." How does the
    information to send to = the database. If the answer is, "It queries the
    database", then it is not the regulatory rules the = device cares about;
    it is the = information the database is configured to ask for (which will
    presumably be in accordance to some = regulations, but are out of band of
    any protocol work). If the answer is, "It is pre-configured in the =
    device", then the regulatory = rules are again out of band. Either way,
    mention of them would be unnecessary.

    3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is = defined in
    2.2, it's only a = slave for purposes of talking to the database. But
    there is an implication in these = sections that the slave device uses the
    master for internet connectivity. I don't think that's = the intent, but
    either way = there's some clarification that's needed. Further confusing
    me about this point is (a) the master = device is always the one in the
    doesn't need an antenna, the = slaves do; and (b) most of the links marked
    "Air" seem to me not to require an air interface, but = could also be
    wired. I could = use some explanation.
    The FCC, as an example, has = two concepts of a slave. The first is a client served by a master, think = 802.11 client using a channel served by an AP. This is the model for low = power devices. If the device is a high power device the slave must get = it's own channel list. It can use a master to do this, using white space = spectrum, if it has no other means of contacting the = database.

    3.2.1, item 7: Does the slave provide its location, device = identifier,
    and antenna = height, the same way the master does when it queries? If so
    (especially in the case of the master = sub-allocating for the slaves),
    slaves in step 5? Some = further explanation might be in = order.
    As above a low power slave, under FCC rule, does not = have to provide any of this information but a high power slave = does.

    3.2.1, item 8: It says that the white space is allocated to slaves = "for
    communication over the = network". That's not right is it? In this
    scenario, the allocated white space could be used for = network (I read
    "Internet") = communication *or anything else*, can't it?
    High power again. A slave = may not get the same channel list as the master and may not be able to = use the channel the master is currently using so a negotiation will be = necessary.

    it be perfectly reasonable = for communication between the master and
    slaves continue on its original connection and that the = white space is
    only used for = other communications the slave wishes to do?
    Same comment as = above
    3.2.2: This = scenario was confusing to me because the master seems
    completely unnecessary to the example. = Please explain.

    3.2.4 and 3.2.5: Another example of the = term "master" seems unnecessary

    4: = "Master" seems unnecessary to the example. Also, I suggest in the =
    second-to-last paragraph, you = say "The databases are locale specific"
    instead of "country specific", and delete the word = "competing" from the
    last = sentence of that paragraph.
    4.1, item 1: Is this = referring to the Internet connectivity between the
    WS device and the database? If so, as = above, does it necessarily need to
    be an air interface?
    4.1, item 3: Again I = suggest changing "operate in any country" to
    "operate in any locale" and change "country-specific" to =
    "locale-specific". (The other = occurrence of "country" seems correct.)

    4.2: Instead of = "regulatory-domain", wouldn't either "locale" or simply
    "domain" be = sufficient?
    The regulatory domain is assumed to be similar to a = country domain but need not be. A database could be permitted to serve =  a different definition. In the FCC case they currently limit the = domain to the 12mile nautical limit and, as we speak databases are only = permitted to service the NE USA. 
    5.1 and 5.2: I don't = understand the distinction between "Normative" and
    "Non-normative" requirements in this = context. Isn't it sufficient that
    you've separately labeled "Data Model Requirements", "Protocol =
    Requirements", and = "Operational Requirements"?
    P.1: "The master device = may validate the database against a list of
    approved databases maintained by a regulatory body." I = don't understand
    that as a = protocol requirement. What is being required?

    P.5 and = P.6: The requirement here is for *message-level* integrity and =
    encryption? That's OK, but I = want to make sure that's what you mean.

    P.8 and P.14: I = don't think "result codes" and "response codes" are the
    requirement here, are they? It sounds = like the requirement is

    P.15: I'm not = clear on what this requirement means in practical terms.
    Some more explanation seems in = order.

    P.16: Shouldn't this be combined with = P.9?

    O.2: The "required accuracy" is = ambiguous. Do you mean, "accuracy
    required by the database"?
    Acceptable Location = Accuracy is defined by the regulator and applied to the calculations of = the database

    O.3: This seems to indicate that database discovery will be out of = band,
    that the WG is not = developing protocol to do so. Is that what you meant?
    If not, this should be turned into a = protocol requirement instead of an
    operational requirement.
    O.4: This requirement = seems a bit overly obvious and silly to state as a
    requirement. Why is it necessary to say = that you need a connection?
    O.5: Again, "regulatory = body" seems unnecessary here. Substituting
    "database" seems sufficient, since you'll be getting the = rule set from
    the = database.
    General observation about this and the next couple of = comments. The FCC Certifies a radio and a database as a "system" Ofcom = is not considering a system. Other regulators may have other thoughts. = In the case of the FCC some of the function is validated/certified, what = ever you want to call it for the combination not as a function of one or = the other.
    So while it seems logical = to have an implementation within a database it is not necessarily = considered as such.
    change "local regulatory = policy" to "the database rule set", "determined
    by regulator policy" can be "enumerated in the database = rule set", etc.

    Section 7, generally: Same issue with = "regulatory". See if there are any
    that are more accurately "database rules".

    Threat = 7: This doesn't strike me as a security consideration per se.
    This might make more sense incorporated = into an operational requirement.
    --
    Qualcomm = Technologies, Inc. - +1 (858)651-4478

    paws mailing list
    paws@ietf.org
    https://www.ietf.org/ma= ilman/listinfo/paws

    = --Apple-Mail=_A8156A0A-936A-4C73-AA21-5B3B162D828B-- From Gabor.Bajko@nokia.com Wed Jan 23 13:55:17 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631CC21F87EE for ; Wed, 23 Jan 2013 13:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 bfKzLpHwUfIm for ; Wed, 23 Jan 2013 13:55:15 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADCE21F87ED for ; Wed, 23 Jan 2013 13:55:14 -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 r0NLtA8X005989; Wed, 23 Jan 2013 23:55:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jan 2013 23:55:09 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.102]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0318.003; Wed, 23 Jan 2013 21:55:09 +0000 From: To: , Thread-Topic: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thread-Index: AQHN+a8Q9ntqfq7U1E+9E3gCOXzG+5hXdAYg Date: Wed, 23 Jan 2013 21:55:09 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> References: <51004DFD.4030001@qti.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E4760210062F008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Jan 2013 21:55:09.0754 (UTC) FILETIME=[502369A0:01CDF9B4] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 21:55:17 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760210062F008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My suggestion would be, if Tony has the time and willingness, then generate= a new version and try to address these comments, perhaps taking the clarif= ications from Peter (and any input from others if available until tomorrow)= into consideration. Thanks, Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Anthony Mancuso Sent: Wednesday, January 23, 2013 1:17 PM To: Pete Resnick Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmt= s-10 Thanks Pete. I went through the list quickly and they seemed like very sens= ible suggestions and calls for clarification. I will go over these (and any= new ones) once we hear back (or don't hear) from the WG as you suggest. Tony On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick > wrote: At long last, I got through my AD review of draft-ietf-paws-problem-stmt-us= ecases-rqmts. I first want to say that this draft is very much improved. Th= e comments I have below are not (as far as I can tell) showstoppers. I have= not had a chance to go through all of the commentary in Anthony's note fro= m last week yet; I wanted to get this out ASAP, so if there are things in t= he note that answer some of my comments below, let me know. Now: Don't Panic! As I said, none of the issues are showstoppers. But the l= ist is long. I am willing to take direction from the chairs on this: I'll w= ait at least until tomorrow to issue the IETF wide Last Call. If upon revie= wing these, the WG thinks, "Gee, if Pete didn't get the point there, perhap= s we should fix the document before issuing the Last Call", let me know tha= t and I'll hold off for a bit. But if you think all of these issues can be = handled easily along with the rest of the Last Call comments, I'll go ahead= and issue the Last Call and you can put these into your queue along with a= ny new comments received. So, here are the comments. If you can have a look in the next 24 hours, tha= t would be great. ------ Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken= to develop a protocol for that management database." Also add the above to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the d= atabase using a well-defined protocol." 2.2: For "Device ID", it says, "that identifies the manufacturer, model num= ber, and serial number." Does the device ID have to identify that informati= on? Can it simply be unique? "Device Class" is only used once in section 5.1. No need for the definition= here. "Location Based Service" is only used once in section 3. No need for the de= finition here. "Protected Entity" is only used once in section 4.1. No need for the defini= tion here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the= definition here. 3.1 This section (and its subsections) seems oddly placed. It is not use ca= ses, but general protocol services that cut across use cases. Perhaps 3.1 a= nd 3.2 should be separate top-level sections? 3.1 "A complete protocol solution must enable all potential white space ser= vices." That seems a bit absolute. How about "must enable many different po= tential white space services"? 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "ma= ster". These services exist whether a device is acting as a master for othe= r devices or whether it is acting on its own. Given that there's been no di= scussion of slave devices yet (that happens in 3.2), I found the use of the= term "master" confusing in these sections. (I suppose you could expand the= definition of master in 2.2 to explain that it could refer to a device act= ing on its own with no slaves, but I still think that might be confusing. 3.1.1, item 2: This says that the device will discover the database "in the= local regulatory domain". How does the device determine the "local regulat= ory domain"? I suspect that the phrase "in the local regulatory domain" is = meaningless for purposes of this sentence. If it is not, there's something = that's not explained. 3.1.2: Similar questions regarding regulatory domains. For example, "2. To= register with the database, the master device sends the database the regis= tration information required under regulatory rules." How does the device d= etermine which regulatory rules it is under and therefore which information= to send to the database. If the answer is, "It queries the database", then= it is not the regulatory rules the device cares about; it is the informati= on the database is configured to ask for (which will presumably be in accor= dance to some regulations, but are out of band of any protocol work). If th= e answer is, "It is pre-configured in the device", then the regulatory rule= s are again out of band. Either way, mention of them would be unnecessary. 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2,= it's only a slave for purposes of talking to the database. But there is an= implication in these sections that the slave device uses the master for in= ternet connectivity. I don't think that's the intent, but either way there'= s some clarification that's needed. Further confusing me about this point i= s (a) the master device is always the one in the diagrams with the antenna,= but as far as I can tell, a master device doesn't need an antenna, the sla= ves do; and (b) most of the links marked "Air" seem to me not to require an= air interface, but could also be wired. I could use some explanation. 3.2.1, item 7: Does the slave provide its location, device identifier, and = antenna height, the same way the master does when it queries? If so (especi= ally in the case of the master sub-allocating for the slaves), doesn't the = master have to provide the set of locations for all of the slaves in step 5= ? Some further explanation might be in order. 3.2.1, item 8: It says that the white space is allocated to slaves "for com= munication over the network". That's not right is it? In this scenario, the= allocated white space could be used for network (I read "Internet") commun= ication *or anything else*, can't it? 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it b= e perfectly reasonable for communication between the master and slaves cont= inue on its original connection and that the white space is only used for o= ther communications the slave wishes to do? 3.2.2: This scenario was confusing to me because the master seems completel= y unnecessary to the example. Please explain. 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in = the example, since there are no slaves. 4: "Master" seems unnecessary to the example. Also, I suggest in the second= -to-last paragraph, you say "The databases are locale specific" instead of = "country specific", and delete the word "competing" from the last sentence = of that paragraph. 4.1, item 1: Is this referring to the Internet connectivity between the WS = device and the database? If so, as above, does it necessarily need to be an= air interface? 4.1, item 3: Again I suggest changing "operate in any country" to "operate = in any locale" and change "country-specific" to "locale-specific". (The oth= er occurrence of "country" seems correct.) 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "do= main" be sufficient? 5.1 and 5.2: I don't understand the distinction between "Normative" and "No= n-normative" requirements in this context. Isn't it sufficient that you've = separately labeled "Data Model Requirements", "Protocol Requirements", and = "Operational Requirements"? P.1: "The master device may validate the database against a list of approve= d databases maintained by a regulatory body." I don't understand that as a = protocol requirement. What is being required? P.5 and P.6: The requirement here is for *message-level* integrity and encr= yption? That's OK, but I want to make sure that's what you mean. P.8 and P.14: I don't think "result codes" and "response codes" are the req= uirement here, are they? It sounds like the requirement is "indication of s= uccess or failure". P.15: I'm not clear on what this requirement means in practical terms. Some= more explanation seems in order. P.16: Shouldn't this be combined with P.9? O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required = by the database"? O.3: This seems to indicate that database discovery will be out of band, th= at the WG is not developing protocol to do so. Is that what you meant? If n= ot, this should be turned into a protocol requirement instead of an operati= onal requirement. O.4: This requirement seems a bit overly obvious and silly to state as a re= quirement. Why is it necessary to say that you need a connection? O.5: Again, "regulatory body" seems unnecessary here. Substituting "databas= e" seems sufficient, since you'll be getting the rule set from the database= . O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change = "local regulatory policy" to "the database rule set", "determined by regula= tor policy" can be "enumerated in the database rule set", etc. Section 7, generally: Same issue with "regulatory". See if there are any th= at are more accurately "database rules". Threat 7: This doesn't strike me as a security consideration per se. This m= ight make more sense incorporated into an operational requirement. -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760210062F008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    My suggestion would be, i= f Tony has the time and willingness, then generate a new version and try to= address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into co= nsideration.

    Thanks, Gabor<= /span>

     <= /p>

    From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Anthony Mancuso
    Sent: Wednesday, January 23, 2013 1:17 PM
    To: Pete Resnick
    Cc: paws@ietf.org
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

     

    Thanks Pete. I went through the list quickly and the= y seemed like very sensible suggestions and calls for clarification. I will= go over these (and any new ones) once we hear back (or don't hear) from th= e WG as you suggest.

     

    Tony

     

    On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <<= a href=3D"mailto:presnick@qti.qualcomm.com" target=3D"_blank">presnick@qti.= qualcomm.com> wrote:

    At long last, I got through my AD review of draft-ie= tf-paws-problem-stmt-usecases-rqmts. I first want to say that this draft is= very much improved. The comments I have below are not (as far as I can tel= l) showstoppers. I have not had a chance to go through all of the commentary in Anthony's note from last wee= k yet; I wanted to get this out ASAP, so if there are things in the note th= at answer some of my comments below, let me know.

    Now: Don't Panic! As I said, none of the issues are showstoppers. But the l= ist is long. I am willing to take direction from the chairs on this: I'll w= ait at least until tomorrow to issue the IETF wide Last Call. If upon revie= wing these, the WG thinks, "Gee, if Pete didn't get the point there, perhaps we should fix the document bef= ore issuing the Last Call", let me know that and I'll hold off for a b= it. But if you think all of these issues can be handled easily along with t= he rest of the Last Call comments, I'll go ahead and issue the Last Call and you can put these into your queue alo= ng with any new comments received.

    So, here are the comments. If you can have a look in the next 24 hours, tha= t would be great.

    ------

    Abstract: End of the first paragraph, perhaps add: "The IETF has under= taken to develop a protocol for that management database."

    Also add the above to 1.1.

    1.2.1: Are 2 & 3 combinable? "Connect to and optionally register w= ith the database using a well-defined protocol."

    2.2: For "Device ID", it says, "that identifies the manufact= urer, model number, and serial number." Does the device ID have to ide= ntify that information? Can it simply be unique?

    "Device Class" is only used once in section 5.1. No need for the = definition here.

    "Location Based Service" is only used once in section 3. No need = for the definition here.

    "Protected Entity" is only used once in section 4.1. No need for = the definition here.

    "Protected Contour" is never used. No need for the definition at = all.

    "Radio Access Technology" is only used once in section 5.1. No ne= ed for the definition here.

    3.1 This section (and its subsections) seems oddly placed. It is not use ca= ses, but general protocol services that cut across use cases. Perhaps 3.1 a= nd 3.2 should be separate top-level sections?

    3.1 "A complete protocol solution must enable all potential white spac= e services." That seems a bit absolute. How about "must enable ma= ny different potential white space services"?

    3.1.1 & 3.1.2: Throughout this section, there's no need to use the term= "master". These services exist whether a device is acting as a m= aster for other devices or whether it is acting on its own. Given that ther= e's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing = in these sections. (I suppose you could expand the definition of master in = 2.2 to explain that it could refer to a device acting on its own with no sl= aves, but I still think that might be confusing.

    3.1.1, item 2: This says that the device will discover the database "i= n the local regulatory domain". How does the device determine the &quo= t;local regulatory domain"? I suspect that the phrase "in the loc= al regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained.

    3.1.2: Similar questions regarding regulatory domains. For example, "2= .  To register with the database, the master device sends the database= the registration information required under regulatory rules." How do= es the device determine which regulatory rules it is under and therefore which information to send to the database. If th= e answer is, "It queries the database", then it is not the regula= tory rules the device cares about; it is the information the database is co= nfigured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol = work). If the answer is, "It is pre-configured in the device", th= en the regulatory rules are again out of band. Either way, mention of them = would be unnecessary.

    3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defin= ed in 2.2, it's only a slave for purposes of talking to the database. But t= here is an implication in these sections that the slave device uses the mas= ter for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed= . Further confusing me about this point is (a) the master device is always = the one in the diagrams with the antenna, but as far as I can tell, a maste= r device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me= not to require an air interface, but could also be wired. I could use some= explanation.

    3.2.1, item 7: Does the slave provide its location, device identifier, and = antenna height, the same way the master does when it queries? If so (especi= ally in the case of the master sub-allocating for the slaves), doesn't the = master have to provide the set of locations for all of the slaves in step 5? Some further explanation might = be in order.

    3.2.1, item 8: It says that the white space is allocated to slaves "fo= r communication over the network". That's not right is it? In this sce= nario, the allocated white space could be used for network (I read "In= ternet") communication *or anything else*, can't it?

    3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it b= e perfectly reasonable for communication between the master and slaves cont= inue on its original connection and that the white space is only used for o= ther communications the slave wishes to do?

    3.2.2: This scenario was confusing to me because the master seems completel= y unnecessary to the example. Please explain.

    3.2.4 and 3.2.5: Another example of the term "master" seems unnec= essary in the example, since there are no slaves.

    4: "Master" seems unnecessary to the example. Also, I suggest in = the second-to-last paragraph, you say "The databases are locale specif= ic" instead of "country specific", and delete the word "= ;competing" from the last sentence of that paragraph.

    4.1, item 1: Is this referring to the Internet connectivity between the WS = device and the database? If so, as above, does it necessarily need to be an= air interface?

    4.1, item 3: Again I suggest changing "operate in any country" to= "operate in any locale" and change "country-specific" = to "locale-specific". (The other occurrence of "country"= ; seems correct.)

    4.2: Instead of "regulatory-domain", wouldn't either "locale= " or simply "domain" be sufficient?

    5.1 and 5.2: I don't understand the distinction between "Normative&quo= t; and "Non-normative" requirements in this context. Isn't it suf= ficient that you've separately labeled "Data Model Requirements",= "Protocol Requirements", and "Operational Requirements"= ;?

    P.1: "The master device may validate the database against a list of ap= proved databases maintained by a regulatory body." I don't understand = that as a protocol requirement. What is being required?

    P.5 and P.6: The requirement here is for *message-level* integrity and encr= yption? That's OK, but I want to make sure that's what you mean.

    P.8 and P.14: I don't think "result codes" and "response cod= es" are the requirement here, are they? It sounds like the requirement= is "indication of success or failure".

    P.15: I'm not clear on what this requirement means in practical terms. Some= more explanation seems in order.

    P.16: Shouldn't this be combined with P.9?

    O.2: The "required accuracy" is ambiguous. Do you mean, "acc= uracy required by the database"?

    O.3: This seems to indicate that database discovery will be out of band, th= at the WG is not developing protocol to do so. Is that what you meant? If n= ot, this should be turned into a protocol requirement instead of an operati= onal requirement.

    O.4: This requirement seems a bit overly obvious and silly to state as a re= quirement. Why is it necessary to say that you need a connection?

    O.5: Again, "regulatory body" seems unnecessary here. Substitutin= g "database" seems sufficient, since you'll be getting the rule s= et from the database.

    O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change = "local regulatory policy" to "the database rule set", &= quot;determined by regulator policy" can be "enumerated in the da= tabase rule set", etc.

    Section 7, generally: Same issue with "regulatory". See if there = are any that are more accurately "database rules".

    Threat 7: This doesn't strike me as a security consideration per se. This m= ight make more sense incorporated into an operational requirement.

    --
    Pete Resnick<http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________
    paws mailing list
    p= aws@ietf.org
    https://www.ietf.org/mailman/listinfo/paws<= /span>

     

    --_000_1ECAFF543A2FED4EA2BEB6CACE08E4760210062F008AM1MPN1006mg_-- From amancuso@google.com Wed Jan 23 14:04:49 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B4721F8757 for ; Wed, 23 Jan 2013 14:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.416 X-Spam-Level: X-Spam-Status: No, score=-101.416 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 f0uym2OrnFKL for ; Wed, 23 Jan 2013 14:04:48 -0800 (PST) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by ietfa.amsl.com (Postfix) with ESMTP id 90FCE21F8749 for ; Wed, 23 Jan 2013 14:04:47 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id jz10so1174626veb.35 for ; Wed, 23 Jan 2013 14:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ucYXJEELB2BX7/K32lhJqlkoHMzAlCrZ0ucsN0XBGgo=; b=AZosZxvOxpVRzy+7QTJHt/XJaRnr3z4Jf8TPREu1Va0KuM2/zW8EbOxfilgLlUWaoN pAJezKOyNvG0i+Z2TiYoOVk4Cr7qpwyZCrRdzUOnNK89z6RXsjLF8f5hCd4hrIjQIQPQ SdU2k8WlPOTCnLeGSBLKHVQ+H2RtGDxU1G5f3Jf/+qnB09RxM8RY0Bb7ZlZGLwKxmHLv y1PrdfBXJ5dKaPooXkpKBVcv+PikDq6dfkd3r9AdX59IhaiSJu7/UOpC7aRmHAudYj8U UZfdBDF2Yu2+7fWNIWg7LiD6r3mGNsaRjrgAeuw2IJDeHIgtnnPzPw9Va/nKnrlXYEYJ MbOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ucYXJEELB2BX7/K32lhJqlkoHMzAlCrZ0ucsN0XBGgo=; b=o+LbHXN+FtVbJo6Zcp5DC5Xn4rbtCOLpAKYLcpU+Dxki0I4fRXGuEa+ztUWCYjLULF PvjAv9Wp8toElpMSAmy/0QsoEQmoDyguKVcGBR1Zey5aO10ob1t7+AJaF4XVyKwndS9+ n+ZfXB1CLtztdtHYtfOEchGcauM031ZDzwQnAwj1DDGxHSGT8r33EanDaA8pvB5c+UzU bOWf3yYIwOPiqKoc+/mk/911NH7IGsDgCS4CYor72PMMm4bbL0atl1wt2XgGM7Y/wWik yfM8XxaGRUax3pwaRtFCR6299Sb9dadZHB9dxXDJgy7Dq301bTOO7D6+k8LsQgX+uf9r Hdww== MIME-Version: 1.0 X-Received: by 10.52.19.241 with SMTP id i17mr2825821vde.67.1358978686857; Wed, 23 Jan 2013 14:04:46 -0800 (PST) Received: by 10.220.141.198 with HTTP; Wed, 23 Jan 2013 14:04:46 -0800 (PST) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> Date: Wed, 23 Jan 2013 14:04:46 -0800 Message-ID: From: Anthony Mancuso To: Gabor Bajko Content-Type: multipart/alternative; boundary=20cf30780bdae3306e04d3fbe10d X-Gm-Message-State: ALoCoQnAi+HHBrnzOSJ1mYus3ahNWJmjQBEuoYsDZyBlhNlt8Wv6uHMoRMhujptI4UM0667STLLc5i9Rm3cn7jvMDHkeFfFlGrTGTfCtWo6Pa3dvrBLrCuKI1NXMcR/MjXETwlRcCxsUMmmh8+U1/Cpv6rBl5OXVJenmV/X+xtzfceLZ0HGn3/Sb2Tct393D/bGDialqTHSU Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 22:04:49 -0000 --20cf30780bdae3306e04d3fbe10d Content-Type: text/plain; charset=ISO-8859-1 Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications. On Wed, Jan 23, 2013 at 1:55 PM, wrote: > My suggestion would be, if Tony has the time and willingness, then > generate a new version and try to address these comments, perhaps taking > the clarifications from Peter (and any input from others if available until > tomorrow) into consideration. **** > > Thanks, Gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Anthony Mancuso > *Sent:* Wednesday, January 23, 2013 1:17 PM > *To:* Pete Resnick > *Cc:* paws@ietf.org > *Subject:* Re: [paws] AD review of > draft-ietf-paws-problem-stmt-usecases-rqmts-10**** > > ** ** > > Thanks Pete. I went through the list quickly and they seemed like very > sensible suggestions and calls for clarification. I will go over these (and > any new ones) once we hear back (or don't hear) from the WG as you suggest. > **** > > ** ** > > Tony**** > > ** ** > > On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick > wrote:**** > > At long last, I got through my AD review of > draft-ietf-paws-problem-stmt-usecases-rqmts. I first want to say that this > draft is very much improved. The comments I have below are not (as far as I > can tell) showstoppers. I have not had a chance to go through all of the > commentary in Anthony's note from last week yet; I wanted to get this out > ASAP, so if there are things in the note that answer some of my comments > below, let me know. > > Now: Don't Panic! As I said, none of the issues are showstoppers. But the > list is long. I am willing to take direction from the chairs on this: I'll > wait at least until tomorrow to issue the IETF wide Last Call. If upon > reviewing these, the WG thinks, "Gee, if Pete didn't get the point there, > perhaps we should fix the document before issuing the Last Call", let me > know that and I'll hold off for a bit. But if you think all of these issues > can be handled easily along with the rest of the Last Call comments, I'll > go ahead and issue the Last Call and you can put these into your queue > along with any new comments received. > > So, here are the comments. If you can have a look in the next 24 hours, > that would be great. > > ------ > > Abstract: End of the first paragraph, perhaps add: "The IETF has > undertaken to develop a protocol for that management database." > > Also add the above to 1.1. > > 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the > database using a well-defined protocol." > > 2.2: For "Device ID", it says, "that identifies the manufacturer, model > number, and serial number." Does the device ID have to identify that > information? Can it simply be unique? > > "Device Class" is only used once in section 5.1. No need for the > definition here. > > "Location Based Service" is only used once in section 3. No need for the > definition here. > > "Protected Entity" is only used once in section 4.1. No need for the > definition here. > > "Protected Contour" is never used. No need for the definition at all. > > "Radio Access Technology" is only used once in section 5.1. No need for > the definition here. > > 3.1 This section (and its subsections) seems oddly placed. It is not use > cases, but general protocol services that cut across use cases. Perhaps 3.1 > and 3.2 should be separate top-level sections? > > 3.1 "A complete protocol solution must enable all potential white space > services." That seems a bit absolute. How about "must enable many different > potential white space services"? > > 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term > "master". These services exist whether a device is acting as a master for > other devices or whether it is acting on its own. Given that there's been > no discussion of slave devices yet (that happens in 3.2), I found the use > of the term "master" confusing in these sections. (I suppose you could > expand the definition of master in 2.2 to explain that it could refer to a > device acting on its own with no slaves, but I still think that might be > confusing. > > 3.1.1, item 2: This says that the device will discover the database "in > the local regulatory domain". How does the device determine the "local > regulatory domain"? I suspect that the phrase "in the local regulatory > domain" is meaningless for purposes of this sentence. If it is not, there's > something that's not explained. > > 3.1.2: Similar questions regarding regulatory domains. For example, "2. > To register with the database, the master device sends the database the > registration information required under regulatory rules." How does the > device determine which regulatory rules it is under and therefore which > information to send to the database. If the answer is, "It queries the > database", then it is not the regulatory rules the device cares about; it > is the information the database is configured to ask for (which will > presumably be in accordance to some regulations, but are out of band of any > protocol work). If the answer is, "It is pre-configured in the device", > then the regulatory rules are again out of band. Either way, mention of > them would be unnecessary. > > 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in > 2.2, it's only a slave for purposes of talking to the database. But there > is an implication in these sections that the slave device uses the master > for internet connectivity. I don't think that's the intent, but either way > there's some clarification that's needed. Further confusing me about this > point is (a) the master device is always the one in the diagrams with the > antenna, but as far as I can tell, a master device doesn't need an antenna, > the slaves do; and (b) most of the links marked "Air" seem to me not to > require an air interface, but could also be wired. I could use some > explanation. > > 3.2.1, item 7: Does the slave provide its location, device identifier, and > antenna height, the same way the master does when it queries? If so > (especially in the case of the master sub-allocating for the slaves), > doesn't the master have to provide the set of locations for all of the > slaves in step 5? Some further explanation might be in order. > > 3.2.1, item 8: It says that the white space is allocated to slaves "for > communication over the network". That's not right is it? In this scenario, > the allocated white space could be used for network (I read "Internet") > communication *or anything else*, can't it? > > 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it > be perfectly reasonable for communication between the master and slaves > continue on its original connection and that the white space is only used > for other communications the slave wishes to do? > > 3.2.2: This scenario was confusing to me because the master seems > completely unnecessary to the example. Please explain. > > 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in > the example, since there are no slaves. > > 4: "Master" seems unnecessary to the example. Also, I suggest in the > second-to-last paragraph, you say "The databases are locale specific" > instead of "country specific", and delete the word "competing" from the > last sentence of that paragraph. > > 4.1, item 1: Is this referring to the Internet connectivity between the WS > device and the database? If so, as above, does it necessarily need to be an > air interface? > > 4.1, item 3: Again I suggest changing "operate in any country" to "operate > in any locale" and change "country-specific" to "locale-specific". (The > other occurrence of "country" seems correct.) > > 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply > "domain" be sufficient? > > 5.1 and 5.2: I don't understand the distinction between "Normative" and > "Non-normative" requirements in this context. Isn't it sufficient that > you've separately labeled "Data Model Requirements", "Protocol > Requirements", and "Operational Requirements"? > > P.1: "The master device may validate the database against a list of > approved databases maintained by a regulatory body." I don't understand > that as a protocol requirement. What is being required? > > P.5 and P.6: The requirement here is for *message-level* integrity and > encryption? That's OK, but I want to make sure that's what you mean. > > P.8 and P.14: I don't think "result codes" and "response codes" are the > requirement here, are they? It sounds like the requirement is "indication > of success or failure". > > P.15: I'm not clear on what this requirement means in practical terms. > Some more explanation seems in order. > > P.16: Shouldn't this be combined with P.9? > > O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required > by the database"? > > O.3: This seems to indicate that database discovery will be out of band, > that the WG is not developing protocol to do so. Is that what you meant? If > not, this should be turned into a protocol requirement instead of an > operational requirement. > > O.4: This requirement seems a bit overly obvious and silly to state as a > requirement. Why is it necessary to say that you need a connection? > > O.5: Again, "regulatory body" seems unnecessary here. Substituting > "database" seems sufficient, since you'll be getting the rule set from the > database. > > O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change > "local regulatory policy" to "the database rule set", "determined by > regulator policy" can be "enumerated in the database rule set", etc. > > Section 7, generally: Same issue with "regulatory". See if there are any > that are more accurately "database rules". > > Threat 7: This doesn't strike me as a security consideration per se. This > might make more sense incorporated into an operational requirement. > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > --20cf30780bdae3306e04d3fbe10d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
    Good suggestion Gabor. I will wait another day or so and t= hen start on generating a new version in response to the comments and clari= fications.


    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> wrote:

    My suggestion would be, i= f Tony has the time and willingness, then generate a new version and try to= address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into co= nsideration.

    Thanks, Gabor

    =A0<= /p>

    From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Anthony Mancuso
    Sent: Wednesday, January 23, 2013 1:17 PM
    To: Pete Resnick
    Cc: paws@ietf.org=
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

    =A0

    Thanks Pete. I went through the list quickly and the= y seemed like very sensible suggestions and calls for clarification. I will= go over these (and any new ones) once we hear back (or don't hear) fro= m the WG as you suggest.

    =A0

    Tony

    =A0

    On Wed, Jan 23, 2013 at 12:54 PM, Pete Resnick <<= a href=3D"mailto:presnick@qti.qualcomm.com" target=3D"_blank">presnick@qti.= qualcomm.com> wrote:

    At long last, I got through my AD review of draft-ie= tf-paws-problem-stmt-usecases-rqmts. I first want to say that this draft is= very much improved. The comments I have below are not (as far as I can tel= l) showstoppers. I have not had a chance to go through all of the commentary in Anthony's note from last= week yet; I wanted to get this out ASAP, so if there are things in the not= e that answer some of my comments below, let me know.

    Now: Don't Panic! As I said, none of the issues are showstoppers. But t= he list is long. I am willing to take direction from the chairs on this: I&= #39;ll wait at least until tomorrow to issue the IETF wide Last Call. If up= on reviewing these, the WG thinks, "Gee, if Pete didn't get the point there, perhaps we should fix the document= before issuing the Last Call", let me know that and I'll hold off= for a bit. But if you think all of these issues can be handled easily alon= g with the rest of the Last Call comments, I'll go ahead and issue the Last Call and you can put these into your queue alo= ng with any new comments received.

    So, here are the comments. If you can have a look in the next 24 hours, tha= t would be great.

    ------

    Abstract: End of the first paragraph, perhaps add: "The IETF has under= taken to develop a protocol for that management database."

    Also add the above to 1.1.

    1.2.1: Are 2 & 3 combinable? "Connect to and optionally register w= ith the database using a well-defined protocol."

    2.2: For "Device ID", it says, "that identifies the manufact= urer, model number, and serial number." Does the device ID have to ide= ntify that information? Can it simply be unique?

    "Device Class" is only used once in section 5.1. No need for the = definition here.

    "Location Based Service" is only used once in section 3. No need = for the definition here.

    "Protected Entity" is only used once in section 4.1. No need for = the definition here.

    "Protected Contour" is never used. No need for the definition at = all.

    "Radio Access Technology" is only used once in section 5.1. No ne= ed for the definition here.

    3.1 This section (and its subsections) seems oddly placed. It is not use ca= ses, but general protocol services that cut across use cases. Perhaps 3.1 a= nd 3.2 should be separate top-level sections?

    3.1 "A complete protocol solution must enable all potential white spac= e services." That seems a bit absolute. How about "must enable ma= ny different potential white space services"?

    3.1.1 & 3.1.2: Throughout this section, there's no need to use the = term "master". These services exist whether a device is acting as= a master for other devices or whether it is acting on its own. Given that = there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing = in these sections. (I suppose you could expand the definition of master in = 2.2 to explain that it could refer to a device acting on its own with no sl= aves, but I still think that might be confusing.

    3.1.1, item 2: This says that the device will discover the database "i= n the local regulatory domain". How does the device determine the &quo= t;local regulatory domain"? I suspect that the phrase "in the loc= al regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained.
    3.1.2: Similar questions regarding regulatory domains. For example, "2= . =A0To register with the database, the master device sends the database th= e registration information required under regulatory rules." How does = the device determine which regulatory rules it is under and therefore which information to send to the database. If th= e answer is, "It queries the database", then it is not the regula= tory rules the device cares about; it is the information the database is co= nfigured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol = work). If the answer is, "It is pre-configured in the device", th= en the regulatory rules are again out of band. Either way, mention of them = would be unnecessary.

    3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defin= ed in 2.2, it's only a slave for purposes of talking to the database. B= ut there is an implication in these sections that the slave device uses the= master for internet connectivity. I don't think that's the intent, but either way there's some clarification that&= #39;s needed. Further confusing me about this point is (a) the master devic= e is always the one in the diagrams with the antenna, but as far as I can t= ell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me= not to require an air interface, but could also be wired. I could use some= explanation.

    3.2.1, item 7: Does the slave provide its location, device identifier, and = antenna height, the same way the master does when it queries? If so (especi= ally in the case of the master sub-allocating for the slaves), doesn't = the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might = be in order.

    3.2.1, item 8: It says that the white space is allocated to slaves "fo= r communication over the network". That's not right is it? In this= scenario, the allocated white space could be used for network (I read &quo= t;Internet") communication *or anything else*, can't it?

    3.2.1, item 9: Is this an important part of the scenario? Why wouldn't = it be perfectly reasonable for communication between the master and slaves = continue on its original connection and that the white space is only used f= or other communications the slave wishes to do?

    3.2.2: This scenario was confusing to me because the master seems completel= y unnecessary to the example. Please explain.

    3.2.4 and 3.2.5: Another example of the term "master" seems unnec= essary in the example, since there are no slaves.

    4: "Master" seems unnecessary to the example. Also, I suggest in = the second-to-last paragraph, you say "The databases are locale specif= ic" instead of "country specific", and delete the word "= ;competing" from the last sentence of that paragraph.

    4.1, item 1: Is this referring to the Internet connectivity between the WS = device and the database? If so, as above, does it necessarily need to be an= air interface?

    4.1, item 3: Again I suggest changing "operate in any country" to= "operate in any locale" and change "country-specific" = to "locale-specific". (The other occurrence of "country"= ; seems correct.)

    4.2: Instead of "regulatory-domain", wouldn't either "lo= cale" or simply "domain" be sufficient?

    5.1 and 5.2: I don't understand the distinction between "Normative= " and "Non-normative" requirements in this context. Isn'= t it sufficient that you've separately labeled "Data Model Require= ments", "Protocol Requirements", and "Operational Requi= rements"?

    P.1: "The master device may validate the database against a list of ap= proved databases maintained by a regulatory body." I don't underst= and that as a protocol requirement. What is being required?

    P.5 and P.6: The requirement here is for *message-level* integrity and encr= yption? That's OK, but I want to make sure that's what you mean.
    P.8 and P.14: I don't think "result codes" and "response= codes" are the requirement here, are they? It sounds like the require= ment is "indication of success or failure".

    P.15: I'm not clear on what this requirement means in practical terms. = Some more explanation seems in order.

    P.16: Shouldn't this be combined with P.9?

    O.2: The "required accuracy" is ambiguous. Do you mean, "acc= uracy required by the database"?

    O.3: This seems to indicate that database discovery will be out of band, th= at the WG is not developing protocol to do so. Is that what you meant? If n= ot, this should be turned into a protocol requirement instead of an operati= onal requirement.

    O.4: This requirement seems a bit overly obvious and silly to state as a re= quirement. Why is it necessary to say that you need a connection?

    O.5: Again, "regulatory body" seems unnecessary here. Substitutin= g "database" seems sufficient, since you'll be getting the ru= le set from the database.

    O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change = "local regulatory policy" to "the database rule set", &= quot;determined by regulator policy" can be "enumerated in the da= tabase rule set", etc.

    Section 7, generally: Same issue with "regulatory". See if there = are any that are more accurately "database rules".

    Threat 7: This doesn't strike me as a security consideration per se. Th= is might make more sense incorporated into an operational requirement.

    --
    Pete Resnick<http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________
    paws mailing list
    paws@ietf.org<= /span>
    https://www.ietf.org/mailman/listinfo/paws    <= /u>

    =A0


    --20cf30780bdae3306e04d3fbe10d-- From presnick@qti.qualcomm.com Wed Jan 23 14:10:41 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4969421F8598 for ; Wed, 23 Jan 2013 14:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 b+gWKrkfbbqN for ; Wed, 23 Jan 2013 14:10:39 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id C3FEC21F858C for ; Wed, 23 Jan 2013 14:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1358977880; x=1390513880; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=6Pmc14JBz6oXCGVhELHhQhGKapK9UFVt55et5wW0ntQ=; b=zYceYyDuyBRWt7Wqg1LD8Zq9wwjB6VG+teVpt8sjBp9kYyAxqILN7c6I pXPyeIYVBmO/39/Qdg4GY1FKGan5RnA+o3b8mUHB75HZfn1lyWZuLTZEu XMFFCYcbRItwM3kTLesrySDFb0HUBgfvQDr1nU2IaipA3lVUNOuZbupH5 E=; X-IronPort-AV: E=Sophos;i="4.84,523,1355126400"; d="scan'208,217";a="17702834" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 23 Jan 2013 13:51:18 -0800 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jan 2013 14:10:36 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 14:10:36 -0800 Message-ID: <51005FDA.4020300@qti.qualcomm.com> Date: Wed, 23 Jan 2013 16:10:34 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Anthony Mancuso References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090400080304000606090706" X-Originating-IP: [172.30.39.5] Cc: "paws@ietf.org" Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 22:10:41 -0000 --------------090400080304000606090706 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit One hitch: If you make the call by EOB tomorrow, I can get the Last Call sent out, which means (assuming the LC goes well) I can get it on the IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat. pr On 1/23/13 4:04 PM, Anthony Mancuso wrote: > Good suggestion Gabor. I will wait another day or so and then start on > generating a new version in response to the comments and clarifications. > > > On Wed, Jan 23, 2013 at 1:55 PM, > wrote: > > My suggestion would be, if Tony has the time and willingness, then > generate a new version and try to address these comments, perhaps > taking the clarifications from Peter (and any input from others if > available until tomorrow) into consideration. > > Thanks, Gabor > > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------090400080304000606090706 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit One hitch: If you make the call by EOB tomorrow, I can get the Last Call sent out, which means (assuming the LC goes well) I can get it on the IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:
    Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications.


    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> wrote:

    My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration.

    Thanks, Gabor



    -- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    --------------090400080304000606090706-- From brian.rosen@neustar.biz Wed Jan 23 14:19:29 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805EF21F87EE for ; Wed, 23 Jan 2013 14:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 iB3yMnQ0nyUR for ; Wed, 23 Jan 2013 14:19:28 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7521F85E0 for ; Wed, 23 Jan 2013 14:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1358979418; x=1674333144; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=FdbCVEo8ZsegSn8m+bHzZ8YgdLobkYTRrm6kw4Wtcdc=; b=hZ7Nlqg4Ev8M893HeyUdZUyYqmPClmbmPqg17tftahvRiBsBMEaLEPLYddK7u3 QZ48bNbjqCcuPjvVgSoRtKew== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.15707519; Wed, 23 Jan 2013 17:16:57 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 23 Jan 2013 17:19:14 -0500 From: "Rosen, Brian" To: Pete Resnick Date: Wed, 23 Jan 2013 17:19:14 -0500 Thread-Topic: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thread-Index: Ac35t61XzfxUKOjrRpSAuBI6gLBH6w== Message-ID: <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> In-Reply-To: <51005FDA.4020300@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: okhX5ruk3GJ5IiqX5KpBLA== Content-Type: multipart/alternative; boundary="_000_785693F1D60A46B0AA694CA8C8045ACBneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 22:19:29 -0000 --_000_785693F1D60A46B0AA694CA8C8045ACBneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think if Tony can spin a rev before EOB tomorrow, we should do that, but = I'm thinking that the current rev is good enough, and I'd prefer to get it = into the Feb 7 telechat. I don't feel very strongly about that, but=85 Brian On Jan 23, 2013, at 5:10 PM, Pete Resnick > wrote: One hitch: If you make the call by EOB tomorrow, I can get the Last Call se= nt out, which means (assuming the LC goes well) I can get it on the IESG te= lechat Feb 7. If we have to wait two additional weeks until the Feb 14 tele= chat, it's not a huge deal, but we have to say "go" or "no go" to the Last = Call by EOB tomorrow for me to sneak it on to the earlier telechat. pr On 1/23/13 4:04 PM, Anthony Mancuso wrote: Good suggestion Gabor. I will wait another day or so and then start on gene= rating a new version in response to the comments and clarifications. On Wed, Jan 23, 2013 at 1:55 PM, > wrote: My suggestion would be, if Tony has the time and willingness, then generate= a new version and try to address these comments, perhaps taking the clarif= ications from Peter (and any input from others if available until tomorrow)= into consideration. Thanks, Gabor -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_785693F1D60A46B0AA694CA8C8045ACBneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think if Tony can s= pin a rev before EOB tomorrow, we should do that, but I'm thinking that the= current rev is good enough, and I'd prefer to get it into the Feb 7 telech= at.  

    I don't feel very strongly about that, but=85=

    Brian

    On Jan 23, 2013, at= 5:10 PM, Pete Resnick <pre= snick@qti.qualcomm.com> wrote:

    One hitch: If you make the call by EOB tomorrow, I can get the Last Call sent out, which means (assuming the LC goes well) I can get it on the IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:
    Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications.


    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> wrote:

    My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration.

    Thanks, Gabor



    --=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    _______________________________________________
    paws mailing list
    paws@ietf.org
    https://www.ietf.org/mai= lman/listinfo/paws

    = --_000_785693F1D60A46B0AA694CA8C8045ACBneustarbiz_-- From amancuso@google.com Wed Jan 23 14:54:44 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BD021F8786 for ; Wed, 23 Jan 2013 14:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.582 X-Spam-Level: X-Spam-Status: No, score=-101.582 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 qeDdrVA7R3A7 for ; Wed, 23 Jan 2013 14:54:43 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1825C21F874F for ; Wed, 23 Jan 2013 14:54:43 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id cz11so1221854veb.11 for ; Wed, 23 Jan 2013 14:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NprjEPjvVMwM1xqXQACDMlPjnsmcT/OhBHEvEr5Uoy8=; b=o3p8L4DjPdZYtniba2SZM+HcEBaMGFv0zR03/lvYnsMa2dW9pgUL1Kz927bdkVAkWu A6t4GRiMR7UJAkVw72LE+Z5KnmmfPGYZV7OxTW3yGT90SGUp9SjiBN4OX/YAqEui0m20 TlFf6H1bNZa7cuIIZH0GlvpBT56V6+Se6Zln+1su2b1XoD/E9gkhjUxUoN9ut42AzlUd g0hAGPHuNgIX91MRQnNcO+wuBTxc8XnxSjk4hWncnt0rc6PMJNEU6Q12X+NekIRXTEkm ixO+F+wD9/njeOHGhtpggEawn93GQErfWTawNLGA84M2dnjxvKBr9z2LWm4i/ARzJIhi 1uxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=NprjEPjvVMwM1xqXQACDMlPjnsmcT/OhBHEvEr5Uoy8=; b=P7cZfQBDVSgFcHExg1MTWgpvNxs8+hKOMGPgI6+UxhE5+NkULFL5JzdcPYtclWs39i r3EpuIcEXnvp7HVMbe5ENuNO5nT7VbMhcghigiDKFwke0SjEctLlYMq60+bDbPJAUOTN pkFdca1v76z5XJjAf0qmG0u/ZU1+JCcv9KOLk5nnwMsm4NJJF6V4Paut+O/sbmtrfI5j wz+VQseV363peWTvDfygrPkt1qD7Q3lWVyRXOSq5IQbnq1I0WD3seyk+fRMs9NNlEbu1 XtH7f3RUItrffGzs1Pu5S0FMkppr35Fm5I0FvXkKp5AgX8UDiOi6xb+FF4XPVcKdeaEe wFwg== MIME-Version: 1.0 X-Received: by 10.52.69.229 with SMTP id h5mr3001024vdu.127.1358981682292; Wed, 23 Jan 2013 14:54:42 -0800 (PST) Received: by 10.220.141.198 with HTTP; Wed, 23 Jan 2013 14:54:42 -0800 (PST) In-Reply-To: <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> Date: Wed, 23 Jan 2013 14:54:42 -0800 Message-ID: From: Anthony Mancuso To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=20cf307c9c526de88904d3fc948d X-Gm-Message-State: ALoCoQk+CEGFkV3B8QqBmL+hV5cK9mpTDriRZ4Zd4orurg1CHM2yhFbd9SOGB3DRDytzUD0QBWrh4LhdFUh1XKn5p5uO8YnMnJLBQaAFLxrY9TtBXjMtJ7qA29TFN2LBSPzpSmBwSx3TW9zNbDYpzQe6zWJSYvrT2vQpxUF353rp21YbMUPPoDRvs7jqV3pSUhh+85Va7Tp3 Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 22:54:44 -0000 --20cf307c9c526de88904d3fc948d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I',m not sure I can turn around the doc by tomorrow since there are some technical points I need to collaborate on. On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian wrot= e: > I think if Tony can spin a rev before EOB tomorrow, we should do that, bu= t > I'm thinking that the current rev is good enough, and I'd prefer to get i= t > into the Feb 7 telechat. > > I don't feel very strongly about that, but=85 > > Brian > > On Jan 23, 2013, at 5:10 PM, Pete Resnick > wrote: > > One hitch: If you make the call by EOB tomorrow, I can get the Last Call > sent out, which means (assuming the LC goes well) I can get it on the IES= G > telechat Feb 7. If we have to wait two additional weeks until the Feb 14 > telechat, it's not a huge deal, but we have to say "go" or "no go" to the > Last Call by EOB tomorrow for me to sneak it on to the earlier telechat. > > pr > > On 1/23/13 4:04 PM, Anthony Mancuso wrote: > > Good suggestion Gabor. I will wait another day or so and then start on > generating a new version in response to the comments and clarifications. > > > On Wed, Jan 23, 2013 at 1:55 PM, wrote: > >> My suggestion would be, if Tony has the time and willingness, then >> generate a new version and try to address these comments, perhaps taking >> the clarifications from Peter (and any input from others if available un= til >> tomorrow) into consideration. >> >> Thanks, Gabor >> >> > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > _______________________________________________ > > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > --20cf307c9c526de88904d3fc948d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    I',m not sure I can turn around the doc by tomorrow si= nce there are some technical points I need to collaborate on.


    On Wed, Jan 23, 2013 = at 2:19 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wro= te:
    I think = if Tony can spin a rev before EOB tomorrow, we should do that, but I'm = thinking that the current rev is good enough, and I'd prefer to get it = into the Feb 7 telechat. =A0

    I don't feel very strongly about that, but=85

    Brian

    On Jan 23, 2013, at 5= :10 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

    =20
    One hitch: If you make the call by EOB tomorrow, I can get the Last Call sent out, which means (assuming the LC goes well) I can get it on the IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal, but we have to say "go&= quot; or "no go" to the Last Call by EOB tomorrow for me to sneak it on to= the earlier telechat.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:
    Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications.


    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.B= ajko@nokia.com> wrote:

    My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration.

    Thank= s, Gabor



    --=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    _______________________________________________

    paws m= ailing list
    paws@ietf= .org
    https://www.ietf.org/mailman/listinfo/paws


    --20cf307c9c526de88904d3fc948d-- From presnick@qti.qualcomm.com Wed Jan 23 14:59:26 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7AE21F88F7 for ; Wed, 23 Jan 2013 14:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 lVLU-QN14Dji for ; Wed, 23 Jan 2013 14:59:24 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6801721F8881 for ; Wed, 23 Jan 2013 14:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1358980805; x=1390516805; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ncZccsLwb2PVWG2W+u3igG1GYCtpRlhYxf/wY7CxmOA=; b=E9ECgHwlkR7tBS6Lr9UQBe8ldJwdfIAwyy8lTc82DTHQb99R3t+RZgKc CG7sPp1MF8y7EAMYptvI2lLY/V3HmTGy/66Sj9f6rtPFI87/eIlytIBN0 gJxBhrBP+qG98BjCy2k6MWETfOfMQRQmF1emMpPqPFtgDQ3Usc2mIqeOM E=; X-IronPort-AV: E=Sophos;i="4.84,524,1355126400"; d="scan'208,217";a="17717549" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 23 Jan 2013 14:39:51 -0800 X-IronPort-AV: E=Sophos;i="4.84,524,1355126400"; d="scan'208,217";a="408752835" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jan 2013 14:59:10 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 14:59:10 -0800 Message-ID: <51006B3C.8010104@qti.qualcomm.com> Date: Wed, 23 Jan 2013 16:59:08 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Anthony Mancuso References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070405090702030709080709" X-Originating-IP: [172.30.39.5] Cc: "paws@ietf.org" Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 22:59:26 -0000 --------------070405090702030709080709 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no go" with the Last Call, even if there is no new draft ready to go. We can Last Call -10 if nobody thinks there's a strong reason to wait. I am fine with either path. pr On 1/23/13 4:54 PM, Anthony Mancuso wrote: > I',m not sure I can turn around the doc by tomorrow since there are > some technical points I need to collaborate on. > > > On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian > wrote: > > I think if Tony can spin a rev before EOB tomorrow, we should do > that, but I'm thinking that the current rev is good enough, and > I'd prefer to get it into the Feb 7 telechat. > > I don't feel very strongly about that, but... > > Brian > > On Jan 23, 2013, at 5:10 PM, Pete Resnick > > wrote: > >> One hitch: If you make the call by EOB tomorrow, I can get the >> Last Call sent out, which means (assuming the LC goes well) I can >> get it on the IESG telechat Feb 7. If we have to wait two >> additional weeks until the Feb 14 telechat, it's not a huge deal, >> but we have to say "go" or "no go" to the Last Call by EOB >> tomorrow for me to sneak it on to the earlier telechat. >> >> pr >> >> On 1/23/13 4:04 PM, Anthony Mancuso wrote: >>> Good suggestion Gabor. I will wait another day or so and then >>> start on generating a new version in response to the comments >>> and clarifications. >>> >>> >>> On Wed, Jan 23, 2013 at 1:55 PM, >> > wrote: >>> >>> My suggestion would be, if Tony has the time and >>> willingness, then generate a new version and try to address >>> these comments, perhaps taking the clarifications from Peter >>> (and any input from others if available until tomorrow) into >>> consideration. >>> >>> Thanks, Gabor >>> >>> >> >> -- >> Pete Resnick >> Qualcomm Technologies, Inc. -+1 (858)651-4478 >> _______________________________________________ >> >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------070405090702030709080709 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no go" with the Last Call, even if there is no new draft ready to go. We can Last Call -10 if nobody thinks there's a strong reason to wait. I am fine with either path.

    pr

    On 1/23/13 4:54 PM, Anthony Mancuso wrote:
    I',m not sure I can turn around the doc by tomorrow since there are some technical points I need to collaborate on.


    On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <Brian.Rosen@neustar.biz> wrote:
    I think if Tony can spin a rev before EOB tomorrow, we should do that, but I'm thinking that the current rev is good enough, and I'd prefer to get it into the Feb 7 telechat.  

    I don't feel very strongly about that, but…

    Brian

    On Jan 23, 2013, at 5:10 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:

    One hitch: If you make the call by EOB tomorrow, I can get the Last Call sent out, which means (assuming the LC goes well) I can get it on the IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to the Last Call by EOB tomorrow for me to sneak it on to the earlier telechat.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:
    Good suggestion Gabor. I will wait another day or so and then start on generating a new version in response to the comments and clarifications.


    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> wrote:

    My suggestion would be, if Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (and any input from others if available until tomorrow) into consideration.

    Thanks, Gabor



    -- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    _______________________________________________

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



    -- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    --------------070405090702030709080709-- From presnick@qti.qualcomm.com Wed Jan 23 15:21:19 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CD921F882D for ; Wed, 23 Jan 2013 15:21:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jMVOHG+ikFZR for ; Wed, 23 Jan 2013 15:21:17 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id F268C21F8814 for ; Wed, 23 Jan 2013 15:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1358982116; x=1390518116; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ET74jukhjjPcA01Ebg2cNCBiPT+ec/Ss+A/Odzg/ERE=; b=ndRb/aFVbgov2fujqFQ3CvhfaJ/JCDKeWiM7tZzzjVCzfi6HNDjqGe9Y 2zv6DzDcyM7fWmUXgHQK1jhdLoicgToXjlYeXiJ8dNWgber5o+58rUTgI xIkzvVf28riNXXyxpbJA3TlpXlfiFgDLFt/AgCyaN4+yA2Ncyzygp4hLZ o=; X-IronPort-AV: E=Sophos;i="4.84,524,1355126400"; d="scan'208,217";a="17722005" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 23 Jan 2013 15:01:55 -0800 Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jan 2013 15:21:13 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 23 Jan 2013 15:18:10 -0800 Message-ID: <51006FAF.7050007@qti.qualcomm.com> Date: Wed, 23 Jan 2013 17:18:07 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060900020101090608080900" X-Originating-IP: [172.30.39.5] Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 23 Jan 2013 23:21:19 -0000 --------------060900020101090608080900 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Replying to both Nancy and Peter. Trimming as I go: On 1/23/13 3:33 PM, Nancy Bravin wrote: > I think since we are dealing with a protocol that can be used > globally, terms such as listed below, with definition, will make it > easier to those countries who are not English speaking, or the > translation to words, with no definition can be confusing. It is not a > deal breaker, but consideration for emerging countries that lack > experience in these areas. IMHO Sorry, I think I wasn't clear enough. Other than "Protected Contour" (which is not used anywhere), I was not suggesting having *no* definition of the terms listed. I was just saying that if they only occur once in the document, define them inline where they are used instead of in the definitions section. But that's strictly an editorial comment. Entirely up to you all whether you want to make a change. > On Jan 23, 2013, at 1:17 PM, Peter Stanforth wrote: > >>> 2.2: For "Device ID", it says, "that identifies the manufacturer, model >>> number, and serial number." Does the device ID have to identify that >>> information? Can it simply be unique? >> >> Regulators are asking for manufacturer and model number as they may >> require action, enforcement or denial by the DB on the set to >> manufacturer devices or a specific model of device I guess the question is: Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about manufacturer or model or etc.? >>> 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term >>> "master". These services exist whether a device is acting as a master >>> for other devices or whether it is acting on its own. Given that >>> there's >>> been no discussion of slave devices yet (that happens in 3.2), I found >>> the use of the term "master" confusing in these sections. (I suppose >>> you >>> could expand the definition of master in 2.2 to explain that it could >>> refer to a device acting on its own with no slaves, but I still think >>> that might be confusing. >> Broadcast use case is a master with no slave, at least in the context >> of a slave that communicates with or is controlled by a master. So are you saying we do or do not need the term "master" in these sections? >>> 3.1.1, item 2: This says that the device will discover the database "in >>> the local regulatory domain". How does the device determine the "local >>> regulatory domain"? I suspect that the phrase "in the local regulatory >>> domain" is meaningless for purposes of this sentence. If it is not, >>> there's something that's not explained. >> >> The location of a device determines it regulatory domain. However the >> device may understand this or it may be told. Right. That seems to indicate that the device that this section should say, "for its current location" and not "in the local regulatory domain". The device needs to know its location, but not its regulatory domain. >> For instance our current US implementation validates that a device is >> within the regulatory domain. If not we deny it service but allowed >> for the DB to tell the device who or what it should contact. In other >> words you are now in Canada so you need to talk to xxx not to and FCC >> DB. Taken together with the comment below this may need some thought >> and additional work I think we're on the same page. >>> 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in >>> 2.2, it's only a slave for purposes of talking to the database. But >>> there is an implication in these sections that the slave device uses >>> the >>> master for internet connectivity. I don't think that's the intent, but >>> either way there's some clarification that's needed. Further confusing >>> me about this point is (a) the master device is always the one in the >>> diagrams with the antenna, but as far as I can tell, a master device >>> doesn't need an antenna, the slaves do; and (b) most of the links >>> marked >>> "Air" seem to me not to require an air interface, but could also be >>> wired. I could use some explanation. >> The FCC, as an example, has two concepts of a slave. The first is a >> client served by a master, think 802.11 client using a channel served >> by an AP. This is the model for low power devices. OK, but does the low power device actually ever request white space spectrum? If not, then it is not involved in this protocol, right? >> If the device is a high power device the slave must get it's own >> channel list. It can use a master to do this, using white space >> spectrum, if it has no other means of contacting the database. This I understood until you said "using white space spectrum". It can't use white space spectrum to talk to the master until it is allocated spectrum by the database, can it? It talks to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then stops talking to the master, correct? >>> 3.2.1, item 7: Does the slave provide its location, device identifier, >>> and antenna height, the same way the master does when it queries? If so >>> (especially in the case of the master sub-allocating for the slaves), >>> doesn't the master have to provide the set of locations for all of the >>> slaves in step 5? Some further explanation might be in order. >> As above a low power slave, under FCC rule, does not have to provide >> any of this information but a high power slave does. Does a low power slave talk to the database at all? >>> 3.2.1, item 8: It says that the white space is allocated to slaves "for >>> communication over the network". That's not right is it? In this >>> scenario, the allocated white space could be used for network (I read >>> "Internet") communication *or anything else*, can't it? >> >> High power again. A slave may not get the same channel list as the >> master and may not be able to use the channel the master is currently >> using so a negotiation will be necessary. I'm not sure whether you agree or disagree with my point here. I don't understand your reply. >>> 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply >>> "domain" be sufficient? >> >> The regulatory domain is assumed to be similar to a country domain >> but need not be. A database could be permitted to serve a different >> definition. In the FCC case they currently limit the domain to the >> 12mile nautical limit and, as we speak databases are only permitted >> to service the NE USA. I don't think you answered my question. >>> O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy >>> required by the database"? >> Acceptable Location Accuracy is defined by the regulator and applied >> to the calculations of the database So the database will tell the device what level of accuracy is required? >>> O.5: Again, "regulatory body" seems unnecessary here. Substituting >>> "database" seems sufficient, since you'll be getting the rule set from >>> the database. >> >> So while it seems logical to have an implementation within a database >> it is not necessarily considered as such. Again, I'm not understand your reply. Can you expand on what you mean here? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------060900020101090608080900 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Replying to both Nancy and Peter. Trimming as I go:

    On 1/23/13 3:33 PM, Nancy Bravin wrote:

    I think since we are dealing with a protocol that can be used globally, terms such as listed below, with definition, will make it easier to those countries who are not English speaking, or the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration for emerging countries that lack experience in these areas. IMHO

    Sorry, I think I wasn't clear enough. Other than "Protected Contour" (which is not used anywhere), I was not suggesting having *no* definition of the terms listed. I was just saying that if they only occur once in the document, define them inline where they are used instead of in the definitions section. But that's strictly an editorial comment. Entirely up to you all whether you want to make a change.

    On Jan 23, 2013, at 1:17 PM, Peter Stanforth wrote:

    2.2: For "Device ID", it says, "that identifies the manufacturer, model
    number, and serial number." Does the device ID have to identify that
    information? Can it simply be unique?

    Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device

    I guess the question is: Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about manufacturer or model or etc.?

    3.1.1 & 3.1.2: Throughout this section, there's no need to use the term
    "master". These services exist whether a device is acting as a master
    for other devices or whether it is acting on its own. Given that there's
    been no discussion of slave devices yet (that happens in 3.2), I found
    the use of the term "master" confusing in these sections. (I suppose you
    could expand the definition of master in 2.2 to explain that it could
    refer to a device acting on its own with no slaves, but I still think
    that might be confusing.
    Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master.

    So are you saying we do or do not need the term "master" in these sections?

    3.1.1, item 2: This says that the device will discover the database "in
    the local regulatory domain". How does the device determine the "local
    regulatory domain"? I suspect that the phrase "in the local regulatory
    domain" is meaningless for purposes of this sentence. If it is not,
    there's something that's not explained.

    The location of a device determines it regulatory domain. However the device may understand this or it may be told.

    Right. That seems to indicate that the device that this section should say, "for its current location" and not "in the local regulatory domain". The device needs to know its location, but not its regulatory domain.

    For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work

    I think we're on the same page.

    3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in
    2.2, it's only a slave for purposes of talking to the database. But
    there is an implication in these sections that the slave device uses the
    master for internet connectivity. I don't think that's the intent, but
    either way there's some clarification that's needed. Further confusing
    me about this point is (a) the master device is always the one in the
    diagrams with the antenna, but as far as I can tell, a master device
    doesn't need an antenna, the slaves do; and (b) most of the links marked
    "Air" seem to me not to require an air interface, but could also be
    wired. I could use some explanation.
    The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices.

    OK, but does the low power device actually ever request white space spectrum? If not, then it is not involved in this protocol, right?

    If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database.

    This I understood until you said "using white space spectrum". It can't use white space spectrum to talk to the master until it is allocated spectrum by the database, can it? It talks to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then stops talking to the master, correct?

    3.2.1, item 7: Does the slave provide its location, device identifier,
    and antenna height, the same way the master does when it queries? If so
    (especially in the case of the master sub-allocating for the slaves),
    doesn't the master have to provide the set of locations for all of the
    slaves in step 5? Some further explanation might be in order.
    As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does.

    Does a low power slave talk to the database at all?

    3.2.1, item 8: It says that the white space is allocated to slaves "for
    communication over the network". That's not right is it? In this
    scenario, the allocated white space could be used for network (I read
    "Internet") communication *or anything else*, can't it?

    High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary.

    I'm not sure whether you agree or disagree with my point here. I don't understand your reply.

    4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply
    "domain" be sufficient?

    The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve  a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA.

    I don't think you answered my question.

    O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy
    required by the database"?
    Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database

    So the database will tell the device what level of accuracy is required?

    O.5: Again, "regulatory body" seems unnecessary here. Substituting
    "database" seems sufficient, since you'll be getting the rule set from
    the database.

    So while it seems logical to have an implementation within a database it is not necessarily considered as such.

    Again, I'm not understand your reply. Can you expand on what you mean here?

    pr
    -- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    --------------060900020101090608080900-- From Gabor.Bajko@nokia.com Thu Jan 24 15:19:39 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3AF21F84D1 for ; Thu, 24 Jan 2013 15:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 SGRGkqC7fnyV for ; Thu, 24 Jan 2013 15:19:37 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7311E8099 for ; Thu, 24 Jan 2013 15:19:33 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0ONJRE3026718; Fri, 25 Jan 2013 01:19:28 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.48]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jan 2013 01:19:27 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.102]) by 008-AM1MMR1-014.mgdnok.nokia.com ([2002:4136:1e30::4136:1e30]) with mapi id 14.02.0318.003; Thu, 24 Jan 2013 23:19:26 +0000 From: To: , Thread-Topic: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thread-Index: AQHN+byyNFmWFpS8ZkC5k82Cn7eFBZhXhwYAgAGXd6A= Date: Thu, 24 Jan 2013 23:19:26 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> In-Reply-To: <51006B3C.8010104@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.187.158] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47602100C61008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Jan 2013 23:19:27.0656 (UTC) FILETIME=[414BC280:01CDFA89] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 24 Jan 2013 23:19:39 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602100C61008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Will wait for Tony to generate a new version by addressing the received com= ments, before issuing the Last Call. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Pete Resnick Sent: Wednesday, January 23, 2013 2:59 PM To: Anthony Mancuso Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmt= s-10 Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no = go" with the Last Call, even if there is no new draft ready to go. We can L= ast Call -10 if nobody thinks there's a strong reason to wait. I am fine wi= th either path. pr On 1/23/13 4:54 PM, Anthony Mancuso wrote: I',m not sure I can turn around the doc by tomorrow since there are some te= chnical points I need to collaborate on. On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian > wrote: I think if Tony can spin a rev before EOB tomorrow, we should do that, but = I'm thinking that the current rev is good enough, and I'd prefer to get it = into the Feb 7 telechat. I don't feel very strongly about that, but... Brian On Jan 23, 2013, at 5:10 PM, Pete Resnick > wrote: One hitch: If you make the call by EOB tomorrow, I can get the Last Call se= nt out, which means (assuming the LC goes well) I can get it on the IESG te= lechat Feb 7. If we have to wait two additional weeks until the Feb 14 tele= chat, it's not a huge deal, but we have to say "go" or "no go" to the Last = Call by EOB tomorrow for me to sneak it on to the earlier telechat. pr On 1/23/13 4:04 PM, Anthony Mancuso wrote: Good suggestion Gabor. I will wait another day or so and then start on gene= rating a new version in response to the comments and clarifications. On Wed, Jan 23, 2013 at 1:55 PM, > wrote: My suggestion would be, if Tony has the time and willingness, then generate= a new version and try to address these comments, perhaps taking the clarif= ications from Peter (and any input from others if available until tomorrow)= into consideration. Thanks, Gabor -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602100C61008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Will wait for Tony to gen= erate a new version by addressing the received comments, before issuing the= Last Call.

     <= /p>

    - =          Gabor<= /span>

     <= /p>

    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of ext Pete Resnick
    Sent: Wednesday, January 23, 2013 2:59 PM
    To: Anthony Mancuso
    Cc: paws@ietf.org
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

     

    Like I said, I'll await word from Brian and Gabor to= morrow for "go" or "no go" with the Last Call, even if = there is no new draft ready to go. We can Last Call -10 if nobody thinks th= ere's a strong reason to wait. I am fine with either path.

    pr

    On 1/23/13 4:54 PM, Anthony Mancuso wrote:

    I',m not sure I can turn around the doc by tomorrow = since there are some technical points I need to collaborate on.<= /p>

     

    On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <Brian.Rosen@neus= tar.biz> wrote:

    I think if Tony can spin a rev before EOB tomorrow, = we should do that, but I'm thinking that the current rev is good enough, an= d I'd prefer to get it into the Feb 7 telechat.  

     

    I don't feel very strongly about that, but…

     

    Brian

     

    On Jan 23, 2013, at 5:10 PM, Pete Resnick <presnick@qti.qualc= omm.com> wrote:

     

    One hitch: If you make the call by EOB tomorrow, I c= an get the Last Call sent out, which means (assuming the LC goes well) I ca= n get it on the IESG telechat Feb 7. If we have to wait two additional week= s until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to= the Last Call by EOB tomorrow for me to sneak it on to the earlier telecha= t.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:

    Good suggestion Gabor. I will wait another day or so= and then start on generating a new version in response to the comments and= clarifications.

     

    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> w= rote:

    My suggestion would be, if Tony has the= time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (a= nd any input from others if available until tomorrow) into consideration.

    Thanks, Gabor

     



    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________

     

     



    -- 
    Pete Resnick <http:/=
/www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478
    --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602100C61008AM1MPN1006mg_-- From internet-drafts@ietf.org Fri Jan 25 09:41:06 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1CA21F87FA; Fri, 25 Jan 2013 09:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 xS-dZCo5XjwZ; Fri, 25 Jan 2013 09:41:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F0E21F8863; Fri, 25 Jan 2013 09:41:05 -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: <20130125174105.9789.84833.idtracker@ietfa.amsl.com> Date: Fri, 25 Jan 2013 09:41:05 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-11.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, 25 Jan 2013 17:41:06 -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-11.txt Pages : 27 Date : 2013-01-25 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 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. The IETF has undertaken to develop a Protocol to Access Spectrum Database [1] for such a management database. 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From amancuso@google.com Fri Jan 25 09:51:45 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D8621F884B for ; Fri, 25 Jan 2013 09:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.138 X-Spam-Level: X-Spam-Status: No, score=-102.138 tagged_above=-999 required=5 tests=[AWL=0.611, 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 vz-nNvt5JZCk for ; Fri, 25 Jan 2013 09:51:42 -0800 (PST) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1647621F8443 for ; Fri, 25 Jan 2013 09:51:42 -0800 (PST) Received: by mail-vb0-f53.google.com with SMTP id b23so470020vbz.12 for ; Fri, 25 Jan 2013 09:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=upwP2bW+Xu3Jhy1imFctjAP6QmGAHaVRELEc83Xeu2Q=; b=WQOI/8ztG7UiKEdlfdBfAQMb4nwUjTyeY5rWk+Wzfe4y8BS5pByIQVCjv9BPIvoaMc k1SsDWtgxgrWhb0NzCNxHNjfyv724qKp+ib13/DS1QV9LYTxarp9ZQ8lNncdxym5qwUA CRgpKc5bWZqSRMXYreHaQbVD8NGHQqdscTToR6ffWabBSgbBsvOr/o07qBDH8jj8GGNv tQNMVwgczTb1GRMFoRmZE7PKHmFMOYtmJGnd2oOQIh2nZUR08wXIsEYQJH3tzbscstrF +i/L1CJXgbpgGNCdDtuSBbmmgDso59JjhksIlE85aoOpGS9gsnGZk+qTe3BruxAMGhSE /ZQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=upwP2bW+Xu3Jhy1imFctjAP6QmGAHaVRELEc83Xeu2Q=; b=RIge2bV3L1M8HVmA96S1+2WS6nZN4pJrB+9brVbuDUzFHr51qy6p8yejNS51sAV5at OzOyPyThkco6MTVIetO3nB0voDfFcTNs243pp7TeLobWzuz+mkNLRNb4UMcesdEtxkwN iZ8HJDeJT4sDQd96DG7WM4bcFuXjFgg9Axg/JtDtM5qBc5iBvYDGghQ7+dX+Fp1fQ+3e T/AERjHN4suKRfr1PJXRN2DfYmtJJpT40Gs6oL79xx0Rrn0EMe4UfsTzPPtC+++i5cQg D93rFWcZ6rBu86DGpJ9pW1DmxPtKZGj3fH+iLapLN96x0rns0aKMjyS3NghiBoZXFjLo lFoA== MIME-Version: 1.0 X-Received: by 10.220.153.143 with SMTP id k15mr6981842vcw.13.1359136301437; Fri, 25 Jan 2013 09:51:41 -0800 (PST) Received: by 10.220.141.198 with HTTP; Fri, 25 Jan 2013 09:51:41 -0800 (PST) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> Date: Fri, 25 Jan 2013 09:51:41 -0800 Message-ID: From: Anthony Mancuso To: Gabor Bajko Content-Type: multipart/alternative; boundary=f46d043d677172d26904d420942c X-Gm-Message-State: ALoCoQldO0skqJryV/a6LYd6RRfpGQGTOrApLH7NYxJmv8Iu7gyY/EeFz5CAzM/QHHCaFlovvaUvwbmvF5MzlUuON2c0R1Y4H9thFw5Z5g9Ao7bSRSBDAq43FPWDWMz9wsg4WsqGT8R/7M7JEbgPJ5SriNOSXajxejRE2WdPTsFe9e0twNwxseAaM9GMZZ3KPAsFlpI5AklL Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 25 Jan 2013 17:51:45 -0000 --f46d043d677172d26904d420942c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I just posted version 11 of the PAWS Use Case & Requirements draft to IETF. In this draft, I responded to several of the comments posted to the list; I left a few TODOs, and am awaiting further comments for the next draft. My notes are in preparing this version are set out below. Tony Mancuso *************** Tony Mancuso Notes - PAWS Use Case & Requirements Notes v. 11 (I consolidated Pete Resnick's initial comments with other comments received on selected points together with my responses) Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database." ___ Mancuso: Done _____ Also add the above to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the database using a well-defined protocol." _____ Mancuso: Done: _____ 2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique? ____ Stanforth: Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device _____ Resnick: I guess the question is: Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about manufacturer or model or etc.? _____ Mancuso: Waiting for further comment. _____ "Device Class" is only used once in section 5.1. No need for the definition here. "Location Based Service" is only used once in section 3. No need for the definition here. "Protected Entity" is only used once in section 4.1. No need for the definition here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the definition here. _____ Nancy Bravin: I think since we are dealing with a protocol that can be used globally, terms such as listed below, with definition, will make it easier to those countries who are not English speaking, or the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration for emerging countries that lack experience in these areas. _____ Resnick: Sorry, I think I wasn't clear enough. Other than "Protected Contour" (which is not used anywhere), I was not suggesting having *no* definition of the terms listed. I was just saying that if they only occur once in the document, define them inline where they are used instead of in the definitions section. But that's strictly an editorial comment. Entirely up to you all whether you want to make a change. _____ Mancuso: Deleted Protected Contour, and moved the definition of single-use terms into the text. _____ 3.1 This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections? --- Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); Use Cases now in new Section 4. _____ 3.1 "A complete protocol solution must enable all potential white space services." That seems a bit absolute. How about "must enable many different potential white space services"? ____ Mancuso: Done. _____ 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing. _____ Stanforth: Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master. _____ Resnick: So are you saying we do or do not need the term "master" in these sections? _____ Mancuso: I clarified the definition of master device: "A device that queries a database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information.". I think this definition plus the definition of a slave device ("A device that queries the database through a Master Device.") makes the use of the term in the section appropriate -- namely, a master device is one that contacts a database to obtain spectrum (for itself or other devices). Slave devices under these definitions, do not contact the db directly, omitting them from the discussion at this point makes sense. Another way of saying it: we use the term master only as a way of describing a device used to query the db directly for spectrum availability. Denoting a device as master does not necessarily imply the use of slaves (devices that are not used to query the db directly) in a particular use case. _______________ 3.1.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained. _____ Stanforth: The location of a device determines it regulatory domain. However the device may understand this or it may be told. _____ Resnick: Right. That seems to indicate that the device that this section should say, "for its current location" and not "in the local regulatory domain". The device needs to know its location, but not its regulatory domain. _____ Stanforth: For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work. _____ Resnick: I think we're on the same page. _____ Mancuso: The intent of the existing wording is simply that the master sends out a request and waits for a response, not to imply that it the device query is constrained or qualified by the device's understanding of its regulatory domain. I deleted the extra language to read as follows: "The master device constructs and sends a service request over the Internet." _______ 3.1.2: Similar questions regarding regulatory domains. For example, "2. To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary. ___ Mancuso: Agreed. Again, I think this was simply a matter of misphrasing. Deleted the extra language to read: "To register with the database, the master device sends registration information to the database." _____ 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation. _____ Stanforth The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices. _____ Resnick: OK, but does the low power device actually ever request white space spectrum? If not, then it is not involved in this protocol, right? ___ Stanforth: If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database. ____ Resnick: This I understood until you said "using white space spectrum". It can't use white space spectrum to talk to the master until it is allocated spectrum by the database, can it? It talks to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then stops talking to the master, correct? ____ Mancuso: Waiting for any further input. _____ 3.2.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order. _____ Stanforth: As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does. _____ Resnick: Does a low power slave talk to the database at all? _____ Mancuso: Waiting for any further input. ______ 3.2.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it? _____ Stanforth: High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary. _____ Resnick: I'm not sure whether you agree or disagree with my point here. I don't understand your reply. _____ Mancuso: Waiting for any further input. _____ 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it be perfectly reasonable for communication between the master and slaves continue on its original connection and that the white space is only used for other communications the slave wishes to do? _____ Stanforth: same as Iten 8, above. ____ Mancuso: TODO. _____ 3.2.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain. _____ Mancuso: TODO. The master is optionally used by the slave to query the db for spectrum. And again, master only connotes ability to query the db directly by the device. I do think we need to eliminate the implication that the slave then connects to the Internet through the master (it uses white space spectrum, right)? _____ 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves. ____ Mancuso: Again, master only connotes ability to query the db directly by the device. ____ 4: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph. ________ Mancuso: Same response re masters as above. Made the suggested wording changes re "locale" and "competing." _____ 4.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface? ___ Mancuso: TODO _____ 4.1, item 3: Again I suggest changing "operate in any country" to "operate in any locale" and change "country-specific" to "locale-specific". (The other occurrence of "country" seems correct.) ____ Mancuso: Made suggested wording changes. _____ 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient? _____ Stanforth: The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA. _____ Resnick: I don't think you answered my question. _____ Mancuso: I changed to "domain specific". Not that the db may not be locale-based (a South American country may opt for FCC domain rules). _____ 5.1 and 5.2: I don't understand the distinction between "Normative" and "Non-normative" requirements in this context. Isn't it sufficient that you've separately labeled "Data Model Requirements", "Protocol Requirements", and "Operational Requirements"? _____ Mancuso: Agreed. Changed the heads and organization. _____ Mancuso: Remaining items TODO. _____ P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required? P.5 and P.6: The requirement here is for *message-level* integrity and encryption? That's OK, but I want to make sure that's what you mean. P.8 and P.14: I don't think "result codes" and "response codes" are the requirement here, are they? It sounds like the requirement is "indication of success or failure". P.15: I'm not clear on what this requirement means in practical terms. Some more explanation seems in order. P.16: Shouldn't this be combined with P.9? O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"? _____ Stanforth: Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database _____ Resnick: So the database will tell the device what level of accuracy is required? _____ O.3: This seems to indicate that database discovery will be out of band, that the WG is not developing protocol to do so. Is that what you meant? If not, this should be turned into a protocol requirement instead of an operational requirement. O.4: This requirement seems a bit overly obvious and silly to state as a requirement. Why is it necessary to say that you need a connection? O.5: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database. _____ Stanforth: General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" Ofcom is not considering a system. Other regulators may have other thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the combination not as a function of one or the other. So while it seems logical to have an implementation within a database it is not necessarily considered as such. _____ Resnick: Again, I'm not understand your reply. Can you expand on what you mean here? _____ O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change "local regulatory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc. Section 7, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules". Threat 7: This doesn't strike me as a security consideration per se. This might make more sense incorporated into an operational requirement. On Thu, Jan 24, 2013 at 3:19 PM, wrote: > Will wait for Tony to generate a new version by addressing the received > comments, before issuing the Last Call.**** > > ** ** > > **- **Gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Pete Resnick > *Sent:* Wednesday, January 23, 2013 2:59 PM > *To:* Anthony Mancuso > > *Cc:* paws@ietf.org > *Subject:* Re: [paws] AD review of > draft-ietf-paws-problem-stmt-usecases-rqmts-10**** > > ** ** > > Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "n= o > go" with the Last Call, even if there is no new draft ready to go. We can > Last Call -10 if nobody thinks there's a strong reason to wait. I am fine > with either path. > > > pr > > On 1/23/13 4:54 PM, Anthony Mancuso wrote: **** > > I',m not sure I can turn around the doc by tomorrow since there are some > technical points I need to collaborate on.**** > > ** ** > > On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian > wrote:**** > > I think if Tony can spin a rev before EOB tomorrow, we should do that, bu= t > I'm thinking that the current rev is good enough, and I'd prefer to get i= t > into the Feb 7 telechat. **** > > ** ** > > I don't feel very strongly about that, but=85**** > > ** ** > > Brian**** > > ** ** > > On Jan 23, 2013, at 5:10 PM, Pete Resnick > wrote:**** > > ** ** > > One hitch: If you make the call by EOB tomorrow, I can get the Last > Call sent out, which means (assuming the LC goes well) I can get it on th= e > IESG telechat Feb 7. If we have to wait two additional weeks until the Fe= b > 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to > the Last Call by EOB tomorrow for me to sneak it on to the earlier telech= at. > > pr > > On 1/23/13 4:04 PM, Anthony Mancuso wrote: **** > > Good suggestion Gabor. I will wait another day or so and then start on > generating a new version in response to the comments and clarifications.*= * > ** > > ** ** > > On Wed, Jan 23, 2013 at 1:55 PM, wrote:**** > > My suggestion would be, if Tony has the time and willingness, then > generate a new version and try to address these comments, perhaps taking > the clarifications from Peter (and any input from others if available unt= il > tomorrow) into consideration. **** > > Thanks, Gabor**** > > ** ** > > > > **** > > -- **** > > Pete Resnick **** > > Qualcomm Technologies, Inc. - +1 (858)651-4478**** > > _______________________________________________ **** > > > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws**** > > ** ** > > ** ** > > > > **** > > -- **** > > Pete Resnick **** > > Qualcomm Technologies, Inc. - +1 (858)651-4478**** > > --f46d043d677172d26904d420942c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    ________
    Mancuso: Same response re masters as above. Made th= e suggested wording changes re "locale" and "competing."= ;
    _____

    5.1, item 1: Is this referring t= o the Internet connectivity between the WS device and the database? If so, = as above, does it necessarily need to be an air interface?
    ___
    Mancuso: This wasn't meant to imply air the exclusiv= e interface -- Made this clearer by using "any" air interface use= d by devices; further limited reference to messages betweein devices and db= as messages from master device to db (since, by definition, slave devices = don't communicate directly to db).
    _____

    5.1, item 3: Again I suggest changing &= quot;operate in any country" to "operate in any locale" and = change "country-specific" to "locale-specific". (The ot= her occurrence of "country" seems correct.)
    ____
    Mancuso: Made suggested wording changes.
    ____= _

    5.2: Instead of "regulatory-domain", w= ouldn't either "locale" or simply "domain" be suffi= cient?
    _____
    Stanforth: The regulatory domain is assumed to be simi= lar to a country domain but need not be. A database could be permitted to s= erve =A0a different definition. In the FCC case they currently limit the do= main to the 12mile nautical limit and, as we speak databases are only permi= tted to service the NE USA.
    _____
    Resnick: I don't think you answered my question.
    _____
    Mancuso: I changed to "domain specific".= Not that the db may not be locale-based (a South American country may opt = for FCC domain rules).
    _____

    5.1 and 5.2: I don't understand the= distinction between "Normative" and "Non-normative" re= quirements in this context. Isn't it sufficient that you've separat= ely labeled "Data Model Requirements", "Protocol Requirement= s", and "Operational Requirements"?
    _____
    Mancuso: Agreed. Changed the heads and organization.

    Requirements:
    _____
    P.1: "= The master device may validate the database against a list of approved data= bases maintained by a regulatory body." I don't understand that as= a protocol requirement. What is being required?
    ___
    Mancuso: (Moved info up from Operation requirements per = later comment). Rephrased to clarify that the master device MUST identify a= db, and MAY discover or be pre-configured with db URIs, and MAY validate d= b URIs against a list of approved databases maintained by a regulatory body= ."

    P.5 and P.6: The requirement here is for *message-level= * integrity and encryption? That's OK, but I want to make sure that'= ;s what you mean.
    ___
    Rex Buddenberg: encryption gets y= ou confidentiality (which may or may not be a
    requirement). =A0It does not get you authenticity.

    integrity gets you bit-perfection. =A0Which is a requirement. =A0But<= /div>
    integrity does not get you authenticity ... which is a requiremen= t. I
    can't think of a situation where you don't need both. =A0(In p= ublic key, a
    digital signature provides both authenticity and int= egrity, assuming you
    have a PKI you can rely on.
    ____
    Mancuso: Yes, that is the intent, and yes, we want all three. DB authe= nticity is addressed in p4.
    ___
    P.8 and P.14: I don'= ;t think "result codes" and "response codes" are the re= quirement here, are they? It sounds like the requirement is "indicatio= n of success or failure".
    _____
    Mancuso: Rephrased to state the requirement in terms o= f the success or failure of the requests.
    _____

    P.15: I'm not clear on what this requirement means in practical= terms. Some more explanation seems in order.
    ___
    Mancuso: Rephrased for clarity to: "The protocol MU= ST support the capability for the database to inform master devices of chan= ges to spectrum availability information in a timely manner."

    P.16: Shouldn't this be combined with P.9?
    ___
    Mancuso: Deleted P.16; this was already included under D.9.=
    _____

    O.2: The "required accuracy&= quot; is ambiguous. Do you mean, "accuracy required by the database&qu= ot;?
    _____
    Stanforth: Acceptable Location Accuracy is defined by = the regulator and applied to the calculations of the database
    ___= __
    Resnick: So the database will tell the device what level of ac= curacy is required?
    _____
    Mancuso: Clarified as follows: "Locations MUST be= determined to the accuracy required by the applicable regualtory domain.&q= uot; These are operational requirements, and not part of the protocol. Accu= racy is verified by certification of devices by regulators.=A0
    ____

    O.3: This seems to indicate that databas= e discovery will be out of band, that the WG is not developing protocol to = do so. Is that what you meant? If not, this should be turned into a protoco= l requirement instead of an operational requirement.=A0
    __

    Mancuso: The master locating the DB is a r= equirement, so I moved this to P.1. Renumbered the remaining requirements (= and comments below).
    ____

    O.3: This requ= irement seems a bit overly obvious and silly to state as a requirement. Why= is it necessary to say that you need a connection?
    ____

    Mancuso: Deleted the first sentence.

    O.4: Again, "regulatory body" seems unneces= sary here. Substituting "database" seems sufficient, since you= 9;ll be getting the rule set from the database.
    _____
    Stanforth: General observation about this and the next= couple of comments. The FCC Certifies a radio and a database as a "sy= stem" Ofcom is not considering a system. Other regulators may have oth= er thoughts. In the case of the FCC some of the function is validated/certi= fied, what ever you want to call it for the combination not as a function o= f one or the other.
    So while it seems logical to have an implementation within a database = it is not necessarily considered as such.
    _____
    Resnick= : Again, I'm not understand your reply. Can you expand on what you mean= here?
    _____
    Mancuso: The statment here is regarding the rule set, = which is from the regulator, so the current phrasing seems OK. Note there a= re a significant number of device-only rule-set requirements (complexity is= to be expected), so the operational requirement here is for the master to = obtain "information." The current expectation is that the db may = communicate the name of the applicable regulatory ruleset to the device, bu= t not the specific parameters.
    _____

    O.5 (and O.9 through O.10 and O.12 thro= ugh O.14): As above, you can change "local regul8atory policy" to= "the database rule set", "determined by regulator policy&qu= ot; can be "enumerated in the database rule set", etc.
    ____
    Mancuso: A db can serve multiple regulatory domains, an= d hence, rulesets. And note that the currently applicaple rule set may not = come from a local regulatory domain, but be imported from a foreign regulat= or (e.g., Brazil decides to use FCC rules)
    _____

    Security Considerations

    <= /div>
    Section 8, generally: Same issue with "regulatory". See= if there are any that are more accurately "database rules".
    ____
    Mancuso: Again, multiple rule sets may apply for a give= n regulatory domain.

    Threat 7: This doesn't st= rike me as a security consideration per se. This might make more sense inco= rporated into an operational requirement.
    ___
    Mancuso: Agreed. Moved duscussion of emergency services = need for white space to new O.17 requirement, and condensed it to: "In= the case of a natural disaster,emergency services may need to use distribu= ted white space databases on short notice. The database should support any = emergency regulations adopted by regulators to provide priority allocation = of white space spectrum to emergency services."

    ---
    end of comments

    =



    On Fri, Jan 25, 2013 at 9:51 AM, Anthony M= ancuso <amancuso@google.com> wrote:
    I just posted version = 11 of the PAWS Use Case & Requirements draft to IETF. In this draft, I = responded to several of the comments posted to the list; I left a few TODOs= , and am awaiting further comments for the next draft.

    My notes are in preparing this version are set ou= t below.

    Tony Mancuso

    ****= ***********
    Tony Mancuso Notes - PAWS Use Case & Requirements= Notes v. 11 (I consolidated Pete Resnick's initial comments with other= comments received on selected points together with my responses)

    Abstract: End of the first paragraph, perhaps add: &quo= t;The IETF has undertaken to develop a protocol for that management databas= e."
    ___
    Mancuso: Done
    _____

    Also add the above to 1.1.

    1.2.1: A= re 2 & 3 combinable? "Connect to and optionally register with the = database using a well-defined protocol."
    _____
    Mancuso: Done:
    _____

    2= .2: For "Device ID", it says, "that identifies the manufactu= rer, model number, and serial number." Does the device ID have to iden= tify that information? Can it simply be unique?
    ____
    Stanforth: Regulators are asking for manufacturer= and model number as they may require action, enforcement or denial by the = DB on the set to manufacturer devices or a specific model of device
    _____
    Resnick: I guess the question is: Are there any potential i= mplementers of this protocol (or potential regulatory bodies) that *don'= ;t* care about manufacturer or model or etc.?
    _____
    Mancuso: Waiting for further comment.
    _____
    "Device Class" is only used once in section 5.1. No need f= or the definition here.

    "Location Based Servi= ce" is only used once in section 3. No need for the definition here.

    "Protected Entity" is only used once in secti= on 4.1. No need for the definition here.

    "Pro= tected Contour" is never used. No need for the definition at all.

    "Radio Access Technology" is only used once i= n section 5.1. No need for the definition here.
    _____
    =
    Nancy Bravin: I think since we are dealing with a protocol that can be= used globally, terms such as listed below, with definition, will make it e= asier to those countries who are not English speaking, or the translation t= o words, with no definition can be confusing. It is not a deal breaker, but= consideration for emerging countries that lack experience in these areas.<= /div>
    _____
    Resnick: Sorry, I think I wasn't clear enough. Oth= er than "Protected Contour" (which is not used anywhere), I was n= ot suggesting having *no* definition of the terms listed. I was just saying= that if they only occur once in the document, define them inline where the= y are used instead of in the definitions section. But that's strictly a= n editorial comment. Entirely up to you all whether you want to make a chan= ge.
    _____
    Mancuso: Deleted Protected Contour, and moved the defi= nition of single-use terms into the text.
    _____

    3.1 This section (and its subsections) seems od= dly placed. It is not use cases, but general protocol services that cut acr= oss use cases. Perhaps 3.1 and 3.2 should be separate top-level sections?
    ---
    Mancuso: Done. Moved Protocol Services to new top-= level head (Section 3); Use Cases now in new Section 4.
    _____

    3.1 "A complete protocol solut= ion must enable all potential white space services." That seems a bit = absolute. How about "must enable many different potential white space = services"?
    ____
    Mancuso: Done.
    _____

    3.1.1 & 3.1.2: Throughout this section, there&= #39;s no need to use the term "master". These services exist whet= her a device is acting as a master for other devices or whether it is actin= g on its own. Given that there's been no discussion of slave devices ye= t (that happens in 3.2), I found the use of the term "master" con= fusing in these sections. (I suppose you could expand the definition of mas= ter in 2.2 to explain that it could refer to a device acting on its own wit= h no slaves, but I still think that might be confusing.
    _____
    Stanforth: Broadcast use case is a master with n= o slave, at least in the context of a slave that communicates with or is co= ntrolled by a master.
    _____
    Resnick: So are you saying = we do or do not need the term "master" in these sections?
    _____
    Mancuso: I clarified the definition of master device: = "A device that queries a database, on its own behalf and/or on behalf = of a slave device, to obtain available spectrum information.". I think= this definition plus the definition of a slave device ("A device that= queries the database through a Master Device.") makes the use of the = term in the section appropriate -- namely, a master device is one that cont= acts a database to obtain spectrum (for itself or other devices). Slave dev= ices under these definitions, do not contact the db directly, omitting them= from the discussion at this point makes sense. Another way of saying it: w= e use the term master only as a way of describing a device used to query th= e db directly for spectrum availability. Denoting a device as master does n= ot necessarily imply the use of slaves (devices that are not used to query = the db directly) in a particular use case.
    _______________

    3.1.1, item= 2: This says that the device will discover the database "in the local= regulatory domain". How does the device determine the "local reg= ulatory domain"? I suspect that the phrase "in the local regulato= ry domain" is meaningless for purposes of this sentence. If it is not,= there's something that's not explained.
    _____
    Stanforth: The location of a device determines i= t regulatory domain. However the device may understand this or it may be to= ld.=A0
    _____
    Resnick: Right. That seems to indicate tha= t the device that this section should say, "for its current location&q= uot; and not "in the local regulatory domain". The device needs t= o know its location, but not its regulatory domain.
    _____
    Stanforth: For instance our current US implementation = validates that a device is within the regulatory domain. If not we deny it = service but allowed for the DB to tell the device who or what it should con= tact. In other words you are now in Canada so you need to talk to xxx not t= o and FCC DB. Taken together with the comment below this may need some thou= ght and additional work.
    _____
    Resnick: I think we're on the same page.
    _____
    Mancuso: The intent of the existing wording is simply that= the master sends out a request and waits for a response, not to imply that= it the device query is constrained or qualified by the device's unders= tanding of its regulatory domain. I deleted the extra language to read as f= ollows: "The master device constructs and sends a service request over= the Internet."
    _______
    3.1.2: Similar questions regarding= regulatory domains. For example, "2. =A0To register with the database= , the master device sends the database the registration information require= d under regulatory rules." How does the device determine which regulat= ory rules it is under and therefore which information to send to the databa= se. If the answer is, "It queries the database", then it is not t= he regulatory rules the device cares about; it is the information the datab= ase is configured to ask for (which will presumably be in accordance to som= e regulations, but are out of band of any protocol work). If the answer is,= "It is pre-configured in the device", then the regulatory rules = are again out of band. Either way, mention of them would be unnecessary.
    ___
    Mancuso: Agreed. Again, I think this was simply a = matter of misphrasing. Deleted the extra language to read: "To registe= r with the database, the master device sends registration information to th= e database."
    _____

    3.2.1, 3.2.2, and 3.2= .3, in general: When "slave device" is defined in 2.2, it's o= nly a slave for purposes of talking to the database. But there is an implic= ation in these sections that the slave device uses the master for internet = connectivity. I don't think that's the intent, but either way there= 's some clarification that's needed. Further confusing me about thi= s point is (a) the master device is always the one in the diagrams with the= antenna, but as far as I can tell, a master device doesn't need an ant= enna, the slaves do; and (b) most of the links marked "Air" seem = to me not to require an air interface, but could also be wired. I could use= some explanation.
    _____
    Stanforth
    The FCC, a= s an example, has two concepts of a slave. The first is a client served by = a master, think 802.11 client using a channel served by an AP. This is the = model for low power devices.=A0
    _____
    Resnick: OK, but does the low power device actua= lly ever request white space spectrum? If not, then it is not involved in t= his protocol, right?
    ___
    Stanforth: If the device is a = high power device the slave must get it's own channel list. It can use = a master to do this, using white space spectrum, if it has no other means o= f contacting the database.
    ____
    Resnick: This I understood until you said "using w= hite space spectrum". It can't use white space spectrum to talk to= the master until it is allocated spectrum by the database, can it? It talk= s to the master *not* using white space spectrum, gets it's answer thro= ugh the master about which spectrum to use, and then stops talking to the m= aster, correct?
    ____
    Mancuso: Waiting for any further input.
    _____= =A0

    3.2.1, item 7: Does the slav= e provide its location, device identifier, and antenna height, the same way= the master does when it queries? If so (especially in the case of the mast= er sub-allocating for the slaves), doesn't the master have to provide t= he set of locations for all of the slaves in step 5? Some further explanati= on might be in order.
    _____
    Stanforth: As above a low power slave, under FCC= rule, does not have to provide any of this information but a high power sl= ave does.
    _____
    Resnick: Does a low power slave talk to= the database at all?
    _____
    Mancuso: Waiting for any further input.
    ____= __
    3.2.1, item 8: It says that the white space = is allocated to slaves "for communication over the network". That= 's not right is it? In this scenario, the allocated white space could b= e used for network (I read "Internet") communication *or anything= else*, can't it?
    _____
    Stanforth: High power again. A slave may not get= the same channel list as the master and may not be able to use the channel= the master is currently using so a negotiation will be necessary.
    _____
    Resnick: I'm not sure whether you agree or disagree wit= h my point here. I don't understand your reply.
    _____
    Mancuso: Waiting for any further input.
    _____

    3.2.1, item 9: Is this an important part of the scenario? Why wo= uldn't it be perfectly reasonable for communication between the master = and slaves continue on its original connection and that the white space is = only used for other communications the slave wishes to do?
    _____
    Stanforth: same as Iten 8, above.
    ____=
    Mancuso: TODO.
    _____

    <= /div>
    3.2.2: This scenario was confusing to me because the master seems= completely unnecessary to the example. Please explain.
    _____
    Mancuso: TODO. The master is optionally used by = the slave to query the db for spectrum. And again, master only connotes abi= lity to query the db directly by the device. I do think we need to eliminat= e the implication that the slave then connects to the Internet through the = master (it uses white space spectrum, right)?
    _____

    3.2.4 and 3.2.5: Anot= her example of the term "master" seems unnecessary in the example= , since there are no slaves.
    ____
    Mancuso: Again,= master only connotes ability to query the db directly by the device.
    ____
    4: "Master" seems unnecessa= ry to the example. Also, I suggest in the second-to-last paragraph, you say= "The databases are locale specific" instead of "country spe= cific", and delete the word "competing" from the last senten= ce of that paragraph.
    ________
    Mancuso: Same response re masters as above. M= ade the suggested wording changes re "locale" and "competing= ."
    _____

    4.1, ite= m 1: Is this referring to the Internet connectivity between the WS device a= nd the database? If so, as above, does it necessarily need to be an air int= erface?
    ___
    Mancuso: TODO
    _____

    4.1, item 3: Again I suggest changing "operate = in any country" to "operate in any locale" and change "= country-specific" to "locale-specific". (The other occurrenc= e of "country" seems correct.)
    ____
    Mancuso: Made suggested wording changes.
    _____

    4.2: Instead of "re= gulatory-domain", wouldn't either "locale" or simply &qu= ot;domain" be sufficient?
    _____
    Stanforth: The regulatory domain is assumed to b= e similar to a country domain but need not be. A database could be permitte= d to serve =A0a different definition. In the FCC case they currently limit = the domain to the 12mile nautical limit and, as we speak databases are only= permitted to service the NE USA.
    _____
    Resnick: I don't think you answered my question.
    _____
    Mancuso: I changed to "domain specific".= Not that the db may not be locale-based (a South American country may opt = for FCC domain rules).
    _____

    5.1 and 5.2: I don= 9;t understand the distinction between "Normative" and "Non-= normative" requirements in this context. Isn't it sufficient that = you've separately labeled "Data Model Requirements", "Pr= otocol Requirements", and "Operational Requirements"?
    _____
    Mancuso: Agreed. Changed the heads and organizat= ion.
    _____
    Mancuso: Remaining items TODO.
    ___= __
    P.1: "The master device may validate th= e database against a list of approved databases maintained by a regulatory = body." I don't understand that as a protocol requirement. What is = being required?

    P.5 and P.6: The requirement here is for *message-level= * integrity and encryption? That's OK, but I want to make sure that'= ;s what you mean.

    P.8 and P.14: I don't think = "result codes" and "response codes" are the requirement= here, are they? It sounds like the requirement is "indication of succ= ess or failure".

    P.15: I'm not clear on what this requirement means = in practical terms. Some more explanation seems in order.

    P.16: Shouldn't this be combined with P.9?

    O.2: The "required accuracy" is ambiguous. Do you mean, &quo= t;accuracy required by the database"?
    _____
    = Stanforth: Acceptable Location Accuracy is defined by the regulator and app= lied to the calculations of the database
    _____
    Resnick: So the database will tell the device what lev= el of accuracy is required?
    _____
    O.3: This seems to indicate that database discovery will be out= of band, that the WG is not developing protocol to do so. Is that what you= meant? If not, this should be turned into a protocol requirement instead o= f an operational requirement.

    O.4: This requirement seems a bit overly obvious and si= lly to state as a requirement. Why is it necessary to say that you need a c= onnection?

    O.5: Again, "regulatory body"= seems unnecessary here. Substituting "database" seems sufficient= , since you'll be getting the rule set from the database.
    _____
    Stanforth: General observation about this and th= e next couple of comments. The FCC Certifies a radio and a database as a &q= uot;system" Ofcom is not considering a system. Other regulators may ha= ve other thoughts. In the case of the FCC some of the function is validated= /certified, what ever you want to call it for the combination not as a func= tion of one or the other.
    So while it seems logical to have an implementation within a database = it is not necessarily considered as such.
    _____
    R= esnick: Again, I'm not understand your reply. Can you expand on what yo= u mean here?
    _____

    O.6 (and O.9 through = O.11 and O.13 through O.15): As above, you can change "local regulator= y policy" to "the database rule set", "determined by re= gulator policy" can be "enumerated in the database rule set"= , etc.

    Section 7, generally: Same issue with "regulatory&= quot;. See if there are any that are more accurately "database rules&q= uot;.

    Threat 7: This doesn't strike me as a se= curity consideration per se. This might make more sense incorporated into a= n operational requirement.




    On Thu, Jan 24, 2013 at 3:19 PM, <Gabor.Bajko@nokia.com>= wrote:

    Will wait for Tony to gen= erate a new version by addressing the received comments, before issuing the= Last Call.

    =A0<= /p>

    -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor<= /span>

    =A0<= /p>

    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Pete Resnick
    Sent: Wednesday, January 23, 2013 2:59 PM
    To: Anthony Mancuso


    Cc: paws@ietf.org=
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

    =A0

    Like I said, I'll await word from Brian and Gabo= r tomorrow for "go" or "no go" with the Last Call, even= if there is no new draft ready to go. We can Last Call -10 if nobody think= s there's a strong reason to wait. I am fine with either path.



    pr

    On 1/23/13 4:54 PM, Anthony Mancuso wrote:

    I',m not sure I can turn around the doc by tomor= row since there are some technical points I need to collaborate on.<= u>

    =A0

    On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <Brian.Rosen@neus= tar.biz> wrote:

    I think if Tony can spin a rev before EOB tomorrow, = we should do that, but I'm thinking that the current rev is good enough= , and I'd prefer to get it into the Feb 7 telechat. =A0

    =A0

    I don't feel very strongly about that, but=85=

    =A0

    Brian

    =A0

    On Jan 23, 2013, at 5:10 PM, Pete Resnick <presnick@qti.qualc= omm.com> wrote:

    =A0

    One hitch: If you make the call by EOB tomorrow, I c= an get the Last Call sent out, which means (assuming the LC goes well) I ca= n get it on the IESG telechat Feb 7. If we have to wait two additional week= s until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to= the Last Call by EOB tomorrow for me to sneak it on to the earlier telecha= t.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:

    Good suggestion Gabor. I will wait another day or so= and then start on generating a new version in response to the comments and= clarifications.

    =A0

    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> w= rote:

    My suggestion would be, i= f Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (a= nd any input from others if available until tomorrow) into consideration.

    Thanks, Gabor

    =A0



    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>

    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________ <= /u>

    =A0

    =A0



    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478


    --20cf307c9deee050dd04d47592e4-- From Gabor.Bajko@nokia.com Wed Jan 30 10:30:50 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515D21F8881 for ; Wed, 30 Jan 2013 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 3YO7aCNNvmJK for ; Wed, 30 Jan 2013 10:30:30 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id BB13721F886C for ; Wed, 30 Jan 2013 10:30:29 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r0UIUOh3019834; Wed, 30 Jan 2013 20:30:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jan 2013 20:30:23 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.194]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 18:30:23 +0000 From: To: Thread-Topic: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thread-Index: AQHN+ygZEM/lER+xCk+6M1VSx1yP55hg9tOAgAFB0BA= Date: Wed, 30 Jan 2013 18:30:23 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47602116D38@008-AM1MPN1-006.mgdnok.nokia.com> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47602116D38008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jan 2013 18:30:23.0926 (UTC) FILETIME=[DE1B1560:01CDFF17] X-Nokia-AV: Clean Cc: paws@ietf.org, presnick@qti.qualcomm.com Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 30 Jan 2013 18:30:50 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602116D38008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Tony. Pete, this version I think is ready for Last Call. - Gabor From: ext Anthony Mancuso [mailto:amancuso@google.com] Sent: Tuesday, January 29, 2013 3:16 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: Pete Resnick; paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmt= s-10 To PAWS list: Here are the collected comments on version 10 (the last posted version) of = the PAWS Use Case & Requirements draft and my responses (what I did and did= n't do) for version 12, which I just posted to IETF. Thanks for all the feedback! Tony Mancuso Abstract End of the first paragraph, perhaps add: "The IETF has undertaken to develo= p a protocol for that management database." ___ Mancuso: Done _____ Introduction Also added reference to the PAWS protocol to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the d= atabase using a well-defined protocol." _____ Mancuso: Done: _____ Conventions and Terminology 2.2: For "Device ID", it says, "that identifies the manufacturer, model num= ber, and serial number." Does the device ID have to identify that informati= on? Can it simply be unique? ____ Stanforth: Regulators are asking for manufacturer and model number as they = may require action, enforcement or denial by the DB on the set to manufactu= rer devices or a specific model of device _____ Resnick: I guess the question is: Are there any potential implementers of t= his protocol (or potential regulatory bodies) that *don't* care about manuf= acturer or model or etc.? _____ Mancuso: Simplified to: "An identifier for each master device." _________ "Device Class" is only used once in section 5.1. No need for the definition= here. "Location Based Service" is only used once in section 3. No need for the de= finition here. "Protected Entity" is only used once in section 4.1. No need for the defini= tion here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the= definition here. _____ Nancy Bravin: I think since we are dealing with a protocol that can be used= globally, terms such as listed below, with definition, will make it easier= to those countries who are not English speaking, or the translation to wor= ds, with no definition can be confusing. It is not a deal breaker, but cons= ideration for emerging countries that lack experience in these areas. _____ Resnick: Sorry, I think I wasn't clear enough. Other than "Protected Contou= r" (which is not used anywhere), I was not suggesting having *no* definitio= n of the terms listed. I was just saying that if they only occur once in th= e document, define them inline where they are used instead of in the defini= tions section. But that's strictly an editorial comment. Entirely up to you= all whether you want to make a change. _____ Mancuso: Deleted Protected Contour, and moved the definition of single-use = terms into the text. _____ Protocol Services (separated out Protocol Services from Use Cases per comme= nt below. (I renumbered the comments below to correspond to the new organiz= ation). 3. This section (and its subsections) seems oddly placed. It is not use cas= es, but general protocol services that cut across use cases. Perhaps 3.1 an= d 3.2 should be separate top-level sections? --- Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); U= se Cases now in new Section 4. _____ 3. "A complete protocol solution must enable all potential white space serv= ices." That seems a bit absolute. How about "must enable many different pot= ential white space services"? ____ Benjamin Rolfe: I'd strike the entire sentence. There is no such thing as a= "complete protocol". If you must have it, change it to "this protocol" a= nd it isn't wrong (but still not adding information). Mancuso: Rephrased to: "A protocol solution must enable many different pote= ntial white space services. ". _____ 3.1 & 3.2: Throughout this section, there's no need to use the term "master= ". These services exist whether a device is acting as a master for other de= vices or whether it is acting on its own. Given that there's been no discus= sion of slave devices yet (that happens in 3.2), I found the use of the ter= m "master" confusing in these sections. (I suppose you could expand the def= inition of master in 2.2 to explain that it could refer to a device acting = on its own with no slaves, but I still think that might be confusing. _____ Stanforth: Broadcast use case is a master with no slave, at least in the co= ntext of a slave that communicates with or is controlled by a master. _____ Resnick: So are you saying we do or do not need the term "master" in these = sections? _____ Mancuso: I clarified the definition of master device: "A device that querie= s a database, on its own behalf and/or on behalf of a slave device, to obta= in available spectrum information.". I think this definition plus the defin= ition of a slave device ("A device that queries the database through a Mast= er Device.") makes the use of the term in this and latter sections and illu= strations appropriate -- namely, a master device is one that contacts a dat= abase to obtain spectrum (for itself or other devices). Slave devices under= these definitions, do not contact the db directly, omitting them from the = discussion and refering in the text or illustrations solely to a master dev= ice makes sense, and is not dependent on also referencing a slave device. A= nother way of saying it: we use the term master only as a way of describing= a device used to query the db directly for spectrum availability. Denoting= a device as master does not necessarily imply the use of slaves (devices t= hat are not used to query the db directly) in a particular use case or illu= stration. _______________ 3.1, item 2: This says that the device will discover the database "in the l= ocal regulatory domain". How does the device determine the "local regulator= y domain"? I suspect that the phrase "in the local regulatory domain" is me= aningless for purposes of this sentence. If it is not, there's something th= at's not explained. _____ Stanforth: The location of a device determines it regulatory domain. Howeve= r the device may understand this or it may be told. _____ Resnick: Right. That seems to indicate that the device that this section sh= ould say, "for its current location" and not "in the local regulatory domai= n". The device needs to know its location, but not its regulatory domain. _____ Stanforth: For instance our current US implementation validates that a devi= ce is within the regulatory domain. If not we deny it service but allowed f= or the DB to tell the device who or what it should contact. In other words = you are now in Canada so you need to talk to xxx not to and FCC DB. Taken t= ogether with the comment below this may need some thought and additional wo= rk. _____ Resnick: I think we're on the same page. _____ Mancuso: Rewrote to clarify the difference between the discovery phase (loc= ating a trusted database) and the initial contact with the trusted database= . Also noted the different ways a device can locate the database URI (throu= gh discovery or pre-configured URIs). _______ 3.2: Similar questions regarding regulatory domains. For example, "2. To r= egister with the database, the master device sends the database the registr= ation information required under regulatory rules." How does the device det= ermine which regulatory rules it is under and therefore which information t= o send to the database. If the answer is, "It queries the database", then i= t is not the regulatory rules the device cares about; it is the information= the database is configured to ask for (which will presumably be in accorda= nce to some regulations, but are out of band of any protocol work). If the = answer is, "It is pre-configured in the device", then the regulatory rules = are again out of band. Either way, mention of them would be unnecessary. ___ Mancuso: Agreed. I think this was simply a matter of misphrasing. Deleted t= he extra language to read: "To register with the database, the master devic= e sends registration information to the database." _____ Use Cases 4.1, 4.2, and 4.3, in general: When "slave device" is defined in 2.2, it's = only a slave for purposes of talking to the database. But there is an impli= cation in these sections that the slave device uses the master for internet= connectivity. I don't think that's the intent, but either way there's some= clarification that's needed. Further confusing me about this point is (a) = the master device is always the one in the diagrams with the antenna, but a= s far as I can tell, a master device doesn't need an antenna, the slaves do= ; and (b) most of the links marked "Air" seem to me not to require an air i= nterface, but could also be wired. I could use some explanation. _____ Stanforth The FCC, as an example, has two concepts of a slave. The first is a client = served by a master, think 802.11 client using a channel served by an AP. Th= is is the model for low power devices. _____ Resnick: OK, but does the low power device actually ever request white spac= e spectrum? If not, then it is not involved in this protocol, right? ___ Stanforth: If the device is a high power device the slave must get it's own= channel list. It can use a master to do this, using white space spectrum, = if it has no other means of contacting the database. ____ Resnick: This I understood until you said "using white space spectrum". It = can't use white space spectrum to talk to the master until it is allocated = spectrum by the database, can it? It talks to the master *not* using white = space spectrum, gets it's answer through the master about which spectrum to= use, and then stops talking to the master, correct? ____ Mancuso: Masters are defined as the device that can contact the db on its o= wn (knows its geolocation), and the use cases I think are consistent with t= his definition. There is no constraint on how the slaves or masters communi= cate (air or wire) but the illustrations attempt to show common connections= for the examples (for hotspots, WANS, etc., slave devices will connect ove= r air to master). Also, slaves can use white space spectrum as appropriate = to the local white space network being established -- to connect to the Int= ernet through the master (or some other AP), for local communications only,= or some other use of the spectrum. I deleted the extra master antenna show= n in use case 5 (local tv broadcast). 4.1, item 7: Does the slave provide its location, device identifier, and an= tenna height, the same way the master does when it queries? If so (especial= ly in the case of the master sub-allocating for the slaves), doesn't the ma= ster have to provide the set of locations for all of the slaves in step 5? = Some further explanation might be in order. _____ Stanforth: As above a low power slave, under FCC rule, does not have to pro= vide any of this information but a high power slave does. _____ Resnick: Does a low power slave talk to the database at all? _____ Mancuso: I moved related slave requests into the corresponding sections for= the master. ______ 4.1, item 8: It says that the white space is allocated to slaves "for commu= nication over the network". That's not right is it? In this scenario, the a= llocated white space could be used for network (I read "Internet") communic= ation *or anything else*, can't it? _____ Stanforth: High power again. A slave may not get the same channel list as t= he master and may not be able to use the channel the master is currently us= ing so a negotiation will be necessary. _____ Resnick: I'm not sure whether you agree or disagree with my point here. I d= on't understand your reply. _____ Mancuso: The network refers to the local master-slave network, not to conne= ctivity to the Internet. I deleted "for communication over the network" for= clarity. _____ 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it b= e perfectly reasonable for communication between the master and slaves cont= inue on its original connection and that the white space is only used for o= ther communications the slave wishes to do? _____ Stanforth: same as Iten 8, above. ____ Mancuso: Changed to "may occur". Technically, the "network" we are talking = about here is the white space network, which only uses white space (after i= nitial bootstrapping communications between slaves and masters). But I agre= e that we should recognize (implicitly) the ability of devices to use other= spectrum/technologies for ongoing communications. _____ 4.2: This scenario was confusing to me because the master seems completely = unnecessary to the example. Please explain. _____ Mancuso: As noted, the master is optionally used by the slave to query the = db for spectrum. And again, master only connotes the device's ability to qu= ery the db directly. _____ 4.4 and 4.5: Another example of the term "master" seems unnecessary in the = example, since there are no slaves. ____ Mancuso: Again, master only connotes ability to query the db directly by th= e device. ____ Problem Statement 5: "Master" seems unnecessary to the example. Also, I suggest in the second= -to-last paragraph, you say "The databases are locale specific" instead of = "country specific", and delete the word "competing" from the last sentence = of that paragraph. ________ Mancuso: Same response re masters as above. Made the suggested wording chan= ges re "locale" and "competing." _____ 5.1, item 1: Is this referring to the Internet connectivity between the WS = device and the database? If so, as above, does it necessarily need to be an= air interface? ___ Mancuso: This wasn't meant to imply air the exclusive interface -- Made thi= s clearer by using "any" air interface used by devices; further limited ref= erence to messages betweein devices and db as messages from master device t= o db (since, by definition, slave devices don't communicate directly to db)= . _____ 5.1, item 3: Again I suggest changing "operate in any country" to "operate = in any locale" and change "country-specific" to "locale-specific". (The oth= er occurrence of "country" seems correct.) ____ Mancuso: Made suggested wording changes. _____ 5.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "do= main" be sufficient? _____ Stanforth: The regulatory domain is assumed to be similar to a country doma= in but need not be. A database could be permitted to serve a different def= inition. In the FCC case they currently limit the domain to the 12mile naut= ical limit and, as we speak databases are only permitted to service the NE = USA. _____ Resnick: I don't think you answered my question. _____ Mancuso: I changed to "domain specific". Not that the db may not be locale-= based (a South American country may opt for FCC domain rules). _____ 5.1 and 5.2: I don't understand the distinction between "Normative" and "No= n-normative" requirements in this context. Isn't it sufficient that you've = separately labeled "Data Model Requirements", "Protocol Requirements", and = "Operational Requirements"? _____ Mancuso: Agreed. Changed the heads and organization. Requirements: _____ P.1: "The master device may validate the database against a list of approve= d databases maintained by a regulatory body." I don't understand that as a = protocol requirement. What is being required? ___ Mancuso: (Moved info up from Operation requirements per later comment). Rep= hrased to clarify that the master device MUST identify a db, and MAY discov= er or be pre-configured with db URIs, and MAY validate db URIs against a li= st of approved databases maintained by a regulatory body." P.5 and P.6: The requirement here is for *message-level* integrity and encr= yption? That's OK, but I want to make sure that's what you mean. ___ Rex Buddenberg: encryption gets you confidentiality (which may or may not b= e a requirement). It does not get you authenticity. integrity gets you bit-perfection. Which is a requirement. But integrity does not get you authenticity ... which is a requirement. I can't think of a situation where you don't need both. (In public key, a digital signature provides both authenticity and integrity, assuming you have a PKI you can rely on. ____ Mancuso: Yes, that is the intent, and yes, we want all three. DB authentici= ty is addressed in p4. ___ P.8 and P.14: I don't think "result codes" and "response codes" are the req= uirement here, are they? It sounds like the requirement is "indication of s= uccess or failure". _____ Mancuso: Rephrased to state the requirement in terms of the success or fail= ure of the requests. _____ P.15: I'm not clear on what this requirement means in practical terms. Some= more explanation seems in order. ___ Mancuso: Rephrased for clarity to: "The protocol MUST support the capabilit= y for the database to inform master devices of changes to spectrum availabi= lity information in a timely manner." P.16: Shouldn't this be combined with P.9? ___ Mancuso: Deleted P.16; this was already included under D.9. _____ O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required = by the database"? _____ Stanforth: Acceptable Location Accuracy is defined by the regulator and app= lied to the calculations of the database _____ Resnick: So the database will tell the device what level of accuracy is req= uired? _____ Mancuso: Clarified as follows: "Locations MUST be determined to the accurac= y required by the applicable regualtory domain." These are operational requ= irements, and not part of the protocol. Accuracy is verified by certificati= on of devices by regulators. ____ O.3: This seems to indicate that database discovery will be out of band, th= at the WG is not developing protocol to do so. Is that what you meant? If n= ot, this should be turned into a protocol requirement instead of an operati= onal requirement. __ Mancuso: The master locating the DB is a requirement, so I moved this to P.= 1. Renumbered the remaining requirements (and comments below). ____ O.3: This requirement seems a bit overly obvious and silly to state as a re= quirement. Why is it necessary to say that you need a connection? ____ Mancuso: Deleted the first sentence. O.4: Again, "regulatory body" seems unnecessary here. Substituting "databas= e" seems sufficient, since you'll be getting the rule set from the database= . _____ Stanforth: General observation about this and the next couple of comments. = The FCC Certifies a radio and a database as a "system" Ofcom is not conside= ring a system. Other regulators may have other thoughts. In the case of the= FCC some of the function is validated/certified, what ever you want to cal= l it for the combination not as a function of one or the other. So while it seems logical to have an implementation within a database it is= not necessarily considered as such. _____ Resnick: Again, I'm not understand your reply. Can you expand on what you m= ean here? _____ Mancuso: The statment here is regarding the rule set, which is from the reg= ulator, so the current phrasing seems OK. Note there are a significant numb= er of device-only rule-set requirements (complexity is to be expected), so = the operational requirement here is for the master to obtain "information."= The current expectation is that the db may communicate the name of the app= licable regulatory ruleset to the device, but not the specific parameters. _____ O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can change = "local regul8atory policy" to "the database rule set", "determined by regul= ator policy" can be "enumerated in the database rule set", etc. ____ Mancuso: A db can serve multiple regulatory domains, and hence, rulesets. A= nd note that the currently applicaple rule set may not come from a local re= gulatory domain, but be imported from a foreign regulator (e.g., Brazil dec= ides to use FCC rules) _____ Security Considerations Section 8, generally: Same issue with "regulatory". See if there are any th= at are more accurately "database rules". ____ Mancuso: Again, multiple rule sets may apply for a given regulatory domain. Threat 7: This doesn't strike me as a security consideration per se. This m= ight make more sense incorporated into an operational requirement. ___ Mancuso: Agreed. Moved duscussion of emergency services need for white spac= e to new O.17 requirement, and condensed it to: "In the case of a natural d= isaster,emergency services may need to use distributed white space database= s on short notice. The database should support any emergency regulations ad= opted by regulators to provide priority allocation of white space spectrum = to emergency services." --- end of comments On Fri, Jan 25, 2013 at 9:51 AM, Anthony Mancuso > wrote: I just posted version 11 of the PAWS Use Case & Requirements draft to IETF.= In this draft, I responded to several of the comments posted to the list; = I left a few TODOs, and am awaiting further comments for the next draft. My notes are in preparing this version are set out below. Tony Mancuso *************** Tony Mancuso Notes - PAWS Use Case & Requirements Notes v. 11 (I consolidat= ed Pete Resnick's initial comments with other comments received on selected= points together with my responses) Abstract: End of the first paragraph, perhaps add: "The IETF has undertaken= to develop a protocol for that management database." ___ Mancuso: Done _____ Also add the above to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the d= atabase using a well-defined protocol." _____ Mancuso: Done: _____ 2.2: For "Device ID", it says, "that identifies the manufacturer, model num= ber, and serial number." Does the device ID have to identify that informati= on? Can it simply be unique? ____ Stanforth: Regulators are asking for manufacturer and model number as they = may require action, enforcement or denial by the DB on the set to manufactu= rer devices or a specific model of device _____ Resnick: I guess the question is: Are there any potential implementers of t= his protocol (or potential regulatory bodies) that *don't* care about manuf= acturer or model or etc.? _____ Mancuso: Waiting for further comment. _____ "Device Class" is only used once in section 5.1. No need for the definition= here. "Location Based Service" is only used once in section 3. No need for the de= finition here. "Protected Entity" is only used once in section 4.1. No need for the defini= tion here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the= definition here. _____ Nancy Bravin: I think since we are dealing with a protocol that can be used= globally, terms such as listed below, with definition, will make it easier= to those countries who are not English speaking, or the translation to wor= ds, with no definition can be confusing. It is not a deal breaker, but cons= ideration for emerging countries that lack experience in these areas. _____ Resnick: Sorry, I think I wasn't clear enough. Other than "Protected Contou= r" (which is not used anywhere), I was not suggesting having *no* definitio= n of the terms listed. I was just saying that if they only occur once in th= e document, define them inline where they are used instead of in the defini= tions section. But that's strictly an editorial comment. Entirely up to you= all whether you want to make a change. _____ Mancuso: Deleted Protected Contour, and moved the definition of single-use = terms into the text. _____ 3.1 This section (and its subsections) seems oddly placed. It is not use ca= ses, but general protocol services that cut across use cases. Perhaps 3.1 a= nd 3.2 should be separate top-level sections? --- Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); U= se Cases now in new Section 4. _____ 3.1 "A complete protocol solution must enable all potential white space ser= vices." That seems a bit absolute. How about "must enable many different po= tential white space services"? ____ Mancuso: Done. _____ 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term "ma= ster". These services exist whether a device is acting as a master for othe= r devices or whether it is acting on its own. Given that there's been no di= scussion of slave devices yet (that happens in 3.2), I found the use of the= term "master" confusing in these sections. (I suppose you could expand the= definition of master in 2.2 to explain that it could refer to a device act= ing on its own with no slaves, but I still think that might be confusing. _____ Stanforth: Broadcast use case is a master with no slave, at least in the co= ntext of a slave that communicates with or is controlled by a master. _____ Resnick: So are you saying we do or do not need the term "master" in these = sections? _____ Mancuso: I clarified the definition of master device: "A device that querie= s a database, on its own behalf and/or on behalf of a slave device, to obta= in available spectrum information.". I think this definition plus the defin= ition of a slave device ("A device that queries the database through a Mast= er Device.") makes the use of the term in the section appropriate -- namely= , a master device is one that contacts a database to obtain spectrum (for i= tself or other devices). Slave devices under these definitions, do not cont= act the db directly, omitting them from the discussion at this point makes = sense. Another way of saying it: we use the term master only as a way of de= scribing a device used to query the db directly for spectrum availability. = Denoting a device as master does not necessarily imply the use of slaves (d= evices that are not used to query the db directly) in a particular use case= . _______________ 3.1.1, item 2: This says that the device will discover the database "in the= local regulatory domain". How does the device determine the "local regulat= ory domain"? I suspect that the phrase "in the local regulatory domain" is = meaningless for purposes of this sentence. If it is not, there's something = that's not explained. _____ Stanforth: The location of a device determines it regulatory domain. Howeve= r the device may understand this or it may be told. _____ Resnick: Right. That seems to indicate that the device that this section sh= ould say, "for its current location" and not "in the local regulatory domai= n". The device needs to know its location, but not its regulatory domain. _____ Stanforth: For instance our current US implementation validates that a devi= ce is within the regulatory domain. If not we deny it service but allowed f= or the DB to tell the device who or what it should contact. In other words = you are now in Canada so you need to talk to xxx not to and FCC DB. Taken t= ogether with the comment below this may need some thought and additional wo= rk. _____ Resnick: I think we're on the same page. _____ Mancuso: The intent of the existing wording is simply that the master sends= out a request and waits for a response, not to imply that it the device qu= ery is constrained or qualified by the device's understanding of its regula= tory domain. I deleted the extra language to read as follows: "The master d= evice constructs and sends a service request over the Internet." _______ 3.1.2: Similar questions regarding regulatory domains. For example, "2. To= register with the database, the master device sends the database the regis= tration information required under regulatory rules." How does the device d= etermine which regulatory rules it is under and therefore which information= to send to the database. If the answer is, "It queries the database", then= it is not the regulatory rules the device cares about; it is the informati= on the database is configured to ask for (which will presumably be in accor= dance to some regulations, but are out of band of any protocol work). If th= e answer is, "It is pre-configured in the device", then the regulatory rule= s are again out of band. Either way, mention of them would be unnecessary. ___ Mancuso: Agreed. Again, I think this was simply a matter of misphrasing. De= leted the extra language to read: "To register with the database, the maste= r device sends registration information to the database." _____ 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in 2.2,= it's only a slave for purposes of talking to the database. But there is an= implication in these sections that the slave device uses the master for in= ternet connectivity. I don't think that's the intent, but either way there'= s some clarification that's needed. Further confusing me about this point i= s (a) the master device is always the one in the diagrams with the antenna,= but as far as I can tell, a master device doesn't need an antenna, the sla= ves do; and (b) most of the links marked "Air" seem to me not to require an= air interface, but could also be wired. I could use some explanation. _____ Stanforth The FCC, as an example, has two concepts of a slave. The first is a client = served by a master, think 802.11 client using a channel served by an AP. Th= is is the model for low power devices. _____ Resnick: OK, but does the low power device actually ever request white spac= e spectrum? If not, then it is not involved in this protocol, right? ___ Stanforth: If the device is a high power device the slave must get it's own= channel list. It can use a master to do this, using white space spectrum, = if it has no other means of contacting the database. ____ Resnick: This I understood until you said "using white space spectrum". It = can't use white space spectrum to talk to the master until it is allocated = spectrum by the database, can it? It talks to the master *not* using white = space spectrum, gets it's answer through the master about which spectrum to= use, and then stops talking to the master, correct? ____ Mancuso: Waiting for any further input. _____ 3.2.1, item 7: Does the slave provide its location, device identifier, and = antenna height, the same way the master does when it queries? If so (especi= ally in the case of the master sub-allocating for the slaves), doesn't the = master have to provide the set of locations for all of the slaves in step 5= ? Some further explanation might be in order. _____ Stanforth: As above a low power slave, under FCC rule, does not have to pro= vide any of this information but a high power slave does. _____ Resnick: Does a low power slave talk to the database at all? _____ Mancuso: Waiting for any further input. ______ 3.2.1, item 8: It says that the white space is allocated to slaves "for com= munication over the network". That's not right is it? In this scenario, the= allocated white space could be used for network (I read "Internet") commun= ication *or anything else*, can't it? _____ Stanforth: High power again. A slave may not get the same channel list as t= he master and may not be able to use the channel the master is currently us= ing so a negotiation will be necessary. _____ Resnick: I'm not sure whether you agree or disagree with my point here. I d= on't understand your reply. _____ Mancuso: Waiting for any further input. _____ 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it b= e perfectly reasonable for communication between the master and slaves cont= inue on its original connection and that the white space is only used for o= ther communications the slave wishes to do? _____ Stanforth: same as Iten 8, above. ____ Mancuso: TODO. _____ 3.2.2: This scenario was confusing to me because the master seems completel= y unnecessary to the example. Please explain. _____ Mancuso: TODO. The master is optionally used by the slave to query the db f= or spectrum. And again, master only connotes ability to query the db direct= ly by the device. I do think we need to eliminate the implication that the = slave then connects to the Internet through the master (it uses white space= spectrum, right)? _____ 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary in = the example, since there are no slaves. ____ Mancuso: Again, master only connotes ability to query the db directly by th= e device. ____ 4: "Master" seems unnecessary to the example. Also, I suggest in the second= -to-last paragraph, you say "The databases are locale specific" instead of = "country specific", and delete the word "competing" from the last sentence = of that paragraph. ________ Mancuso: Same response re masters as above. Made the suggested wording chan= ges re "locale" and "competing." _____ 4.1, item 1: Is this referring to the Internet connectivity between the WS = device and the database? If so, as above, does it necessarily need to be an= air interface? ___ Mancuso: TODO _____ 4.1, item 3: Again I suggest changing "operate in any country" to "operate = in any locale" and change "country-specific" to "locale-specific". (The oth= er occurrence of "country" seems correct.) ____ Mancuso: Made suggested wording changes. _____ 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "do= main" be sufficient? _____ Stanforth: The regulatory domain is assumed to be similar to a country doma= in but need not be. A database could be permitted to serve a different def= inition. In the FCC case they currently limit the domain to the 12mile naut= ical limit and, as we speak databases are only permitted to service the NE = USA. _____ Resnick: I don't think you answered my question. _____ Mancuso: I changed to "domain specific". Not that the db may not be locale-= based (a South American country may opt for FCC domain rules). _____ 5.1 and 5.2: I don't understand the distinction between "Normative" and "No= n-normative" requirements in this context. Isn't it sufficient that you've = separately labeled "Data Model Requirements", "Protocol Requirements", and = "Operational Requirements"? _____ Mancuso: Agreed. Changed the heads and organization. _____ Mancuso: Remaining items TODO. _____ P.1: "The master device may validate the database against a list of approve= d databases maintained by a regulatory body." I don't understand that as a = protocol requirement. What is being required? P.5 and P.6: The requirement here is for *message-level* integrity and encr= yption? That's OK, but I want to make sure that's what you mean. P.8 and P.14: I don't think "result codes" and "response codes" are the req= uirement here, are they? It sounds like the requirement is "indication of s= uccess or failure". P.15: I'm not clear on what this requirement means in practical terms. Some= more explanation seems in order. P.16: Shouldn't this be combined with P.9? O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required = by the database"? _____ Stanforth: Acceptable Location Accuracy is defined by the regulator and app= lied to the calculations of the database _____ Resnick: So the database will tell the device what level of accuracy is req= uired? _____ O.3: This seems to indicate that database discovery will be out of band, th= at the WG is not developing protocol to do so. Is that what you meant? If n= ot, this should be turned into a protocol requirement instead of an operati= onal requirement. O.4: This requirement seems a bit overly obvious and silly to state as a re= quirement. Why is it necessary to say that you need a connection? O.5: Again, "regulatory body" seems unnecessary here. Substituting "databas= e" seems sufficient, since you'll be getting the rule set from the database= . _____ Stanforth: General observation about this and the next couple of comments. = The FCC Certifies a radio and a database as a "system" Ofcom is not conside= ring a system. Other regulators may have other thoughts. In the case of the= FCC some of the function is validated/certified, what ever you want to cal= l it for the combination not as a function of one or the other. So while it seems logical to have an implementation within a database it is= not necessarily considered as such. _____ Resnick: Again, I'm not understand your reply. Can you expand on what you m= ean here? _____ O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can change = "local regulatory policy" to "the database rule set", "determined by regula= tor policy" can be "enumerated in the database rule set", etc. Section 7, generally: Same issue with "regulatory". See if there are any th= at are more accurately "database rules". Threat 7: This doesn't strike me as a security consideration per se. This m= ight make more sense incorporated into an operational requirement. On Thu, Jan 24, 2013 at 3:19 PM, > wrote: Will wait for Tony to generate a new version by addressing the received com= ments, before issuing the Last Call. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Pete Resnick Sent: Wednesday, January 23, 2013 2:59 PM To: Anthony Mancuso Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmt= s-10 Like I said, I'll await word from Brian and Gabor tomorrow for "go" or "no = go" with the Last Call, even if there is no new draft ready to go. We can L= ast Call -10 if nobody thinks there's a strong reason to wait. I am fine wi= th either path. pr On 1/23/13 4:54 PM, Anthony Mancuso wrote: I',m not sure I can turn around the doc by tomorrow since there are some te= chnical points I need to collaborate on. On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian > wrote: I think if Tony can spin a rev before EOB tomorrow, we should do that, but = I'm thinking that the current rev is good enough, and I'd prefer to get it = into the Feb 7 telechat. I don't feel very strongly about that, but... Brian On Jan 23, 2013, at 5:10 PM, Pete Resnick > wrote: One hitch: If you make the call by EOB tomorrow, I can get the Last Call se= nt out, which means (assuming the LC goes well) I can get it on the IESG te= lechat Feb 7. If we have to wait two additional weeks until the Feb 14 tele= chat, it's not a huge deal, but we have to say "go" or "no go" to the Last = Call by EOB tomorrow for me to sneak it on to the earlier telechat. pr On 1/23/13 4:04 PM, Anthony Mancuso wrote: Good suggestion Gabor. I will wait another day or so and then start on gene= rating a new version in response to the comments and clarifications. On Wed, Jan 23, 2013 at 1:55 PM, > wrote: My suggestion would be, if Tony has the time and willingness, then generate= a new version and try to address these comments, perhaps taking the clarif= ications from Peter (and any input from others if available until tomorrow)= into consideration. Thanks, Gabor -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602116D38008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Thanks Tony.

    Pete, this version I thin= k is ready for Last Call.

     <= /p>

    - =          Gabor<= /span>

     <= /p>

     <= /p>

    From: ext Anth= ony Mancuso [mailto:amancuso@google.com]
    Sent: Tuesday, January 29, 2013 3:16 PM
    To: Bajko Gabor (Nokia-CIC/SiliconValley)
    Cc: Pete Resnick; paws@ietf.org
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

     

    To PAWS list:

     

    Here are the collected comments on version 10 (the l= ast posted version) of the PAWS Use Case & Requirements draft and my re= sponses (what I did and didn't do) for version 12, which I just posted to I= ETF.

     

    Thanks for all the feedback!

     

    Tony Mancuso

     

    Abstract

     

    End of the first paragraph, perhaps add: "The I= ETF has undertaken to develop a protocol for that management database."= ;

    ___

    Mancuso: Done

    _____

     

    Introduction

     

    Also added reference to the PAWS protocol to 1.1.

     

    1.2.1: Are 2 & 3 combinable? "Connect to an= d optionally register with the database using a well-defined protocol."= ;

    _____

    Mancuso: Done:

    _____

     

    Conventions and Terminology

     

    2.2: For "Device ID", it says, "that = identifies the manufacturer, model number, and serial number." Does th= e device ID have to identify that information? Can it simply be unique?

    ____

    Stanforth: Regulators are asking for manufacturer an= d model number as they may require action, enforcement or denial by the DB = on the set to manufacturer devices or a specific model of device=

    _____

    Resnick: I guess the question is: Are there any pote= ntial implementers of this protocol (or potential regulatory bodies) that *= don't* care about manufacturer or model or etc.?

    _____

    Mancuso: Simplified to:  "An identifier fo= r each master device." 

    _________

     

    "Device Class" is only used once in sectio= n 5.1. No need for the definition here.

     

    "Location Based Service" is only used once= in section 3. No need for the definition here.

     

    "Protected Entity" is only used once in se= ction 4.1. No need for the definition here.

     

    "Protected Contour" is never used. No need= for the definition at all.

     

    "Radio Access Technology" is only used onc= e in section 5.1. No need for the definition here.

    _____

    Nancy Bravin: I think since we are dealing with a pr= otocol that can be used globally, terms such as listed below, with definiti= on, will make it easier to those countries who are not English speaking, or= the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration f= or emerging countries that lack experience in these areas.

    _____

    Resnick: Sorry, I think I wasn't clear enough. Other= than "Protected Contour" (which is not used anywhere), I was not= suggesting having *no* definition of the terms listed. I was just saying t= hat if they only occur once in the document, define them inline where they are used instead of in the definitions secti= on. But that's strictly an editorial comment. Entirely up to you all whethe= r you want to make a change.

    _____

    Mancuso: Deleted Protected Contour, and moved the de= finition of single-use terms into the text.

    _____

     

    Protocol Services (separated out Protocol Services f= rom Use Cases per comment below. (I renumbered the comments below to corres= pond to the new organization).

     

    3. This section (and its subsections) seems oddly pl= aced. It is not use cases, but general protocol services that cut across us= e cases. Perhaps 3.1 and 3.2 should be separate top-level sections?

    ---

    Mancuso: Done. Moved Protocol Services to new top-le= vel head (Section 3); Use Cases now in new Section 4.

    _____

     

    3. "A complete protocol solution must enable al= l potential white space services." That seems a bit absolute. How abou= t "must enable many different potential white space services"?

    ____

     

    Benjamin Rolfe: I'd strike the entire sentence. Ther= e is no such thing as a "complete protocol".   If you must h= ave it, change it to "this protocol" and it isn't wrong (but stil= l not adding information).

     

    Mancuso: Rephrased to: "A protocol solution mus= t enable many different potential white space services. ".<= /p>

    _____

     

    3.1 & 3.2: Throughout this section, there's no n= eed to use the term "master". These services exist whether a devi= ce is acting as a master for other devices or whether it is acting on its o= wn. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "maste= r" confusing in these sections. (I suppose you could expand the defini= tion of master in 2.2 to explain that it could refer to a device acting on = its own with no slaves, but I still think that might be confusing.

    _____

    Stanforth: Broadcast use case is a master with no sl= ave, at least in the context of a slave that communicates with or is contro= lled by a master.

    _____

    Resnick: So are you saying we do or do not need the = term "master" in these sections?

    _____

    Mancuso: I clarified the definition of master device= : "A device that queries a database, on its own behalf and/or on behal= f of a slave device, to obtain available spectrum information.". I thi= nk this definition plus the definition of a slave device ("A device that queries the database through a Master De= vice.") makes the use of the term in this and latter sections and illu= strations appropriate -- namely, a master device is one that contacts a dat= abase to obtain spectrum (for itself or other devices). Slave devices under these definitions, do not contact the db dir= ectly, omitting them from the discussion and refering in the text or illust= rations solely to a master device makes sense, and is not dependent on also= referencing a slave device. Another way of saying it: we use the term master only as a way of describing a dev= ice used to query the db directly for spectrum availability. Denoting a dev= ice as master does not necessarily imply the use of slaves (devices that ar= e not used to query the db directly) in a particular use case or illustration.

    _______________

     

    3.1, item 2: This says that the device will discover= the database "in the local regulatory domain". How does the devi= ce determine the "local regulatory domain"? I suspect that the ph= rase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not expl= ained.

    _____

    Stanforth: The location of a device determines it re= gulatory domain. However the device may understand this or it may be told.&= nbsp;

    _____

    Resnick: Right. That seems to indicate that the devi= ce that this section should say, "for its current location" and n= ot "in the local regulatory domain". The device needs to know its= location, but not its regulatory domain.

    _____

    Stanforth: For instance our current US implementatio= n validates that a device is within the regulatory domain. If not we deny i= t service but allowed for the DB to tell the device who or what it should c= ontact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together wit= h the comment below this may need some thought and additional work.

    _____

    Resnick: I think we're on the same page.<= /p>

    _____

    Mancuso: Rewrote to clarify the difference between t= he discovery phase (locating a trusted database) and the initial contact wi= th the trusted database. Also noted the different ways a device can locate = the database URI (through discovery or pre-configured URIs).

    _______

    3.2: Similar questions regarding regulatory domains.= For example, "2.  To register with the database, the master devi= ce sends the database the registration information required under regulator= y rules." How does the device determine which regulatory rules it is under and therefore which information to send to th= e database. If the answer is, "It queries the database", then it = is not the regulatory rules the device cares about; it is the information t= he database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band = of any protocol work). If the answer is, "It is pre-configured in the = device", then the regulatory rules are again out of band. Either way, = mention of them would be unnecessary.

    ___

    Mancuso: Agreed. I think this was simply a matter of= misphrasing. Deleted the extra language to read: "To register with th= e database, the master device sends registration information to the databas= e."

    _____

     

    Use Cases

     

    4.1, 4.2, and 4.3, in general: When "slave devi= ce" is defined in 2.2, it's only a slave for purposes of talking to th= e database. But there is an implication in these sections that the slave de= vice uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification= that's needed. Further confusing me about this point is (a) the master dev= ice is always the one in the diagrams with the antenna, but as far as I can= tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air"= ; seem to me not to require an air interface, but could also be wired. I co= uld use some explanation.

    _____

    Stanforth

    The FCC, as an example, has two concepts of a slave.= The first is a client served by a master, think 802.11 client using a chan= nel served by an AP. This is the model for low power devices. 

    _____

    Resnick: OK, but does the low power device actually = ever request white space spectrum? If not, then it is not involved in this = protocol, right?

    ___

    Stanforth: If the device is a high power device the = slave must get it's own channel list. It can use a master to do this, using= white space spectrum, if it has no other means of contacting the database.=

    ____

    Resnick: This I understood until you said "usin= g white space spectrum". It can't use white space spectrum to talk to = the master until it is allocated spectrum by the database, can it? It talks= to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then = stops talking to the master, correct?

    ____

    Mancuso: Masters are defined as the device that can = contact the db on its own (knows its geolocation), and the use cases I thin= k are consistent with this definition. There is no constraint on how the sl= aves or masters communicate (air or wire) but the illustrations attempt to show common connections for the exa= mples (for hotspots, WANS, etc., slave devices will connect over air to mas= ter). Also, slaves can use white space spectrum as appropriate to the local= white space network being established -- to connect to the Internet through the master (or some other AP), for l= ocal communications only, or some other use of the spectrum. I deleted the = extra master antenna shown in use case 5 (local tv broadcast).

     

    4.1, item 7: Does the slave provide its location, de= vice identifier, and antenna height, the same way the master does when it q= ueries? If so (especially in the case of the master sub-allocating for the = slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further= explanation might be in order.

    _____

    Stanforth: As above a low power slave, under FCC rul= e, does not have to provide any of this information but a high power slave = does.

    _____

    Resnick: Does a low power slave talk to the database= at all?

    _____

    Mancuso: I moved related slave requests into the cor= responding sections for the master.

    ______

    4.1, item 8: It says that the white space is allocat= ed to slaves "for communication over the network". That's not rig= ht is it? In this scenario, the allocated white space could be used for net= work (I read "Internet") communication *or anything else*, can't it?

    _____

    Stanforth: High power again. A slave may not get the= same channel list as the master and may not be able to use the channel the= master is currently using so a negotiation will be necessary.

    _____

    Resnick: I'm not sure whether you agree or disagree = with my point here. I don't understand your reply.

    _____

    Mancuso: The network refers to the local master-slav= e network, not to connectivity to the Internet. I deleted "for communi= cation over the network" for clarity.

    _____

     

    3.2.1, item 9: Is this an important part of the scen= ario? Why wouldn't it be perfectly reasonable for communication between the= master and slaves continue on its original connection and that the white s= pace is only used for other communications the slave wishes to do?

    _____

    Stanforth: same as Iten 8, above.

    ____

    Mancuso: Changed to "may occur". Technical= ly, the "network" we are talking about here is the white space ne= twork, which only uses white space (after initial bootstrapping communicati= ons between slaves and masters). But I agree that we should recognize (implicitly) the ability of devices to use other spectrum/techno= logies for ongoing communications.

    _____

     

    4.2: This scenario was confusing to me because the m= aster seems completely unnecessary to the example. Please explain.

    _____

    Mancuso: As noted, the master is optionally used by = the slave to query the db for spectrum. And again, master only connotes the= device's ability to query the db directly.

    _____

     

    4.4 and 4.5: Another example of the term "maste= r" seems unnecessary in the example, since there are no slaves.

    ____

    Mancuso: Again, master only connotes ability to quer= y the db directly by the device.

    ____

     

    Problem Statement

     

    5: "Master" seems unnecessary to the examp= le. Also, I suggest in the second-to-last paragraph, you say "The data= bases are locale specific" instead of "country specific", an= d delete the word "competing" from the last sentence of that para= graph.

    ________

    Mancuso: Same response re masters as above. Made the= suggested wording changes re "locale" and "competing."=

    _____

     

    5.1, item 1: Is this referring to the Internet conne= ctivity between the WS device and the database? If so, as above, does it ne= cessarily need to be an air interface?

    ___

    Mancuso: This wasn't meant to imply air the exclusiv= e interface -- Made this clearer by using "any" air interface use= d by devices; further limited reference to messages betweein devices and db= as messages from master device to db (since, by definition, slave devices don't communicate directly to db).=

    _____

     

    5.1, item 3: Again I suggest changing "operate = in any country" to "operate in any locale" and change "= country-specific" to "locale-specific". (The other occurrenc= e of "country" seems correct.)

    ____

    Mancuso: Made suggested wording changes.<= /p>

    _____

     

    5.2: Instead of "regulatory-domain", would= n't either "locale" or simply "domain" be sufficient?

    _____

    Stanforth: The regulatory domain is assumed to be si= milar to a country domain but need not be. A database could be permitted to= serve  a different definition. In the FCC case they currently limit t= he domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA.<= /o:p>

    _____

    Resnick: I don't think you answered my question.

    _____

    Mancuso: I changed to "domain specific". N= ot that the db may not be locale-based (a South American country may opt fo= r FCC domain rules).

    _____

     

    5.1 and 5.2: I don't understand the distinction betw= een "Normative" and "Non-normative" requirements in thi= s context. Isn't it sufficient that you've separately labeled "Data Mo= del Requirements", "Protocol Requirements", and "Operat= ional Requirements"?

    _____

    Mancuso: Agreed. Changed the heads and organization.=

     

    Requirements:

    _____

    P.1: "The master device may validate the databa= se against a list of approved databases maintained by a regulatory body.&qu= ot; I don't understand that as a protocol requirement. What is being requir= ed?

    ___

    Mancuso: (Moved info up from Operation requirements = per later comment). Rephrased to clarify that the master device MUST identi= fy a db, and MAY discover or be pre-configured with db URIs, and MAY valida= te db URIs against a list of approved databases maintained by a regulatory body."

     

    P.5 and P.6: The requirement here is for *message-le= vel* integrity and encryption? That's OK, but I want to make sure that's wh= at you mean.

    ___

    Rex Buddenberg: encryption gets you confidentiality = (which may or may not be a

    requirement).  It does not get you authenticity= .

     

    integrity gets you bit-perfection.  Which is a = requirement.  But

    integrity does not get you authenticity ... which is= a requirement. I

    can't think of a situation where you don't need both= .  (In public key, a

    digital signature provides both authenticity and int= egrity, assuming you

    have a PKI you can rely on.

    ____

    Mancuso: Yes, that is the intent, and yes, we want a= ll three. DB authenticity is addressed in p4.

    ___

    P.8 and P.14: I don't think "result codes"= and "response codes" are the requirement here, are they? It soun= ds like the requirement is "indication of success or failure".

    _____

    Mancuso: Rephrased to state the requirement in terms= of the success or failure of the requests.

    _____

     

    P.15: I'm not clear on what this requirement means i= n practical terms. Some more explanation seems in order.

    ___

    Mancuso: Rephrased for clarity to: "The protoco= l MUST support the capability for the database to inform master devices of = changes to spectrum availability information in a timely manner."=

     

    P.16: Shouldn't this be combined with P.9?

    ___

    Mancuso: Deleted P.16; this was already included und= er D.9.

    _____

     

    O.2: The "required accuracy" is ambiguous.= Do you mean, "accuracy required by the database"?

    _____

    Stanforth: Acceptable Location Accuracy is defined b= y the regulator and applied to the calculations of the database<= /p>

    _____

    Resnick: So the database will tell the device what l= evel of accuracy is required?

    _____

    Mancuso: Clarified as follows: "Locations MUST = be determined to the accuracy required by the applicable regualtory domain.= " These are operational requirements, and not part of the protocol. Ac= curacy is verified by certification of devices by regulators. 

    ____

     

    O.3: This seems to indicate that database discovery = will be out of band, that the WG is not developing protocol to do so. Is th= at what you meant? If not, this should be turned into a protocol requiremen= t instead of an operational requirement. 

    __

     

    Mancuso: The master locating the DB is a requirement= , so I moved this to P.1. Renumbered the remaining requirements (and commen= ts below).

    ____

     

    O.3: This requirement seems a bit overly obvious and= silly to state as a requirement. Why is it necessary to say that you need = a connection?

    ____

     

    Mancuso: Deleted the first sentence.

     

    O.4: Again, "regulatory body" seems unnece= ssary here. Substituting "database" seems sufficient, since you'l= l be getting the rule set from the database.

    _____

    Stanforth: General observation about this and the ne= xt couple of comments. The FCC Certifies a radio and a database as a "= system" Ofcom is not considering a system. Other regulators may have o= ther thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the= combination not as a function of one or the other.

    So while it seems logical to have an implementation = within a database it is not necessarily considered as such.

    _____

    Resnick: Again, I'm not understand your reply. Can y= ou expand on what you mean here?

    _____

    Mancuso: The statment here is regarding the rule set= , which is from the regulator, so the current phrasing seems OK. Note there= are a significant number of device-only rule-set requirements (complexity = is to be expected), so the operational requirement here is for the master to obtain "information." The = current expectation is that the db may communicate the name of the applicab= le regulatory ruleset to the device, but not the specific parameters.<= /o:p>

    _____

     

    O.5 (and O.9 through O.10 and O.12 through O.14): As= above, you can change "local regul8atory policy" to "the da= tabase rule set", "determined by regulator policy" can be &q= uot;enumerated in the database rule set", etc.

    ____

    Mancuso: A db can serve multiple regulatory domains,= and hence, rulesets. And note that the currently applicaple rule set may n= ot come from a local regulatory domain, but be imported from a foreign regu= lator (e.g., Brazil decides to use FCC rules)

    _____

     

    Security Considerations

     

    Section 8, generally: Same issue with "regulato= ry". See if there are any that are more accurately "database rule= s".

    ____

    Mancuso: Again, multiple rule sets may apply for a g= iven regulatory domain.

     

    Threat 7: This doesn't strike me as a security consi= deration per se. This might make more sense incorporated into an operationa= l requirement.

    ___

    Mancuso: Agreed. Moved duscussion of emergency servi= ces need for white space to new O.17 requirement, and condensed it to: &quo= t;In the case of a natural disaster,emergency services may need to use dist= ributed white space databases on short notice. The database should support any emergency regulations adopted by r= egulators to provide priority allocation of white space spectrum to emergen= cy services."

     

    ---

    end of comments

     

     

     

     

     

    On Fri, Jan 25, 2013 at 9:51 AM, Anthony Mancuso <= ;amancuso@google.c= om> wrote:

    I just posted version 11 of the PAWS Use Case & = Requirements draft to IETF. In this draft, I responded to several of the co= mments posted to the list; I left a few TODOs, and am awaiting further comm= ents for the next draft.

     

    My notes are in preparing this version are set out b= elow.

     

    Tony Mancuso

     

    ***************

    Tony Mancuso Notes - PAWS Use Case & Requirement= s Notes v. 11 (I consolidated Pete Resnick's initial comments with other co= mments received on selected points together with my responses)

     

    Abstract: End of the first paragraph, perhaps add: &= quot;The IETF has undertaken to develop a protocol for that management data= base."

    ___

    Mancuso: Done

    _____

     

    Also add the above to 1.1.

     

    1.2.1: Are 2 & 3 combinable? "Connect to an= d optionally register with the database using a well-defined protocol."= ;

    _____

    Mancuso: Done:

    _____

     

    2.2: For "Device ID", it says, "that = identifies the manufacturer, model number, and serial number." Does th= e device ID have to identify that information? Can it simply be unique?

    ____

    Stanforth: Regulators are asking for manufacturer an= d model number as they may require action, enforcement or denial by the DB = on the set to manufacturer devices or a specific model of device=

    _____

    Resnick: I guess the question is: Are there any pote= ntial implementers of this protocol (or potential regulatory bodies) that *= don't* care about manufacturer or model or etc.?

    _____

    Mancuso: Waiting for further comment.

    _____

    "Device Class" is only used once in sectio= n 5.1. No need for the definition here.

     

    "Location Based Service" is only used once= in section 3. No need for the definition here.

     

    "Protected Entity" is only used once in se= ction 4.1. No need for the definition here.

     

    "Protected Contour" is never used. No need= for the definition at all.

     

    "Radio Access Technology" is only used onc= e in section 5.1. No need for the definition here.

    _____

    Nancy Bravin: I think since we are dealing with a pr= otocol that can be used globally, terms such as listed below, with definiti= on, will make it easier to those countries who are not English speaking, or= the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration f= or emerging countries that lack experience in these areas.

    _____

    Resnick: Sorry, I think I wasn't clear enough. Other= than "Protected Contour" (which is not used anywhere), I was not= suggesting having *no* definition of the terms listed. I was just saying t= hat if they only occur once in the document, define them inline where they are used instead of in the definitions secti= on. But that's strictly an editorial comment. Entirely up to you all whethe= r you want to make a change.

    _____

    Mancuso: Deleted Protected Contour, and moved the de= finition of single-use terms into the text.

    _____

     

    3.1 This section (and its subsections) seems oddly p= laced. It is not use cases, but general protocol services that cut across u= se cases. Perhaps 3.1 and 3.2 should be separate top-level sections?

    ---

    Mancuso: Done. Moved Protocol Services to new top-le= vel head (Section 3); Use Cases now in new Section 4.

    _____

     

    3.1 "A complete protocol solution must enable a= ll potential white space services." That seems a bit absolute. How abo= ut "must enable many different potential white space services"?

    ____

    Mancuso: Done.

    _____

     

    3.1.1 & 3.1.2: Throughout this section, there's = no need to use the term "master". These services exist whether a = device is acting as a master for other devices or whether it is acting on i= ts own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "= ;master" confusing in these sections. (I suppose you could expand the = definition of master in 2.2 to explain that it could refer to a device acti= ng on its own with no slaves, but I still think that might be confusing.

    _____

    Stanforth: Broadcast use case is a master with no sl= ave, at least in the context of a slave that communicates with or is contro= lled by a master.

    _____

    Resnick: So are you saying we do or do not need the = term "master" in these sections?

    _____

    Mancuso: I clarified the definition of master device= : "A device that queries a database, on its own behalf and/or on behal= f of a slave device, to obtain available spectrum information.". I thi= nk this definition plus the definition of a slave device ("A device that queries the database through a Master De= vice.") makes the use of the term in the section appropriate -- namely= , a master device is one that contacts a database to obtain spectrum (for i= tself or other devices). Slave devices under these definitions, do not contact the db directly, omitting them from the = discussion at this point makes sense. Another way of saying it: we use the = term master only as a way of describing a device used to query the db direc= tly for spectrum availability. Denoting a device as master does not necessarily imply the use of slaves (devices t= hat are not used to query the db directly) in a particular use case.

    _______________

     

    3.1.1, item 2: This says that the device will discov= er the database "in the local regulatory domain". How does the de= vice determine the "local regulatory domain"? I suspect that the = phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not = explained.

    _____

    Stanforth: The location of a device determines it re= gulatory domain. However the device may understand this or it may be told.&= nbsp;

    _____

    Resnick: Right. That seems to indicate that the devi= ce that this section should say, "for its current location" and n= ot "in the local regulatory domain". The device needs to know its= location, but not its regulatory domain.

    _____

    Stanforth: For instance our current US implementatio= n validates that a device is within the regulatory domain. If not we deny i= t service but allowed for the DB to tell the device who or what it should c= ontact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together wit= h the comment below this may need some thought and additional work.

    _____

    Resnick: I think we're on the same page.<= /p>

    _____

    Mancuso: The intent of the existing wording is simpl= y that the master sends out a request and waits for a response, not to impl= y that it the device query is constrained or qualified by the device's unde= rstanding of its regulatory domain. I deleted the extra language to read as follows: "The master device c= onstructs and sends a service request over the Internet."

    _______

    3.1.2: Similar questions regarding regulatory domain= s. For example, "2.  To register with the database, the master de= vice sends the database the registration information required under regulat= ory rules." How does the device determine which regulatory rules it is under and therefore which information to send to th= e database. If the answer is, "It queries the database", then it = is not the regulatory rules the device cares about; it is the information t= he database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band = of any protocol work). If the answer is, "It is pre-configured in the = device", then the regulatory rules are again out of band. Either way, = mention of them would be unnecessary.

    ___

    Mancuso: Agreed. Again, I think this was simply a ma= tter of misphrasing. Deleted the extra language to read: "To register = with the database, the master device sends registration information to the = database."

    _____

     

    3.2.1, 3.2.2, and 3.2.3, in general: When "slav= e device" is defined in 2.2, it's only a slave for purposes of talking= to the database. But there is an implication in these sections that the sl= ave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification= that's needed. Further confusing me about this point is (a) the master dev= ice is always the one in the diagrams with the antenna, but as far as I can= tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air"= ; seem to me not to require an air interface, but could also be wired. I co= uld use some explanation.

    _____

    Stanforth

    The FCC, as an example, has two concepts of a slave.= The first is a client served by a master, think 802.11 client using a chan= nel served by an AP. This is the model for low power devices. 

    _____

    Resnick: OK, but does the low power device actually = ever request white space spectrum? If not, then it is not involved in this = protocol, right?

    ___

    Stanforth: If the device is a high power device the = slave must get it's own channel list. It can use a master to do this, using= white space spectrum, if it has no other means of contacting the database.=

    ____

    Resnick: This I understood until you said "usin= g white space spectrum". It can't use white space spectrum to talk to = the master until it is allocated spectrum by the database, can it? It talks= to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then = stops talking to the master, correct?

    ____

    Mancuso: Waiting for any further input.

    _____ 

     

    3.2.1, item 7: Does the slave provide its location, = device identifier, and antenna height, the same way the master does when it= queries? If so (especially in the case of the master sub-allocating for th= e slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some furt= her explanation might be in order.

    _____

    Stanforth: As above a low power slave, under FCC rul= e, does not have to provide any of this information but a high power slave = does.

    _____

    Resnick: Does a low power slave talk to the database= at all?

    _____

    Mancuso: Waiting for any further input.

    ______

    3.2.1, item 8: It says that the white space is alloc= ated to slaves "for communication over the network". That's not r= ight is it? In this scenario, the allocated white space could be used for n= etwork (I read "Internet") communication *or anything else*, can't it?

    _____

    Stanforth: High power again. A slave may not get the= same channel list as the master and may not be able to use the channel the= master is currently using so a negotiation will be necessary.

    _____

    Resnick: I'm not sure whether you agree or disagree = with my point here. I don't understand your reply.

    _____

    Mancuso: Waiting for any further input.

    _____

     

    3.2.1, item 9: Is this an important part of the scen= ario? Why wouldn't it be perfectly reasonable for communication between the= master and slaves continue on its original connection and that the white s= pace is only used for other communications the slave wishes to do?

    _____

    Stanforth: same as Iten 8, above.

    ____

    Mancuso: TODO.

    _____

     

    3.2.2: This scenario was confusing to me because the= master seems completely unnecessary to the example. Please explain.

    _____

    Mancuso: TODO. The master is optionally used by the = slave to query the db for spectrum. And again, master only connotes ability= to query the db directly by the device. I do think we need to eliminate th= e implication that the slave then connects to the Internet through the master (it uses white space spectrum,= right)?

    _____

     

    3.2.4 and 3.2.5: Another example of the term "m= aster" seems unnecessary in the example, since there are no slaves.

    ____

    Mancuso: Again, master only connotes ability to quer= y the db directly by the device.

    ____

    4: "Master" seems unnecessary to the examp= le. Also, I suggest in the second-to-last paragraph, you say "The data= bases are locale specific" instead of "country specific", an= d delete the word "competing" from the last sentence of that para= graph.

    ________

    Mancuso: Same response re masters as above. Made the= suggested wording changes re "locale" and "competing."=

    _____

     

    4.1, item 1: Is this referring to the Internet conne= ctivity between the WS device and the database? If so, as above, does it ne= cessarily need to be an air interface?

    ___

    Mancuso: TODO

    _____

     

    4.1, item 3: Again I suggest changing "operate = in any country" to "operate in any locale" and change "= country-specific" to "locale-specific". (The other occurrenc= e of "country" seems correct.)

    ____

    Mancuso: Made suggested wording changes.<= /p>

    _____

     

    4.2: Instead of "regulatory-domain", would= n't either "locale" or simply "domain" be sufficient?

    _____

    Stanforth: The regulatory domain is assumed to be si= milar to a country domain but need not be. A database could be permitted to= serve  a different definition. In the FCC case they currently limit t= he domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA.<= /o:p>

    _____

    Resnick: I don't think you answered my question.

    _____

    Mancuso: I changed to "domain specific". N= ot that the db may not be locale-based (a South American country may opt fo= r FCC domain rules).

    _____

     

    5.1 and 5.2: I don't understand the distinction betw= een "Normative" and "Non-normative" requirements in thi= s context. Isn't it sufficient that you've separately labeled "Data Mo= del Requirements", "Protocol Requirements", and "Operat= ional Requirements"?

    _____

    Mancuso: Agreed. Changed the heads and organization.=

    _____

    Mancuso: Remaining items TODO.

    _____

    P.1: "The master device may validate the databa= se against a list of approved databases maintained by a regulatory body.&qu= ot; I don't understand that as a protocol requirement. What is being requir= ed?

     

    P.5 and P.6: The requirement here is for *message-le= vel* integrity and encryption? That's OK, but I want to make sure that's wh= at you mean.

     

    P.8 and P.14: I don't think "result codes"= and "response codes" are the requirement here, are they? It soun= ds like the requirement is "indication of success or failure".

     

    P.15: I'm not clear on what this requirement means i= n practical terms. Some more explanation seems in order.

     

    P.16: Shouldn't this be combined with P.9?

     

    O.2: The "required accuracy" is ambiguous.= Do you mean, "accuracy required by the database"?

    _____

    Stanforth: Acceptable Location Accuracy is defined b= y the regulator and applied to the calculations of the database<= /p>

    _____

    Resnick: So the database will tell the device what l= evel of accuracy is required?

    _____

     

    O.3: This seems to indicate that database discovery = will be out of band, that the WG is not developing protocol to do so. Is th= at what you meant? If not, this should be turned into a protocol requiremen= t instead of an operational requirement.

     

    O.4: This requirement seems a bit overly obvious and= silly to state as a requirement. Why is it necessary to say that you need = a connection?

     

    O.5: Again, "regulatory body" seems unnece= ssary here. Substituting "database" seems sufficient, since you'l= l be getting the rule set from the database.

    _____

    Stanforth: General observation about this and the ne= xt couple of comments. The FCC Certifies a radio and a database as a "= system" Ofcom is not considering a system. Other regulators may have o= ther thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the= combination not as a function of one or the other.

    So while it seems logical to have an implementation = within a database it is not necessarily considered as such.

    _____

    Resnick: Again, I'm not understand your reply. Can y= ou expand on what you mean here?

    _____

     

    O.6 (and O.9 through O.11 and O.13 through O.15): As= above, you can change "local regulatory policy" to "the dat= abase rule set", "determined by regulator policy" can be &qu= ot;enumerated in the database rule set", etc.

     

    Section 7, generally: Same issue with "regulato= ry". See if there are any that are more accurately "database rule= s".

     

    Threat 7: This doesn't strike me as a security consi= deration per se. This might make more sense incorporated into an operationa= l requirement.

     

     

     

    On Thu, Jan 24, 2013 at 3:19 PM, <Gabor.Bajko@nokia.com> w= rote:

    Will wait for Tony to generate a new ve= rsion by addressing the received comments, before issuing the Last Call.

     

    -          Gabor

     

    From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Pete Resnick
    Sent: Wednesday, January 23, 2013 2:59 PM
    To: Anthony Mancuso


    Cc: paws@ietf.org=
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

     

    Like I said, I'll await word from Brian and Gabor tomorrow for &qu= ot;go" or "no go" with the Last Call, even if there is no ne= w draft ready to go. We can Last Call -10 if nobody thinks there's a strong reason to wait. I am fine with either path.



    pr

    On 1/23/13 4:54 PM, Anthony Mancuso wrote:

    I',m not sure I can turn around the doc by tomorrow since there ar= e some technical points I need to collaborate on.

     

    On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <Brian.Rosen@neustar.biz>= ; wrote:

    I think if Tony can spin a rev before EOB tomorrow, we should do t= hat, but I'm thinking that the current rev is good enough, and I'd prefer t= o get it into the Feb 7 telechat.  

     

    I don't feel very strongly about that, but…

     

    Brian

     

    On Jan 23, 2013, at 5:10 PM, Pete Resnick <presnick@qti.qualcomm.com>= ; wrote:

     

    One hitch: If you make the call by EOB tomorrow, I can get the Las= t Call sent out, which means (assuming the LC goes well) I can get it on th= e IESG telechat Feb 7. If we have to wait two additional weeks until the Feb 14 telechat, it's not a huge deal,= but we have to say "go" or "no go" to the Last Call by= EOB tomorrow for me to sneak it on to the earlier telechat.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:

    Good suggestion Gabor. I will wait another day or so and then star= t on generating a new version in response to the comments and clarification= s.

     

    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> wrote:

    My suggestion would be, if Tony has the= time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (a= nd any input from others if available until tomorrow) into consideration.

    Thanks, Gabor

     

     

    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________

     

     

     

    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

     

     

    --_000_1ECAFF543A2FED4EA2BEB6CACE08E47602116D38008AM1MPN1006mg_-- From presnick@qti.qualcomm.com Thu Jan 31 06:44:31 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13121F85C3 for ; Thu, 31 Jan 2013 06:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2WEpsLeuwfJe for ; Thu, 31 Jan 2013 06:44:30 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8344621F85B6 for ; Thu, 31 Jan 2013 06:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1359642282; x=1391178282; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=/Y+kvv7glKaguyibAmQPbV6+/0itJdMky0DjjtNheKM=; b=S7qv3g1Ia+VeKOfEb+8cIK9O9EK5nhO+4dNbq36DT3Kw/zLZ89T5C7wb /wMlm1lzdvC8l+HE1Fgv4oxJgakTgUwrBCEoJIxAOqVKaPShmR933SYb7 ru7G4b22hm+1SOUmBgP4Zktv+YaG/eMpe2BFH5o21ngSiESIgKNbEBhJR c=; X-IronPort-AV: E=Sophos;i="4.84,577,1355126400"; d="scan'208,217";a="19515252" Received: from unknown (HELO Ironmsg03-L.qualcomm.com) ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 31 Jan 2013 06:24:41 -0800 X-IronPort-AV: E=Sophos;i="4.84,577,1355126400"; d="scan'208,217";a="413861248" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jan 2013 06:44:28 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 31 Jan 2013 06:44:28 -0800 Message-ID: <510A834B.2080400@qti.qualcomm.com> Date: Thu, 31 Jan 2013 08:44:27 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602116D38@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47602116D38@008-AM1MPN1-006.mgdnok.nokia.com> Content-Type: multipart/alternative; boundary="------------050905000006080809000502" X-Originating-IP: [172.30.39.5] Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 31 Jan 2013 14:44:31 -0000 --------------050905000006080809000502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 1/30/13 12:30 PM, Gabor.Bajko@nokia.com wrote: > > Pete, this version I think is ready for Last Call. > Excellent. I'll have a few more minor comments, but you can simply consider them as Last Call comments and deal with them with any other comments that come in. I'll do the Last Call request today. Dan Romascanu (our IEEE-SA liaison manager) reminded me that we promised to notify the assorted IEEE 802 WGs when documents reach Last Call. Gabor or Brian: Can you take care of that? Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------050905000006080809000502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 1/30/13 12:30 PM, Gabor.Bajko@nokia.com wrote:

    Pete, this version I think is ready for Last Call.


    Excellent. I'll have a few more minor comments, but you can simply consider them as Last Call comments and deal with them with any other comments that come in. I'll do the Last Call request today.

    Dan Romascanu (our IEEE-SA liaison manager) reminded me that we promised to notify the assorted IEEE 802 WGs when documents reach Last Call. Gabor or Brian: Can you take care of that?

    Thanks,

    pr
    -- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
    --------------050905000006080809000502-- From Gabor.Bajko@nokia.com Thu Jan 31 13:18:04 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82321F8722 for ; Thu, 31 Jan 2013 13:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 VcA3N4lBNJ+o for ; Thu, 31 Jan 2013 13:18:03 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id E95F221F84E8 for ; Thu, 31 Jan 2013 13:18:02 -0800 (PST) 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 r0VLHxNO017448; Thu, 31 Jan 2013 23:17:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Jan 2013 23:17:58 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.194]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 21:17:57 +0000 From: To: Thread-Topic: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 Thread-Index: AQHN+ygZEM/lER+xCk+6M1VSx1yP55hg9tOAgAFB0BCAAVP8gIAAbaBw Date: Thu, 31 Jan 2013 21:17:57 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021173BC@008-AM1MPN1-006.mgdnok.nokia.com> References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602116D38@008-AM1MPN1-006.mgdnok.nokia.com> <510A834B.2080400@qti.qualcomm.com> In-Reply-To: <510A834B.2080400@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.32.127] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021173BC008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 31 Jan 2013 21:17:58.0662 (UTC) FILETIME=[719BCA60:01CDFFF8] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 31 Jan 2013 21:18:04 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021173BC008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. I'll send a notification to the relevant ieee802 wgs. - Gabor From: ext Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Thursday, January 31, 2013 6:44 AM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: amancuso@google.com; paws@ietf.org Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmt= s-10 On 1/30/13 12:30 PM, Gabor.Bajko@nokia.com wr= ote: Pete, this version I think is ready for Last Call. Excellent. I'll have a few more minor comments, but you can simply consider= them as Last Call comments and deal with them with any other comments that= come in. I'll do the Last Call request today. Dan Romascanu (our IEEE-SA liaison manager) reminded me that we promised to= notify the assorted IEEE 802 WGs when documents reach Last Call. Gabor or = Brian: Can you take care of that? Thanks, pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021173BC008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Yes. I’ll send a no= tification to the relevant ieee802 wgs.

    - =          Gabor<= /span>

     <= /p>

    From: ext Pete Resnick [mailto:presnick@qti.qualcomm.co= m]
    Sent: Thursday, January 31, 2013 6:44 AM
    To: Bajko Gabor (Nokia-CIC/SiliconValley)
    Cc: amancuso@google.com; paws@ietf.org
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

     

    On 1/30/13 12:30 PM, Gabor.Bajko@nokia.com wrote:

    Pete, this version I think is ready for= Last Call.


    Excellent. I'll have a few more minor comments, but you can simply consider= them as Last Call comments and deal with them with any other comments that= come in. I'll do the Last Call request today.

    Dan Romascanu (our IEEE-SA liaison manager) reminded me that we promised to= notify the assorted IEEE 802 WGs when documents reach Last Call. Gabor or = Brian: Can you take care of that?

    Thanks,

    pr

    -- 
    Pete Resnick <http:/=
/www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478
    --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021173BC008AM1MPN1006mg_-- From presnick@qti.qualcomm.com Thu Jan 31 21:44:31 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E983121F8928 for ; Thu, 31 Jan 2013 21:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=-0.049, 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 nKf9B7IQls-K for ; Thu, 31 Jan 2013 21:44:29 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5E21F890E for ; Thu, 31 Jan 2013 21:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1359696280; x=1391232280; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1+d5NyHKOSQZgA0V7IrWxmonxYs2dOSfXv8fh0iDBTE=; b=vE05mYJW2aUAL/rt0ilPzVpbSxdld2wU+azOGU2MgSUYqnUIXrvqb/l2 4vWTYKGs7MUBkk4Fb0TbaOWIdh0vKADBG1adauH5C07XhTRe6tnpTrgjO h1fsF46Z5YCwatvEimtkv8+pkH7ts1p8HemnjPCC2TILZOK7E4cKMeOVA 0=; X-IronPort-AV: E=Sophos;i="4.84,579,1355126400"; d="scan'208";a="19741917" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 31 Jan 2013 21:24:36 -0800 X-IronPort-AV: E=Sophos;i="4.84,579,1355126400"; d="scan'208";a="414444869" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 31 Jan 2013 21:44:25 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 31 Jan 2013 21:44:24 -0800 Message-ID: <510B5637.3030504@qti.qualcomm.com> Date: Thu, 31 Jan 2013 23:44:23 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Anthony Mancuso References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: "paws@ietf.org" Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 01 Feb 2013 05:44:31 -0000 The Last Call should be coming out of the secretariat soon. Trimming the message to things where I still have some comments. Please consider the following part of the Last Call comments: On 1/29/13 5:15 PM, Anthony Mancuso wrote: > Abstract > > End of the first paragraph, perhaps add: "The IETF has undertaken to > develop a protocol for that management database." > ___ > Mancuso: Done > _____ > > Introduction > > Also added reference to the PAWS protocol to 1.1. Please don't refer to the WG, either in the Abstract or in the Intro. First of all, there ought to be no references in the Abstract anyway since the Abstract is often displayed in announcements and other places without the rest of the document. But more importantly, I don't think what you put in flows very well. In the Abstract, just saying "protocol" is sufficient. In the Intro, I'd suggest simply changing the last paragraph to: This document includes the problem statement for the development of a database query protocol to access a database of whitespace information followed by use cases and requirements for that protocol associated with the use of white space spectrum by secondary users. > 3.1 & 3.2: Throughout this section, there's no need to use the term > "master". These services exist whether a device is acting as a master > for other devices or whether it is acting on its own. Given that > there's been no discussion of slave devices yet (that happens in 3.2), > I found the use of the term "master" confusing in these sections. (I > suppose you could expand the definition of master in 2.2 to explain > that it could refer to a device acting on its own with no slaves, but > I still think that might be confusing. > _____ > Stanforth: Broadcast use case is a master with no slave, at least in > the context of a slave that communicates with or is controlled by a > master. > _____ > Resnick: So are you saying we do or do not need the term "master" in > these sections? > _____ > Mancuso: I clarified the definition of master device: "A device that > queries a database, on its own behalf and/or on behalf of a slave > device, to obtain available spectrum information.". I think this > definition plus the definition of a slave device ("A device that > queries the database through a Master Device.") makes the use of the > term in this and latter sections and illustrations appropriate -- > namely, a master device is one that contacts a database to obtain > spectrum (for itself or other devices). Slave devices under these > definitions, do not contact the db directly, omitting them from the > discussion and refering in the text or illustrations solely to a > master device makes sense, and is not dependent on also referencing a > slave device. Another way of saying it: we use the term master only as > a way of describing a device used to query the db directly for > spectrum availability. Denoting a device as master does not > necessarily imply the use of slaves (devices that are not used to > query the db directly) in a particular use case or illustration. That's all fine, but then in the first sentence of 3.1, it says "A white space radio network is created by a master device." That's not true, or at least not necessarily true. The white space network is created by either the master or the high-power slave. What defines something as a master is not that it creates a white space radio network. A master is simply defined as that which queries the database. So I suspect the word "master" in this section is wrong and the first paragraph of 3.1 needs a bit more work to remove all reference to creation of the whitespace network. Creating the network is not part of the discovery phase at all. > 3.2: Similar questions regarding regulatory domains. For example, "2. > To register with the database, the master device sends the database > the registration information required under regulatory rules." How > does the device determine which regulatory rules it is under and > therefore which information to send to the database. If the answer is, > "It queries the database", then it is not the regulatory rules the > device cares about; it is the information the database is configured > to ask for (which will presumably be in accordance to some > regulations, but are out of band of any protocol work). If the answer > is, "It is pre-configured in the device", then the regulatory rules > are again out of band. Either way, mention of them would be unnecessary. > ___ > Mancuso: Agreed. I think this was simply a matter of misphrasing. > Deleted the extra language to read: "To register with the database, > the master device sends registration information to the database. There are still several references in 3.2 to "regulatory domain" and "regulatory requirement" that I think are unnecessary and confusing and should be removed. > 4.2: This scenario was confusing to me because the master seems > completely unnecessary to the example. Please explain. > _____ > Mancuso: As noted, the master is optionally used by the slave to query > the db for spectrum. And again, master only connotes the device's > ability to query the db directly. OK, this section still does not make sense to me. The slave is getting whitespace in this scenario. But in the diagram, the slave doesn't have the antenna; the master does. That doesn't jibe with the rest of the example. If it's the slave that wants to move away from it's metered service and use whitespace, then it should have the antenna. If the slave wants to talk to an AP that's going to use the whitespace, there should be a box for the AP in the diagram. If you want to say that the master and the AP can be one device, still show two boxes but say they can be in the same box. If the master is doing the querying and setting up the whitespace and the "slave" is doing nothing with regard to whitespace but simply using the master as an Internet gateway, then the "slave" is not a slave. > 5.1, item 1: Is this referring to the Internet connectivity between > the WS device and the database? If so, as above, does it necessarily > need to be an air interface? > ___ > Mancuso: This wasn't meant to imply air the exclusive interface -- > Made this clearer by using "any" air interface used by devices; > further limited reference to messages betweein devices and db as > messages from master device to db (since, by definition, slave devices > don't communicate directly to db). You missed one bit of what I was asking: Couldn't the interface between the database and the master be wired, not air at all? > Requirements: > _____ > P.1: "The master device may validate the database against a list of > approved databases maintained by a regulatory body." I don't > understand that as a protocol requirement. What is being required? > ___ > Mancuso: (Moved info up from Operation requirements per later > comment). Rephrased to clarify that the master device MUST identify a > db, and MAY discover or be pre-configured with db URIs, and MAY > validate db URIs against a list of approved databases maintained by a > regulatory body." I don't think I explained my question well enough. So let me try it this way. Here's what you currently have: P.1 The master device MUST identify a database to which it can register, make spectrum availability requests, etc. That's not the requirement. Here you're just describing what the master is going to do. So MUST isn't needed here. "will" is probably sufficient. Next comes the requirement: The master device MAY select a database by discovery at run time or by means of a pre-programmed URI address. That's fine, but it doesn't make it clear that the discovery protocol is a requirement. Shouldn't it say, "The protocol must support the discovery of an appropriate database given a location provided by the master device. The master device may select a database..."? The master device MAY validate discovered or configured database addresses against a list of approved databases maintained by a regulatory body. Here's my original confusion. I think this would be better as, "The master device may validate discovered or configured database addresses against a list of known databases (e.g., a list of databases approved by a regulatory body)." That is, the requirement (and it's not a protocol requirement) is that the master will have the ability to (optionally) do the validation against a list. Where that list comes from, e.g., a regulatory body, is not part of the requirement. > O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy > required by the database"? > _____ > Stanforth: Acceptable Location Accuracy is defined by the regulator > and applied to the calculations of the database > _____ > Resnick: So the database will tell the device what level of accuracy > is required? > _____ > Mancuso: Clarified as follows: "Locations MUST be determined to the > accuracy required by the applicable regualtory domain." These are > operational requirements, and not part of the protocol. Accuracy is > verified by certification of devices by regulators. Oh, I think that made it worse. If the regulators are determining the accuracy and certifying the devices, this is not an operational requirement; it's all going to be pre-configured. Is that what you mean? > O.4: Again, "regulatory body" seems unnecessary here. Substituting > "database" seems sufficient, since you'll be getting the rule set from > the database. > _____ > Stanforth: General observation about this and the next couple of > comments. The FCC Certifies a radio and a database as a "system" Ofcom > is not considering a system. Other regulators may have other thoughts. > In the case of the FCC some of the function is validated/certified, > what ever you want to call it for the combination not as a function of > one or the other. > So while it seems logical to have an implementation within a database > it is not necessarily considered as such. > _____ > Resnick: Again, I'm not understand your reply. Can you expand on what > you mean here? > _____ > Mancuso: The statment here is regarding the rule set, which is from > the regulator, so the current phrasing seems OK. I think we are talking past each other: How does the master device determine the rule set? Is it getting it from the database? Is it pre-configured? In any event, does the master device know that the rule set came from the regulator? If not, then there's no need to mention the regulator at all. > Note there are a significant number of device-only rule-set > requirements (complexity is to be expected), so the operational > requirement here is for the master to obtain "information." The > current expectation is that the db may communicate the name of the > applicable regulatory ruleset to the device, but not the specific > parameters. But the master device is only dealing with the name of the rule set. It doesn't have semantics to the master device. The master device DOES NOT CARE that the rule set came from a regulator, or the manufacturer, or from invaders from Mars. The concept of the regulator is irrelevant to the operational requirement. > _____ > > O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can > change "local regul8atory policy" to "the database rule set", > "determined by regulator policy" can be "enumerated in the database > rule set", etc. > ____ > Mancuso: A db can serve multiple regulatory domains, and hence, > rulesets. And note that the currently applicaple rule set may not come > from a local regulatory domain, but be imported from a foreign > regulator (e.g., Brazil decides to use FCC rules) > _____ > > Security Considerations > > Section 8, generally: Same issue with "regulatory". See if there are > any that are more accurately "database rules". > ____ > Mancuso: Again, multiple rule sets may apply for a given regulatory > domain. See above. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478
    I just posted version 11 of the PAWS Use Case &= amp; Requirements draft to IETF. In this draft, I responded to several of t= he comments posted to the list; I left a few TODOs, and am awaiting further= comments for the next draft.

    My notes are in preparing this version are set ou= t below.

    Tony Mancuso

    ***************
    Tony Mancuso Notes - PAWS Use= Case & Requirements Notes v. 11 (I consolidated Pete Resnick's ini= tial comments with other comments received on selected points together with= my responses)

    Abstract: End of the first paragraph, perhaps add: &quo= t;The IETF has undertaken to develop a protocol for that management databas= e."
    ___
    Mancuso: Done
    _____

    Also add the above to 1.1.

    1.2.1: A= re 2 & 3 combinable? "Connect to and optionally register with the = database using a well-defined protocol."
    _____
    Mancuso: Done:
    _____

    2.2: For "Devi= ce ID", it says, "that identifies the manufacturer, model number,= and serial number." Does the device ID have to identify that informat= ion? Can it simply be unique?
    ____
    Stanforth: Regulators are asking for manufacturer and m= odel number as they may require action, enforcement or denial by the DB on = the set to manufacturer devices or a specific model of device
    _____
    Resnick: I guess the question is: Are there any potential i= mplementers of this protocol (or potential regulatory bodies) that *don'= ;t* care about manufacturer or model or etc.?
    _____
    Mancuso: Waiting for further comment.
    _____
    "Devic= e Class" is only used once in section 5.1. No need for the definition = here.

    "Location Based Service" is only u= sed once in section 3. No need for the definition here.

    "Protected Entity" is only used once in secti= on 4.1. No need for the definition here.

    "Pro= tected Contour" is never used. No need for the definition at all.

    "Radio Access Technology" is only used once i= n section 5.1. No need for the definition here.
    _____
    N= ancy Bravin: I think since we are dealing with a protocol that can be used = globally, terms such as listed below, with definition, will make it easier = to those countries who are not English speaking, or the translation to word= s, with no definition can be confusing. It is not a deal breaker, but consi= deration for emerging countries that lack experience in these areas.
    _____
    Resnick: Sorry, I think I wasn't clear enough. Oth= er than "Protected Contour" (which is not used anywhere), I was n= ot suggesting having *no* definition of the terms listed. I was just saying= that if they only occur once in the document, define them inline where the= y are used instead of in the definitions section. But that's strictly a= n editorial comment. Entirely up to you all whether you want to make a chan= ge.
    _____
    Mancuso: Deleted Protected Contour, and moved the defi= nition of single-use terms into the text.
    _____

    3.1 This section (and its subsections) seems oddly placed. It is no= t use cases, but general protocol services that cut across use cases. Perha= ps 3.1 and 3.2 should be separate top-level sections?
    ---
    Mancuso: Done. Moved Protocol Services to new top-level = head (Section 3); Use Cases now in new Section 4.
    _____

    3.1 "A complete protocol solution must enable all pote= ntial white space services." That seems a bit absolute. How about &quo= t;must enable many different potential white space services"?
    ____
    Mancuso: Done.
    _____

    3.1.1 & 3.1.2: Throughout this section, there's no need to use the= term "master". These services exist whether a device is acting a= s a master for other devices or whether it is acting on its own. Given that= there's been no discussion of slave devices yet (that happens in 3.2),= I found the use of the term "master" confusing in these sections= . (I suppose you could expand the definition of master in 2.2 to explain th= at it could refer to a device acting on its own with no slaves, but I still= think that might be confusing.
    _____
    Stanforth: Broadcast use case is a master with no slav= e, at least in the context of a slave that communicates with or is controll= ed by a master.
    _____
    Resnick: So are you saying we do = or do not need the term "master" in these sections?
    _____
    Mancuso: I clarified the definition of master device: = "A device that queries a database, on its own behalf and/or on behalf = of a slave device, to obtain available spectrum information.". I think= this definition plus the definition of a slave device ("A device that= queries the database through a Master Device.") makes the use of the = term in the section appropriate -- namely, a master device is one that cont= acts a database to obtain spectrum (for itself or other devices). Slave dev= ices under these definitions, do not contact the db directly, omitting them= from the discussion at this point makes sense. Another way of saying it: w= e use the term master only as a way of describing a device used to query th= e db directly for spectrum availability. Denoting a device as master does n= ot necessarily imply the use of slaves (devices that are not used to query = the db directly) in a particular use case.
    _______________

    3.1.1, item 2: This says that= the device will discover the database "in the local regulatory domain= ". How does the device determine the "local regulatory domain&quo= t;? I suspect that the phrase "in the local regulatory domain" is= meaningless for purposes of this sentence. If it is not, there's somet= hing that's not explained.
    _____
    Stanforth: The location of a device determines it regu= latory domain. However the device may understand this or it may be told.=A0=
    _____
    Resnick: Right. That seems to indicate that the = device that this section should say, "for its current location" a= nd not "in the local regulatory domain". The device needs to know= its location, but not its regulatory domain.
    _____
    Stanforth: For instance our current US implementation = validates that a device is within the regulatory domain. If not we deny it = service but allowed for the DB to tell the device who or what it should con= tact. In other words you are now in Canada so you need to talk to xxx not t= o and FCC DB. Taken together with the comment below this may need some thou= ght and additional work.
    _____
    Resnick: I think we're on the same page.
    _____
    Mancuso: The intent of the existing wording is simply that= the master sends out a request and waits for a response, not to imply that= it the device query is constrained or qualified by the device's unders= tanding of its regulatory domain. I deleted the extra language to read as f= ollows: "The master device constructs and sends a service request over= the Internet."
    _______
    3.1.2: Similar questions regarding regulatory domain= s. For example, "2. =A0To register with the database, the master devic= e sends the database the registration information required under regulatory= rules." How does the device determine which regulatory rules it is un= der and therefore which information to send to the database. If the answer = is, "It queries the database", then it is not the regulatory rule= s the device cares about; it is the information the database is configured = to ask for (which will presumably be in accordance to some regulations, but= are out of band of any protocol work). If the answer is, "It is pre-c= onfigured in the device", then the regulatory rules are again out of b= and. Either way, mention of them would be unnecessary.
    ___
    Mancuso: Agreed. Again, I think this was simply a matter= of misphrasing. Deleted the extra language to read: "To register with= the database, the master device sends registration information to the data= base."
    _____

    3.2.1, 3.2.2, and 3.2.3, in general: Wh= en "slave device" is defined in 2.2, it's only a slave for pu= rposes of talking to the database. But there is an implication in these sec= tions that the slave device uses the master for internet connectivity. I do= n't think that's the intent, but either way there's some clarif= ication that's needed. Further confusing me about this point is (a) the= master device is always the one in the diagrams with the antenna, but as f= ar as I can tell, a master device doesn't need an antenna, the slaves d= o; and (b) most of the links marked "Air" seem to me not to requi= re an air interface, but could also be wired. I could use some explanation.=
    _____
    Stanforth
    The FCC, as an example, has two co= ncepts of a slave. The first is a client served by a master, think 802.11 c= lient using a channel served by an AP. This is the model for low power devi= ces.=A0
    _____
    Resnick: OK, but does the low power device actually ev= er request white space spectrum? If not, then it is not involved in this pr= otocol, right?
    ___
    Stanforth: If the device is a high p= ower device the slave must get it's own channel list. It can use a mast= er to do this, using white space spectrum, if it has no other means of cont= acting the database.
    ____
    Resnick: This I understood until you said "using w= hite space spectrum". It can't use white space spectrum to talk to= the master until it is allocated spectrum by the database, can it? It talk= s to the master *not* using white space spectrum, gets it's answer thro= ugh the master about which spectrum to use, and then stops talking to the m= aster, correct?
    ____
    Mancuso: Waiting for any further input.
    _____= =A0

    3.2.1, item 7: Does the slave provide its loca= tion, device identifier, and antenna height, the same way the master does w= hen it queries? If so (especially in the case of the master sub-allocating = for the slaves), doesn't the master have to provide the set of location= s for all of the slaves in step 5? Some further explanation might be in ord= er.
    _____
    Stanforth: As above a low power slave, under FCC rule,= does not have to provide any of this information but a high power slave do= es.
    _____
    Resnick: Does a low power slave talk to the d= atabase at all?
    _____
    Mancuso: Waiting for any further input.
    ____= __
    3.2.1, item 8: It says that the white space is allocated to sl= aves "for communication over the network". That's not right i= s it? In this scenario, the allocated white space could be used for network= (I read "Internet") communication *or anything else*, can't = it?
    _____
    Stanforth: High power again. A slave may not get the s= ame channel list as the master and may not be able to use the channel the m= aster is currently using so a negotiation will be necessary.
    _____
    Resnick: I'm not sure whether you agree or disagree wit= h my point here. I don't understand your reply.
    _____
    Mancuso: Waiting for any further input.
    _____

    3.2.1, item 9: Is this an important part of the scenario? Why wo= uldn't it be perfectly reasonable for communication between the master = and slaves continue on its original connection and that the white space is = only used for other communications the slave wishes to do?
    _____
    Stanforth: same as Iten 8, above.
    ____
    =
    Mancuso: TODO.
    _____

    3.2.2: This sc= enario was confusing to me because the master seems completely unnecessary = to the example. Please explain.
    _____
    Mancuso: TODO. The master is optionally used by the sl= ave to query the db for spectrum. And again, master only connotes ability t= o query the db directly by the device. I do think we need to eliminate the = implication that the slave then connects to the Internet through the master= (it uses white space spectrum, right)?
    _____

    3.2.4 and 3.2.5: Another example of the= term "master" seems unnecessary in the example, since there are = no slaves.
    ____
    Mancuso: Again, master only connotes ab= ility to query the db directly by the device.
    ____
    4: "Master" seems unnecessary to the example.= Also, I suggest in the second-to-last paragraph, you say "The databas= es are locale specific" instead of "country specific", and d= elete the word "competing" from the last sentence of that paragra= ph.
    ________
    Mancuso: Same response re masters as above. Made th= e suggested wording changes re "locale" and "competing."= ;
    _____

    4.1, item 1: Is this referring t= o the Internet connectivity between the WS device and the database? If so, = as above, does it necessarily need to be an air interface?
    ___
    Mancuso: TODO
    _____

    4= .1, item 3: Again I suggest changing "operate in any country" to = "operate in any locale" and change "country-specific" t= o "locale-specific". (The other occurrence of "country"= seems correct.)
    ____
    Mancuso: Made suggested wording changes.
    ____= _

    4.2: Instead of "regulatory-domain", w= ouldn't either "locale" or simply "domain" be suffi= cient?
    _____
    Stanforth: The regulatory domain is assumed to be simi= lar to a country domain but need not be. A database could be permitted to s= erve =A0a different definition. In the FCC case they currently limit the do= main to the 12mile nautical limit and, as we speak databases are only permi= tted to service the NE USA.
    _____
    Resnick: I don't think you answered my question.
    _____
    Mancuso: I changed to "domain specific".= Not that the db may not be locale-based (a South American country may opt = for FCC domain rules).
    _____

    5.1 and 5.2: I don't understand the= distinction between "Normative" and "Non-normative" re= quirements in this context. Isn't it sufficient that you've separat= ely labeled "Data Model Requirements", "Protocol Requirement= s", and "Operational Requirements"?
    _____
    Mancuso: Agreed. Changed the heads and organization.
    _____
    Mancuso: Remaining items TODO.
    _____
    P.1: "The master device may validate the database against a lis= t of approved databases maintained by a regulatory body." I don't = understand that as a protocol requirement. What is being required?

    P.5 and P.6: The requirement here is for *message-level= * integrity and encryption? That's OK, but I want to make sure that'= ;s what you mean.

    P.8 and P.14: I don't think = "result codes" and "response codes" are the requirement= here, are they? It sounds like the requirement is "indication of succ= ess or failure".

    P.15: I'm not clear on what this requirement means = in practical terms. Some more explanation seems in order.

    P.16: Shouldn't this be combined with P.9?

    O.2: The "required accuracy" is ambiguous. Do you mean, &quo= t;accuracy required by the database"?
    _____
    Stanfo= rth: Acceptable Location Accuracy is defined by the regulator and applied t= o the calculations of the database
    _____
    Resnick: So the database will tell the device what lev= el of accuracy is required?
    _____

    O.3: T= his seems to indicate that database discovery will be out of band, that the= WG is not developing protocol to do so. Is that what you meant? If not, th= is should be turned into a protocol requirement instead of an operational r= equirement.

    O.4: This requirement seems a bit overly obvious and si= lly to state as a requirement. Why is it necessary to say that you need a c= onnection?

    O.5: Again, "regulatory body"= seems unnecessary here. Substituting "database" seems sufficient= , since you'll be getting the rule set from the database.
    _____
    Stanforth: General observation about this and the next= couple of comments. The FCC Certifies a radio and a database as a "sy= stem" Ofcom is not considering a system. Other regulators may have oth= er thoughts. In the case of the FCC some of the function is validated/certi= fied, what ever you want to call it for the combination not as a function o= f one or the other.
    So while it seems logical to have an implementation within a database = it is not necessarily considered as such.
    _____
    Resnick= : Again, I'm not understand your reply. Can you expand on what you mean= here?
    _____

    O.6 (and O.9 through O.11 and O.13 thro= ugh O.15): As above, you can change "local regulatory policy" to = "the database rule set", "determined by regulator policy&quo= t; can be "enumerated in the database rule set", etc.

    Section 7, generally: Same issue with "regulatory&= quot;. See if there are any that are more accurately "database rules&q= uot;.

    Threat 7: This doesn't strike me as a se= curity consideration per se. This might make more sense incorporated into a= n operational requirement.




    On Thu, Jan 24, 2013 at 3:19 PM, = <Gabor.Bajko@nokia.com> wrote:

    Will wait for Tony to gen= erate a new version by addressing the received comments, before issuing the= Last Call.

    =A0<= /p>

    -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Gabor<= /span>

    =A0<= /p>

    From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Pete Resnick
    Sent: Wednesday, January 23, 2013 2:59 PM
    To: Anthony Mancuso


    Cc: paws@ietf.org=
    Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecas= es-rqmts-10

    =A0

    Like I said, I'll await word from Brian and Gabo= r tomorrow for "go" or "no go" with the Last Call, even= if there is no new draft ready to go. We can Last Call -10 if nobody think= s there's a strong reason to wait. I am fine with either path.



    pr

    On 1/23/13 4:54 PM, Anthony Mancuso wrote:

    I',m not sure I can turn around the doc by tomor= row since there are some technical points I need to collaborate on.<= u>

    =A0

    On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian <Brian.Rosen@neus= tar.biz> wrote:

    I think if Tony can spin a rev before EOB tomorrow, = we should do that, but I'm thinking that the current rev is good enough= , and I'd prefer to get it into the Feb 7 telechat. =A0

    =A0

    I don't feel very strongly about that, but=85=

    =A0

    Brian

    =A0

    On Jan 23, 2013, at 5:10 PM, Pete Resnick <presnick@qti.qualc= omm.com> wrote:

    =A0

    One hitch: If you make the call by EOB tomorrow, I c= an get the Last Call sent out, which means (assuming the LC goes well) I ca= n get it on the IESG telechat Feb 7. If we have to wait two additional week= s until the Feb 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to= the Last Call by EOB tomorrow for me to sneak it on to the earlier telecha= t.

    pr

    On 1/23/13 4:04 PM, Anthony Mancuso wrote:

    Good suggestion Gabor. I will wait another day or so= and then start on generating a new version in response to the comments and= clarifications.

    =A0

    On Wed, Jan 23, 2013 at 1:55 PM, <Gabor.Bajko@nokia.com> w= rote:

    My suggestion would be, i= f Tony has the time and willingness, then generate a new version and try to address these comments, perhaps taking the clarifications from Peter (a= nd any input from others if available until tomorrow) into consideration.

    Thanks, Gabor

    =A0



    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>

    Qualcomm Technologies, Inc. - +1 (858)651-4478

    _______________________________________________ <= /u>

    =A0

    =A0



    -- 
    Pete Resnick <http://www.qualcomm.com/~presnick/>
    Qualcomm Technologies, Inc. - +1 (858)651-4478

    --f46d043d677172d26904d420942c-- From ben@blindcreek.com Fri Jan 25 11:44:29 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AEF621F8946 for ; Fri, 25 Jan 2013 11:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.042 X-Spam-Level: X-Spam-Status: No, score=0.042 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 AUxAb+LhNEOo for ; Fri, 25 Jan 2013 11:44:28 -0800 (PST) Received: from wilson.nswebhost.com (wilson.nswebhost.com [209.217.228.59]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91B21F8700 for ; Fri, 25 Jan 2013 11:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=blindcreek.com; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=zYRGe1f2/j9iQjuzR2odBqa5AchR+wuL6X+93Fbj8b0=; b=jWXXy8TV5WG2gXBNX8yfPFNQVMAHGaU5w0lCQXZdg4LiL1G1qp1YnnCujbjYdk8UbWjxC1BZnaMZPD/O1Sn7saVCVheZZSiEPpVUfaIia+t4sfhH8Vb0op28Ok2cU2Bf; Received: from [64.74.213.174] (port=64276 helo=[192.168.250.11]) by wilson.nswebhost.com with esmtpa (Exim 4.80) (envelope-from ) id 1TypCM-0004tr-BX for paws@ietf.org; Fri, 25 Jan 2013 13:44:26 -0600 Message-ID: <5102E09C.40202@blindcreek.com> Date: Fri, 25 Jan 2013 11:44:28 -0800 From: "Benjamin A. Rolfe" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: paws@ietf.org References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wilson.nswebhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - blindcreek.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 25 Jan 2013 19:44:29 -0000 On 1/25/2013 9:51 AM, Anthony Mancuso wrote: > 3.1 "A complete protocol solution must enable all potential white > space services." That seems a bit absolute. How about "must enable > many different potential white space services"? I'd strike the entire sentence. There is no such thing as a "complete protocol". If you must have it, change it to "this protocol" and it isn't wrong (but still not adding information). From internet-drafts@ietf.org Tue Jan 29 15:09:39 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA0421F87D5; Tue, 29 Jan 2013 15:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 LQ-P7O8dXKr6; Tue, 29 Jan 2013 15:09:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A2F21F87E7; Tue, 29 Jan 2013 15:09:39 -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: <20130129230939.13273.9451.idtracker@ietfa.amsl.com> Date: Tue, 29 Jan 2013 15:09:39 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-12.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, 29 Jan 2013 23:09:40 -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-12.txt Pages : 27 Date : 2013-01-29 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 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. The IETF has undertaken to develop a Protocol to Access Spectrum Database [1] for such a management database. 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-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-rq= mts-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From amancuso@google.com Tue Jan 29 15:15:54 2013 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD7F21F8840 for ; Tue, 29 Jan 2013 15:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.291 X-Spam-Level: X-Spam-Status: No, score=-102.291 tagged_above=-999 required=5 tests=[AWL=0.458, 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 JQjmLe7xkrAt for ; Tue, 29 Jan 2013 15:15:49 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by ietfa.amsl.com (Postfix) with ESMTP id 64B6021F883C for ; Tue, 29 Jan 2013 15:15:48 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id fy7so652940vcb.18 for ; Tue, 29 Jan 2013 15:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=88jA+cnC/qA+9bsdjP8qu0oyLZSKKElIDYunA0AWKJg=; b=iDACEW0wH8LsSQkGJuSGYJLNkmO+XnefpHQXFCFB5WmyBDQVe5HJu9hxNJizxh2HIl MPhvZ/NWHT3FRyC4MD7CU1WVDW3eQ1EzwkotO8VSao5cM4Ue/RWuaCUABeG3ctnQdGbB d2/xmM/fmhAf/z5QkugrbPjKu0OGsKmgnHSLydL9o4iMYLk6ajwu0wrrrbOUmwurqnk0 eRiR7qpVJG1/7HXOHvBRo62LRIo/tSkBJYba5Tcc+LYmZYUZns+Ilbe9xAQOrQ9Yyz7v 8Fn02Z2TGsSYl/RGvz7Sv+TDK0l+6Lkg95Snf5VisVNS3rOU70kmrmP9qnfDmX/T/DwB 7voA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=88jA+cnC/qA+9bsdjP8qu0oyLZSKKElIDYunA0AWKJg=; b=IHjJPcGBHOyWzLqHtL31ODia6PMaQJrucgiagZxT/ZC6EE7LBZqIlrLVVOiHGQJMCf pSefT4mlgzDAqF5UFLlEfdJMV35NIhk4eUlqr7ZJb3/DXzfoHf2VVTJmXkhBMdNHjbtb JQ/I0u9vDD+1aE55tTitC4LVLDTh5nljC98UMuwTiibgV/2KMUwqiosr6BBz9mgp+tnC xPGUZjEu1crHXU8/0GsA7WkmJllOrWZUkYXgftRhewyzE/ofmrGjM9wkRCx/cjlWRELa ODz6kyFgR1B0B/3o+BM9+UnliFYeLKiGiCnHNj5EYleSb9JN42f6yOIkjHHBuqqbHKtx Txrg== MIME-Version: 1.0 X-Received: by 10.52.91.212 with SMTP id cg20mr2719231vdb.63.1359501347278; Tue, 29 Jan 2013 15:15:47 -0800 (PST) Received: by 10.220.182.195 with HTTP; Tue, 29 Jan 2013 15:15:47 -0800 (PST) In-Reply-To: References: <51004DFD.4030001@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E4760210062F@008-AM1MPN1-006.mgdnok.nokia.com> <51005FDA.4020300@qti.qualcomm.com> <785693F1-D60A-46B0-AA69-4CA8C8045ACB@neustar.biz> <51006B3C.8010104@qti.qualcomm.com> <1ECAFF543A2FED4EA2BEB6CACE08E47602100C61@008-AM1MPN1-006.mgdnok.nokia.com> Date: Tue, 29 Jan 2013 15:15:47 -0800 Message-ID: From: Anthony Mancuso To: Gabor Bajko Content-Type: multipart/alternative; boundary=20cf307c9deee050dd04d47592e4 X-Gm-Message-State: ALoCoQkVihzO9a77NG2UDTNnKlfTGve0yCRqAYWzLvvs5W2TQwZ71AtYDwFsGaWLJ/lbOKkp1V1hjZ5TxClCALQtlclgfzI1btOfuxOaqaFEo6fe2J1l4nQ0po359vq8Fbp+uqNIuNhxt5xutPWkAkIliGESuBQ/at26Q8j5jUvbYao7bgAjwUnKiYo4+5oswq6Y8/V4BJh7 Cc: "paws@ietf.org" , Pete Resnick Subject: Re: [paws] AD review of draft-ietf-paws-problem-stmt-usecases-rqmts-10 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, 29 Jan 2013 23:15:54 -0000 --20cf307c9deee050dd04d47592e4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable To PAWS list: Here are the collected comments on version 10 (the last posted version) of the PAWS Use Case & Requirements draft and my responses (what I did and didn't do) for version 12, which I just posted to IETF. Thanks for all the feedback! Tony Mancuso Abstract End of the first paragraph, perhaps add: "The IETF has undertaken to develop a protocol for that management database." ___ Mancuso: Done _____ Introduction Also added reference to the PAWS protocol to 1.1. 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the database using a well-defined protocol." _____ Mancuso: Done: _____ Conventions and Terminology 2.2: For "Device ID", it says, "that identifies the manufacturer, model number, and serial number." Does the device ID have to identify that information? Can it simply be unique? ____ Stanforth: Regulators are asking for manufacturer and model number as they may require action, enforcement or denial by the DB on the set to manufacturer devices or a specific model of device _____ Resnick: I guess the question is: Are there any potential implementers of this protocol (or potential regulatory bodies) that *don't* care about manufacturer or model or etc.? _____ Mancuso: Simplified to: "An identifier for each master device." _________ "Device Class" is only used once in section 5.1. No need for the definition here. "Location Based Service" is only used once in section 3. No need for the definition here. "Protected Entity" is only used once in section 4.1. No need for the definition here. "Protected Contour" is never used. No need for the definition at all. "Radio Access Technology" is only used once in section 5.1. No need for the definition here. _____ Nancy Bravin: I think since we are dealing with a protocol that can be used globally, terms such as listed below, with definition, will make it easier to those countries who are not English speaking, or the translation to words, with no definition can be confusing. It is not a deal breaker, but consideration for emerging countries that lack experience in these areas. _____ Resnick: Sorry, I think I wasn't clear enough. Other than "Protected Contour" (which is not used anywhere), I was not suggesting having *no* definition of the terms listed. I was just saying that if they only occur once in the document, define them inline where they are used instead of in the definitions section. But that's strictly an editorial comment. Entirely up to you all whether you want to make a change. _____ Mancuso: Deleted Protected Contour, and moved the definition of single-use terms into the text. _____ Protocol Services (separated out Protocol Services from Use Cases per comment below. (I renumbered the comments below to correspond to the new organization). 3. This section (and its subsections) seems oddly placed. It is not use cases, but general protocol services that cut across use cases. Perhaps 3.1 and 3.2 should be separate top-level sections? --- Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); Use Cases now in new Section 4. _____ 3. "A complete protocol solution must enable all potential white space services." That seems a bit absolute. How about "must enable many different potential white space services"? ____ Benjamin Rolfe: I'd strike the entire sentence. There is no such thing as a "complete protocol". If you must have it, change it to "this protocol" and it isn't wrong (but still not adding information). Mancuso: Rephrased to: "A protocol solution must enable many different potential white space services. ". _____ 3.1 & 3.2: Throughout this section, there's no need to use the term "master". These services exist whether a device is acting as a master for other devices or whether it is acting on its own. Given that there's been no discussion of slave devices yet (that happens in 3.2), I found the use of the term "master" confusing in these sections. (I suppose you could expand the definition of master in 2.2 to explain that it could refer to a device acting on its own with no slaves, but I still think that might be confusing. _____ Stanforth: Broadcast use case is a master with no slave, at least in the context of a slave that communicates with or is controlled by a master. _____ Resnick: So are you saying we do or do not need the term "master" in these sections? _____ Mancuso: I clarified the definition of master device: "A device that queries a database, on its own behalf and/or on behalf of a slave device, to obtain available spectrum information.". I think this definition plus the definition of a slave device ("A device that queries the database through a Master Device.") makes the use of the term in this and latter sections and illustrations appropriate -- namely, a master device is one that contacts a database to obtain spectrum (for itself or other devices). Slave devices under these definitions, do not contact the db directly, omitting them from the discussion and refering in the text or illustrations solely to a master device makes sense, and is not dependent on also referencing a slave device. Another way of saying it: we use the term master only as a way of describing a device used to query the db directly for spectrum availability. Denoting a device as master does not necessarily imply the use of slaves (devices that are not used to query the db directly) in a particular use case or illustration. _______________ 3.1, item 2: This says that the device will discover the database "in the local regulatory domain". How does the device determine the "local regulatory domain"? I suspect that the phrase "in the local regulatory domain" is meaningless for purposes of this sentence. If it is not, there's something that's not explained. _____ Stanforth: The location of a device determines it regulatory domain. However the device may understand this or it may be told. _____ Resnick: Right. That seems to indicate that the device that this section should say, "for its current location" and not "in the local regulatory domain". The device needs to know its location, but not its regulatory domain. _____ Stanforth: For instance our current US implementation validates that a device is within the regulatory domain. If not we deny it service but allowed for the DB to tell the device who or what it should contact. In other words you are now in Canada so you need to talk to xxx not to and FCC DB. Taken together with the comment below this may need some thought and additional work. _____ Resnick: I think we're on the same page. _____ Mancuso: Rewrote to clarify the difference between the discovery phase (locating a trusted database) and the initial contact with the trusted database. Also noted the different ways a device can locate the database URI (through discovery or pre-configured URIs). _______ 3.2: Similar questions regarding regulatory domains. For example, "2. To register with the database, the master device sends the database the registration information required under regulatory rules." How does the device determine which regulatory rules it is under and therefore which information to send to the database. If the answer is, "It queries the database", then it is not the regulatory rules the device cares about; it is the information the database is configured to ask for (which will presumably be in accordance to some regulations, but are out of band of any protocol work). If the answer is, "It is pre-configured in the device", then the regulatory rules are again out of band. Either way, mention of them would be unnecessary. ___ Mancuso: Agreed. I think this was simply a matter of misphrasing. Deleted the extra language to read: "To register with the database, the master device sends registration information to the database." _____ Use Cases 4.1, 4.2, and 4.3, in general: When "slave device" is defined in 2.2, it's only a slave for purposes of talking to the database. But there is an implication in these sections that the slave device uses the master for internet connectivity. I don't think that's the intent, but either way there's some clarification that's needed. Further confusing me about this point is (a) the master device is always the one in the diagrams with the antenna, but as far as I can tell, a master device doesn't need an antenna, the slaves do; and (b) most of the links marked "Air" seem to me not to require an air interface, but could also be wired. I could use some explanation. _____ Stanforth The FCC, as an example, has two concepts of a slave. The first is a client served by a master, think 802.11 client using a channel served by an AP. This is the model for low power devices. _____ Resnick: OK, but does the low power device actually ever request white space spectrum? If not, then it is not involved in this protocol, right? ___ Stanforth: If the device is a high power device the slave must get it's own channel list. It can use a master to do this, using white space spectrum, if it has no other means of contacting the database. ____ Resnick: This I understood until you said "using white space spectrum". It can't use white space spectrum to talk to the master until it is allocated spectrum by the database, can it? It talks to the master *not* using white space spectrum, gets it's answer through the master about which spectrum to use, and then stops talking to the master, correct? ____ Mancuso: Masters are defined as the device that can contact the db on its own (knows its geolocation), and the use cases I think are consistent with this definition. There is no constraint on how the slaves or masters communicate (air or wire) but the illustrations attempt to show common connections for the examples (for hotspots, WANS, etc., slave devices will connect over air to master). Also, slaves can use white space spectrum as appropriate to the local white space network being established -- to connect to the Internet through the master (or some other AP), for local communications only, or some other use of the spectrum. I deleted the extra master antenna shown in use case 5 (local tv broadcast). 4.1, item 7: Does the slave provide its location, device identifier, and antenna height, the same way the master does when it queries? If so (especially in the case of the master sub-allocating for the slaves), doesn't the master have to provide the set of locations for all of the slaves in step 5? Some further explanation might be in order. _____ Stanforth: As above a low power slave, under FCC rule, does not have to provide any of this information but a high power slave does. _____ Resnick: Does a low power slave talk to the database at all? _____ Mancuso: I moved related slave requests into the corresponding sections for the master. ______ 4.1, item 8: It says that the white space is allocated to slaves "for communication over the network". That's not right is it? In this scenario, the allocated white space could be used for network (I read "Internet") communication *or anything else*, can't it? _____ Stanforth: High power again. A slave may not get the same channel list as the master and may not be able to use the channel the master is currently using so a negotiation will be necessary. _____ Resnick: I'm not sure whether you agree or disagree with my point here. I don't understand your reply. _____ Mancuso: The network refers to the local master-slave network, not to connectivity to the Internet. I deleted "for communication over the network" for clarity. _____ 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it be perfectly reasonable for communication between the master and slaves continue on its original connection and that the white space is only used for other communications the slave wishes to do? _____ Stanforth: same as Iten 8, above. ____ Mancuso: Changed to "may occur". Technically, the "network" we are talking about here is the white space network, which only uses white space (after initial bootstrapping communications between slaves and masters). But I agree that we should recognize (implicitly) the ability of devices to use other spectrum/technologies for ongoing communications. _____ 4.2: This scenario was confusing to me because the master seems completely unnecessary to the example. Please explain. _____ Mancuso: As noted, the master is optionally used by the slave to query the db for spectrum. And again, master only connotes the device's ability to query the db directly. _____ 4.4 and 4.5: Another example of the term "master" seems unnecessary in the example, since there are no slaves. ____ Mancuso: Again, master only connotes ability to query the db directly by the device. ____ Problem Statement 5: "Master" seems unnecessary to the example. Also, I suggest in the second-to-last paragraph, you say "The databases are locale specific" instead of "country specific", and delete the word "competing" from the last sentence of that paragraph. ________ Mancuso: Same response re masters as above. Made the suggested wording changes re "locale" and "competing." _____ 5.1, item 1: Is this referring to the Internet connectivity between the WS device and the database? If so, as above, does it necessarily need to be an air interface? ___ Mancuso: This wasn't meant to imply air the exclusive interface -- Made this clearer by using "any" air interface used by devices; further limited reference to messages betweein devices and db as messages from master device to db (since, by definition, slave devices don't communicate directly to db). _____ 5.1, item 3: Again I suggest changing "operate in any country" to "operate in any locale" and change "country-specific" to "locale-specific". (The other occurrence of "country" seems correct.) ____ Mancuso: Made suggested wording changes. _____ 5.2: Instead of "regulatory-domain", wouldn't either "locale" or simply "domain" be sufficient? _____ Stanforth: The regulatory domain is assumed to be similar to a country domain but need not be. A database could be permitted to serve a different definition. In the FCC case they currently limit the domain to the 12mile nautical limit and, as we speak databases are only permitted to service the NE USA. _____ Resnick: I don't think you answered my question. _____ Mancuso: I changed to "domain specific". Not that the db may not be locale-based (a South American country may opt for FCC domain rules). _____ 5.1 and 5.2: I don't understand the distinction between "Normative" and "Non-normative" requirements in this context. Isn't it sufficient that you've separately labeled "Data Model Requirements", "Protocol Requirements", and "Operational Requirements"? _____ Mancuso: Agreed. Changed the heads and organization. Requirements: _____ P.1: "The master device may validate the database against a list of approved databases maintained by a regulatory body." I don't understand that as a protocol requirement. What is being required? ___ Mancuso: (Moved info up from Operation requirements per later comment). Rephrased to clarify that the master device MUST identify a db, and MAY discover or be pre-configured with db URIs, and MAY validate db URIs against a list of approved databases maintained by a regulatory body." P.5 and P.6: The requirement here is for *message-level* integrity and encryption? That's OK, but I want to make sure that's what you mean. ___ Rex Buddenberg: encryption gets you confidentiality (which may or may not be a requirement). It does not get you authenticity. integrity gets you bit-perfection. Which is a requirement. But integrity does not get you authenticity ... which is a requirement. I can't think of a situation where you don't need both. (In public key, a digital signature provides both authenticity and integrity, assuming you have a PKI you can rely on. ____ Mancuso: Yes, that is the intent, and yes, we want all three. DB authenticity is addressed in p4. ___ P.8 and P.14: I don't think "result codes" and "response codes" are the requirement here, are they? It sounds like the requirement is "indication of success or failure". _____ Mancuso: Rephrased to state the requirement in terms of the success or failure of the requests. _____ P.15: I'm not clear on what this requirement means in practical terms. Some more explanation seems in order. ___ Mancuso: Rephrased for clarity to: "The protocol MUST support the capability for the database to inform master devices of changes to spectrum availability information in a timely manner." P.16: Shouldn't this be combined with P.9? ___ Mancuso: Deleted P.16; this was already included under D.9. _____ O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy required by the database"? _____ Stanforth: Acceptable Location Accuracy is defined by the regulator and applied to the calculations of the database _____ Resnick: So the database will tell the device what level of accuracy is required? _____ Mancuso: Clarified as follows: "Locations MUST be determined to the accuracy required by the applicable regualtory domain." These are operational requirements, and not part of the protocol. Accuracy is verified by certification of devices by regulators. ____ O.3: This seems to indicate that database discovery will be out of band, that the WG is not developing protocol to do so. Is that what you meant? If not, this should be turned into a protocol requirement instead of an operational requirement. __ Mancuso: The master locating the DB is a requirement, so I moved this to P.1. Renumbered the remaining requirements (and comments below). ____ O.3: This requirement seems a bit overly obvious and silly to state as a requirement. Why is it necessary to say that you need a connection? ____ Mancuso: Deleted the first sentence. O.4: Again, "regulatory body" seems unnecessary here. Substituting "database" seems sufficient, since you'll be getting the rule set from the database. _____ Stanforth: General observation about this and the next couple of comments. The FCC Certifies a radio and a database as a "system" Ofcom is not considering a system. Other regulators may have other thoughts. In the case of the FCC some of the function is validated/certified, what ever you want to call it for the combination not as a function of one or the other. So while it seems logical to have an implementation within a database it is not necessarily considered as such. _____ Resnick: Again, I'm not understand your reply. Can you expand on what you mean here? _____ Mancuso: The statment here is regarding the rule set, which is from the regulator, so the current phrasing seems OK. Note there are a significant number of device-only rule-set requirements (complexity is to be expected), so the operational requirement here is for the master to obtain "information." The current expectation is that the db may communicate the name of the applicable regulatory ruleset to the device, but not the specific parameters. _____ O.5 (and O.9 through O.10 and O.12 through O.14): As above, you can change "local regul8atory policy" to "the database rule set", "determined by regulator policy" can be "enumerated in the database rule set", etc. ____ Mancuso: A db can serve multiple regulatory domains, and hence, rulesets. And note that the currently applicaple rule set may not come from a local regulatory domain, but be imported from a foreign regulator (e.g., Brazil decides to use FCC rules) _____ Security Considerations Section 8, generally: Same issue with "regulatory". See if there are any that are more accurately "database rules". ____ Mancuso: Again, multiple rule sets may apply for a given regulatory domain. Threat 7: This doesn't strike me as a security consideration per se. This might make more sense incorporated into an operational requirement. ___ Mancuso: Agreed. Moved duscussion of emergency services need for white space to new O.17 requirement, and condensed it to: "In the case of a natural disaster,emergency services may need to use distributed white space databases on short notice. The database should support any emergency regulations adopted by regulators to provide priority allocation of white space spectrum to emergency services." --- end of comments On Fri, Jan 25, 2013 at 9:51 AM, Anthony Mancuso wrote= : > I just posted version 11 of the PAWS Use Case & Requirements draft to > IETF. In this draft, I responded to several of the comments posted to the > list; I left a few TODOs, and am awaiting further comments for the next > draft. > > My notes are in preparing this version are set out below. > > Tony Mancuso > > *************** > Tony Mancuso Notes - PAWS Use Case & Requirements Notes v. 11 (I > consolidated Pete Resnick's initial comments with other comments received > on selected points together with my responses) > > Abstract: End of the first paragraph, perhaps add: "The IETF has > undertaken to develop a protocol for that management database." > ___ > Mancuso: Done > _____ > > Also add the above to 1.1. > > 1.2.1: Are 2 & 3 combinable? "Connect to and optionally register with the > database using a well-defined protocol." > _____ > Mancuso: Done: > _____ > > 2.2: For "Device ID", it says, "that identifies the manufacturer, model > number, and serial number." Does the device ID have to identify that > information? Can it simply be unique? > ____ > Stanforth: Regulators are asking for manufacturer and model number as the= y > may require action, enforcement or denial by the DB on the set to > manufacturer devices or a specific model of device > _____ > Resnick: I guess the question is: Are there any potential implementers of > this protocol (or potential regulatory bodies) that *don't* care about > manufacturer or model or etc.? > _____ > Mancuso: Waiting for further comment. > _____ > "Device Class" is only used once in section 5.1. No need for the > definition here. > > "Location Based Service" is only used once in section 3. No need for the > definition here. > > "Protected Entity" is only used once in section 4.1. No need for the > definition here. > > "Protected Contour" is never used. No need for the definition at all. > > "Radio Access Technology" is only used once in section 5.1. No need for > the definition here. > _____ > Nancy Bravin: I think since we are dealing with a protocol that can be > used globally, terms such as listed below, with definition, will make it > easier to those countries who are not English speaking, or the translatio= n > to words, with no definition can be confusing. It is not a deal breaker, > but consideration for emerging countries that lack experience in these > areas. > _____ > Resnick: Sorry, I think I wasn't clear enough. Other than "Protected > Contour" (which is not used anywhere), I was not suggesting having *no* > definition of the terms listed. I was just saying that if they only occur > once in the document, define them inline where they are used instead of i= n > the definitions section. But that's strictly an editorial comment. Entire= ly > up to you all whether you want to make a change. > _____ > Mancuso: Deleted Protected Contour, and moved the definition of single-us= e > terms into the text. > _____ > > 3.1 This section (and its subsections) seems oddly placed. It is not use > cases, but general protocol services that cut across use cases. Perhaps 3= .1 > and 3.2 should be separate top-level sections? > --- > Mancuso: Done. Moved Protocol Services to new top-level head (Section 3); > Use Cases now in new Section 4. > _____ > > 3.1 "A complete protocol solution must enable all potential white space > services." That seems a bit absolute. How about "must enable many differe= nt > potential white space services"? > ____ > Mancuso: Done. > _____ > > 3.1.1 & 3.1.2: Throughout this section, there's no need to use the term > "master". These services exist whether a device is acting as a master for > other devices or whether it is acting on its own. Given that there's been > no discussion of slave devices yet (that happens in 3.2), I found the use > of the term "master" confusing in these sections. (I suppose you could > expand the definition of master in 2.2 to explain that it could refer to = a > device acting on its own with no slaves, but I still think that might be > confusing. > _____ > Stanforth: Broadcast use case is a master with no slave, at least in the > context of a slave that communicates with or is controlled by a master. > _____ > Resnick: So are you saying we do or do not need the term "master" in thes= e > sections? > _____ > Mancuso: I clarified the definition of master device: "A device that > queries a database, on its own behalf and/or on behalf of a slave device, > to obtain available spectrum information.". I think this definition plus > the definition of a slave device ("A device that queries the database > through a Master Device.") makes the use of the term in the section > appropriate -- namely, a master device is one that contacts a database to > obtain spectrum (for itself or other devices). Slave devices under these > definitions, do not contact the db directly, omitting them from the > discussion at this point makes sense. Another way of saying it: we use th= e > term master only as a way of describing a device used to query the db > directly for spectrum availability. Denoting a device as master does not > necessarily imply the use of slaves (devices that are not used to query t= he > db directly) in a particular use case. > _______________ > > 3.1.1, item 2: This says that the device will discover the database "in > the local regulatory domain". How does the device determine the "local > regulatory domain"? I suspect that the phrase "in the local regulatory > domain" is meaningless for purposes of this sentence. If it is not, there= 's > something that's not explained. > _____ > Stanforth: The location of a device determines it regulatory domain. > However the device may understand this or it may be told. > _____ > Resnick: Right. That seems to indicate that the device that this section > should say, "for its current location" and not "in the local regulatory > domain". The device needs to know its location, but not its regulatory > domain. > _____ > Stanforth: For instance our current US implementation validates that a > device is within the regulatory domain. If not we deny it service but > allowed for the DB to tell the device who or what it should contact. In > other words you are now in Canada so you need to talk to xxx not to and F= CC > DB. Taken together with the comment below this may need some thought and > additional work. > _____ > Resnick: I think we're on the same page. > _____ > Mancuso: The intent of the existing wording is simply that the master > sends out a request and waits for a response, not to imply that it the > device query is constrained or qualified by the device's understanding of > its regulatory domain. I deleted the extra language to read as follows: > "The master device constructs and sends a service request over the > Internet." > _______ > 3.1.2: Similar questions regarding regulatory domains. For example, "2. > To register with the database, the master device sends the database the > registration information required under regulatory rules." How does the > device determine which regulatory rules it is under and therefore which > information to send to the database. If the answer is, "It queries the > database", then it is not the regulatory rules the device cares about; it > is the information the database is configured to ask for (which will > presumably be in accordance to some regulations, but are out of band of a= ny > protocol work). If the answer is, "It is pre-configured in the device", > then the regulatory rules are again out of band. Either way, mention of > them would be unnecessary. > ___ > Mancuso: Agreed. Again, I think this was simply a matter of misphrasing. > Deleted the extra language to read: "To register with the database, the > master device sends registration information to the database." > _____ > > 3.2.1, 3.2.2, and 3.2.3, in general: When "slave device" is defined in > 2.2, it's only a slave for purposes of talking to the database. But there > is an implication in these sections that the slave device uses the master > for internet connectivity. I don't think that's the intent, but either wa= y > there's some clarification that's needed. Further confusing me about this > point is (a) the master device is always the one in the diagrams with the > antenna, but as far as I can tell, a master device doesn't need an antenn= a, > the slaves do; and (b) most of the links marked "Air" seem to me not to > require an air interface, but could also be wired. I could use some > explanation. > _____ > Stanforth > The FCC, as an example, has two concepts of a slave. The first is a clien= t > served by a master, think 802.11 client using a channel served by an AP. > This is the model for low power devices. > _____ > Resnick: OK, but does the low power device actually ever request white > space spectrum? If not, then it is not involved in this protocol, right? > ___ > Stanforth: If the device is a high power device the slave must get it's > own channel list. It can use a master to do this, using white space > spectrum, if it has no other means of contacting the database. > ____ > Resnick: This I understood until you said "using white space spectrum". I= t > can't use white space spectrum to talk to the master until it is allocate= d > spectrum by the database, can it? It talks to the master *not* using whit= e > space spectrum, gets it's answer through the master about which spectrum = to > use, and then stops talking to the master, correct? > ____ > Mancuso: Waiting for any further input. > _____ > > 3.2.1, item 7: Does the slave provide its location, device identifier, an= d > antenna height, the same way the master does when it queries? If so > (especially in the case of the master sub-allocating for the slaves), > doesn't the master have to provide the set of locations for all of the > slaves in step 5? Some further explanation might be in order. > _____ > Stanforth: As above a low power slave, under FCC rule, does not have to > provide any of this information but a high power slave does. > _____ > Resnick: Does a low power slave talk to the database at all? > _____ > Mancuso: Waiting for any further input. > ______ > 3.2.1, item 8: It says that the white space is allocated to slaves "for > communication over the network". That's not right is it? In this scenario= , > the allocated white space could be used for network (I read "Internet") > communication *or anything else*, can't it? > _____ > Stanforth: High power again. A slave may not get the same channel list as > the master and may not be able to use the channel the master is currently > using so a negotiation will be necessary. > _____ > Resnick: I'm not sure whether you agree or disagree with my point here. I > don't understand your reply. > _____ > Mancuso: Waiting for any further input. > _____ > > 3.2.1, item 9: Is this an important part of the scenario? Why wouldn't it > be perfectly reasonable for communication between the master and slaves > continue on its original connection and that the white space is only used > for other communications the slave wishes to do? > _____ > Stanforth: same as Iten 8, above. > ____ > Mancuso: TODO. > _____ > > 3.2.2: This scenario was confusing to me because the master seems > completely unnecessary to the example. Please explain. > _____ > Mancuso: TODO. The master is optionally used by the slave to query the db > for spectrum. And again, master only connotes ability to query the db > directly by the device. I do think we need to eliminate the implication > that the slave then connects to the Internet through the master (it uses > white space spectrum, right)? > _____ > > 3.2.4 and 3.2.5: Another example of the term "master" seems unnecessary i= n > the example, since there are no slaves. > ____ > Mancuso: Again, master only connotes ability to query the db directly by > the device. > ____ > 4: "Master" seems unnecessary to the example. Also, I suggest in the > second-to-last paragraph, you say "The databases are locale specific" > instead of "country specific", and delete the word "competing" from the > last sentence of that paragraph. > ________ > Mancuso: Same response re masters as above. Made the suggested wording > changes re "locale" and "competing." > _____ > > 4.1, item 1: Is this referring to the Internet connectivity between the W= S > device and the database? If so, as above, does it necessarily need to be = an > air interface? > ___ > Mancuso: TODO > _____ > > 4.1, item 3: Again I suggest changing "operate in any country" to "operat= e > in any locale" and change "country-specific" to "locale-specific". (The > other occurrence of "country" seems correct.) > ____ > Mancuso: Made suggested wording changes. > _____ > > 4.2: Instead of "regulatory-domain", wouldn't either "locale" or simply > "domain" be sufficient? > _____ > Stanforth: The regulatory domain is assumed to be similar to a country > domain but need not be. A database could be permitted to serve a differe= nt > definition. In the FCC case they currently limit the domain to the 12mile > nautical limit and, as we speak databases are only permitted to service t= he > NE USA. > _____ > Resnick: I don't think you answered my question. > _____ > Mancuso: I changed to "domain specific". Not that the db may not be > locale-based (a South American country may opt for FCC domain rules). > _____ > > 5.1 and 5.2: I don't understand the distinction between "Normative" and > "Non-normative" requirements in this context. Isn't it sufficient that > you've separately labeled "Data Model Requirements", "Protocol > Requirements", and "Operational Requirements"? > _____ > Mancuso: Agreed. Changed the heads and organization. > _____ > Mancuso: Remaining items TODO. > _____ > P.1: "The master device may validate the database against a list of > approved databases maintained by a regulatory body." I don't understand > that as a protocol requirement. What is being required? > > P.5 and P.6: The requirement here is for *message-level* integrity and > encryption? That's OK, but I want to make sure that's what you mean. > > P.8 and P.14: I don't think "result codes" and "response codes" are the > requirement here, are they? It sounds like the requirement is "indication > of success or failure". > > P.15: I'm not clear on what this requirement means in practical terms. > Some more explanation seems in order. > > P.16: Shouldn't this be combined with P.9? > > O.2: The "required accuracy" is ambiguous. Do you mean, "accuracy require= d > by the database"? > _____ > Stanforth: Acceptable Location Accuracy is defined by the regulator and > applied to the calculations of the database > _____ > Resnick: So the database will tell the device what level of accuracy is > required? > _____ > > O.3: This seems to indicate that database discovery will be out of band, > that the WG is not developing protocol to do so. Is that what you meant? = If > not, this should be turned into a protocol requirement instead of an > operational requirement. > > O.4: This requirement seems a bit overly obvious and silly to state as a > requirement. Why is it necessary to say that you need a connection? > > O.5: Again, "regulatory body" seems unnecessary here. Substituting > "database" seems sufficient, since you'll be getting the rule set from th= e > database. > _____ > Stanforth: General observation about this and the next couple of comments= . > The FCC Certifies a radio and a database as a "system" Ofcom is not > considering a system. Other regulators may have other thoughts. In the ca= se > of the FCC some of the function is validated/certified, what ever you wan= t > to call it for the combination not as a function of one or the other. > So while it seems logical to have an implementation within a database it > is not necessarily considered as such. > _____ > Resnick: Again, I'm not understand your reply. Can you expand on what you > mean here? > _____ > > O.6 (and O.9 through O.11 and O.13 through O.15): As above, you can chang= e > "local regulatory policy" to "the database rule set", "determined by > regulator policy" can be "enumerated in the database rule set", etc. > > Section 7, generally: Same issue with "regulatory". See if there are any > that are more accurately "database rules". > > Threat 7: This doesn't strike me as a security consideration per se. This > might make more sense incorporated into an operational requirement. > > > > > On Thu, Jan 24, 2013 at 3:19 PM, wrote: > >> Will wait for Tony to generate a new version by addressing the received >> comments, before issuing the Last Call.**** >> >> ** ** >> >> **- **Gabor**** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf >> Of *ext Pete Resnick >> *Sent:* Wednesday, January 23, 2013 2:59 PM >> *To:* Anthony Mancuso >> >> *Cc:* paws@ietf.org >> *Subject:* Re: [paws] AD review of >> draft-ietf-paws-problem-stmt-usecases-rqmts-10**** >> >> ** ** >> >> Like I said, I'll await word from Brian and Gabor tomorrow for "go" or >> "no go" with the Last Call, even if there is no new draft ready to go. W= e >> can Last Call -10 if nobody thinks there's a strong reason to wait. I am >> fine with either path. >> >> >> pr >> >> On 1/23/13 4:54 PM, Anthony Mancuso wrote: **** >> >> I',m not sure I can turn around the doc by tomorrow since there are >> some technical points I need to collaborate on.**** >> >> ** ** >> >> On Wed, Jan 23, 2013 at 2:19 PM, Rosen, Brian >> wrote:**** >> >> I think if Tony can spin a rev before EOB tomorrow, we should do that, >> but I'm thinking that the current rev is good enough, and I'd prefer to = get >> it into the Feb 7 telechat. **** >> >> ** ** >> >> I don't feel very strongly about that, but=85**** >> >> ** ** >> >> Brian**** >> >> ** ** >> >> On Jan 23, 2013, at 5:10 PM, Pete Resnick >> wrote:**** >> >> ** ** >> >> One hitch: If you make the call by EOB tomorrow, I can get the Last >> Call sent out, which means (assuming the LC goes well) I can get it on t= he >> IESG telechat Feb 7. If we have to wait two additional weeks until the F= eb >> 14 telechat, it's not a huge deal, but we have to say "go" or "no go" to >> the Last Call by EOB tomorrow for me to sneak it on to the earlier telec= hat. >> >> pr >> >> On 1/23/13 4:04 PM, Anthony Mancuso wrote: **** >> >> Good suggestion Gabor. I will wait another day or so and then start on >> generating a new version in response to the comments and clarifications.= * >> *** >> >> ** ** >> >> On Wed, Jan 23, 2013 at 1:55 PM, wrote:**** >> >> My suggestion would be, if Tony has the time and willingness, then >> generate a new version and try to address these comments, perhaps taking >> the clarifications from Peter (and any input from others if available un= til >> tomorrow) into consideration. **** >> >> Thanks, Gabor**** >> >> ** ** >> >> >> >> **** >> >> -- **** >> >> Pete Resnick **** >> >> Qualcomm Technologies, Inc. - +1 (858)651-4478**** >> >> _______________________________________________ **** >> >> >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws**** >> >> ** ** >> >> ** ** >> >> >> >> **** >> >> -- **** >> >> Pete Resnick **** >> >> Qualcomm Technologies, Inc. - +1 (858)651-4478**** >> >> > --20cf307c9deee050dd04d47592e4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
    To PAWS list:

    Here are the c= ollected comments on version 10 (the last posted version) of the PAWS Use C= ase & Requirements draft and my responses (what I did and didn't do= ) for version 12, which I just posted to IETF.

    Thanks for all the feedback!

    T= ony Mancuso

    Abstract

    End = of the first paragraph, perhaps add: "The IETF has undertaken to devel= op a protocol for that management database."
    ___
    Mancuso: Done
    _____

    I= ntroduction

    Also added reference to the PAWS proto= col to 1.1.

    1.2.1: Are 2 & 3 combinable? "= ;Connect to and optionally register with the database using a well-defined = protocol."
    _____
    Mancuso: Done:
    _____

    Conventions and Terminology

    2.2: For "Devic= e ID", it says, "that identifies the manufacturer, model number, = and serial number." Does the device ID have to identify that informati= on? Can it simply be unique?
    ____
    Stanforth: Regulators are asking for manufacturer and m= odel number as they may require action, enforcement or denial by the DB on = the set to manufacturer devices or a specific model of device
    _____
    Resnick: I guess the question is: Are there any potential i= mplementers of this protocol (or potential regulatory bodies) that *don'= ;t* care about manufacturer or model or etc.?
    _____
    Mancuso: Simplified to: =A0"An identifier for each master device."= ;=A0
    _________

    "Device Class" = is only used once in section 5.1. No need for the definition here.

    "Location Based Service" is only used once in sect= ion 3. No need for the definition here.

    "Prot= ected Entity" is only used once in section 4.1. No need for the defini= tion here.

    "Protected Contour" is never used. No need fo= r the definition at all.

    "Radio Access Techno= logy" is only used once in section 5.1. No need for the definition her= e.
    _____
    Nancy Bravin: I think since we are dealing with a prot= ocol that can be used globally, terms such as listed below, with definition= , will make it easier to those countries who are not English speaking, or t= he translation to words, with no definition can be confusing. It is not a d= eal breaker, but consideration for emerging countries that lack experience = in these areas.
    _____
    Resnick: Sorry, I think I wasn't clear enough. Oth= er than "Protected Contour" (which is not used anywhere), I was n= ot suggesting having *no* definition of the terms listed. I was just saying= that if they only occur once in the document, define them inline where the= y are used instead of in the definitions section. But that's strictly a= n editorial comment. Entirely up to you all whether you want to make a chan= ge.
    _____
    Mancuso: Deleted Protected Contour, and moved the defi= nition of single-use terms into the text.
    _____

    Protocol Services (separated out Protocol Services from Use Cases p= er comment below. (I renumbered the comments below to correspond to the new= organization).

    3. This section (and its subsections) seems oddly place= d. It is not use cases, but general protocol services that cut across use c= ases. Perhaps 3.1 and 3.2 should be separate top-level sections?
    ---
    Mancuso: Done. Moved Protocol Services to new top-level head = (Section 3); Use Cases now in new Section 4.
    _____

    =
    3. "A complete protocol solution must enable all potential = white space services." That seems a bit absolute. How about "must= enable many different potential white space services"?
    ____

    Benjamin Rolfe: I'd strike the entir= e sentence. There is no such thing as a "complete protocol". =A0 = If you must have it, change it to "this protocol" and it isn'= t wrong (but still not adding information).

    Mancuso: Rephrased to: "A protocol solution must e= nable many different potential white space services. ".
    ____= _

    3.1 & 3.2: Throughout this section, there= 9;s no need to use the term "master". These services exist whethe= r a device is acting as a master for other devices or whether it is acting = on its own. Given that there's been no discussion of slave devices yet = (that happens in 3.2), I found the use of the term "master" confu= sing in these sections. (I suppose you could expand the definition of maste= r in 2.2 to explain that it could refer to a device acting on its own with = no slaves, but I still think that might be confusing.
    _____
    Stanforth: Broadcast use case is a master with no slav= e, at least in the context of a slave that communicates with or is controll= ed by a master.
    _____
    Resnick: So are you saying we do = or do not need the term "master" in these sections?
    _____
    Mancuso: I clarified the definition of master device: = "A device that queries a database, on its own behalf and/or on behalf = of a slave device, to obtain available spectrum information.". I think= this definition plus the definition of a slave device ("A device that= queries the database through a Master Device.") makes the use of the = term in this and latter sections and illustrations appropriate -- namely, a= master device is one that contacts a database to obtain spectrum (for itse= lf or other devices). Slave devices under these definitions, do not contact= the db directly, omitting them from the discussion and refering in the tex= t or illustrations solely to a master device makes sense, and is not depend= ent on also referencing a slave device. Another way of saying it: we use th= e term master only as a way of describing a device used to query the db dir= ectly for spectrum availability. Denoting a device as master does not neces= sarily imply the use of slaves (devices that are not used to query the db d= irectly) in a particular use case or illustration.
    _______________

    3.1, item 2: This says that t= he device will discover the database "in the local regulatory domain&q= uot;. How does the device determine the "local regulatory domain"= ? I suspect that the phrase "in the local regulatory domain" is m= eaningless for purposes of this sentence. If it is not, there's somethi= ng that's not explained.
    _____
    Stanforth: The location of a device determines it regu= latory domain. However the device may understand this or it may be told.=A0=
    _____
    Resnick: Right. That seems to indicate that the = device that this section should say, "for its current location" a= nd not "in the local regulatory domain". The device needs to know= its location, but not its regulatory domain.
    _____
    Stanforth: For instance our current US implementation = validates that a device is within the regulatory domain. If not we deny it = service but allowed for the DB to tell the device who or what it should con= tact. In other words you are now in Canada so you need to talk to xxx not t= o and FCC DB. Taken together with the comment below this may need some thou= ght and additional work.
    _____
    Resnick: I think we're on the same page.
    _____
    Mancuso: Rewrote to clarify the difference between the dis= covery phase (locating a trusted database) and the initial contact with the= trusted database. Also noted the different ways a device can locate the da= tabase URI (through discovery or pre-configured URIs).
    _______
    3.2: Similar questions regarding regulatory domains.= For example, "2. =A0To register with the database, the master device = sends the database the registration information required under regulatory r= ules." How does the device determine which regulatory rules it is unde= r and therefore which information to send to the database. If the answer is= , "It queries the database", then it is not the regulatory rules = the device cares about; it is the information the database is configured to= ask for (which will presumably be in accordance to some regulations, but a= re out of band of any protocol work). If the answer is, "It is pre-con= figured in the device", then the regulatory rules are again out of ban= d. Either way, mention of them would be unnecessary.
    ___
    Mancuso: Agreed. I think this was simply a matter of mis= phrasing. Deleted the extra language to read: "To register with the da= tabase, the master device sends registration information to the database.&q= uot;
    _____

    Use Cases

    4.1,= 4.2, and 4.3, in general: When "slave device" is defined in 2.2,= it's only a slave for purposes of talking to the database. But there i= s an implication in these sections that the slave device uses the master fo= r internet connectivity. I don't think that's the intent, but eithe= r way there's some clarification that's needed. Further confusing m= e about this point is (a) the master device is always the one in the diagra= ms with the antenna, but as far as I can tell, a master device doesn't = need an antenna, the slaves do; and (b) most of the links marked "Air&= quot; seem to me not to require an air interface, but could also be wired. = I could use some explanation.
    _____
    Stanforth
    The FCC, as an example, has two co= ncepts of a slave. The first is a client served by a master, think 802.11 c= lient using a channel served by an AP. This is the model for low power devi= ces.=A0
    _____
    Resnick: OK, but does the low power device actually ev= er request white space spectrum? If not, then it is not involved in this pr= otocol, right?
    ___
    Stanforth: If the device is a high p= ower device the slave must get it's own channel list. It can use a mast= er to do this, using white space spectrum, if it has no other means of cont= acting the database.
    ____
    Resnick: This I understood until you said "using w= hite space spectrum". It can't use white space spectrum to talk to= the master until it is allocated spectrum by the database, can it? It talk= s to the master *not* using white space spectrum, gets it's answer thro= ugh the master about which spectrum to use, and then stops talking to the m= aster, correct?
    ____
    Mancuso: Masters are defined as the device that can con= tact the db on its own (knows its geolocation), and the use cases I think a= re consistent with this definition. There is no constraint on how the slave= s or masters communicate (air or wire) but the illustrations attempt to sho= w common connections for the examples (for hotspots, WANS, etc., slave devi= ces will connect over air to master). Also, slaves can use white space spec= trum as appropriate to the local white space network being established -- t= o connect to the Internet through the master (or some other AP), for local = communications only, or some other use of the spectrum. I deleted the extra= master antenna shown in use case 5 (local tv broadcast).

    4.1, item 7: Does the slave provide its location, devic= e identifier, and antenna height, the same way the master does when it quer= ies? If so (especially in the case of the master sub-allocating for the sla= ves), doesn't the master have to provide the set of locations for all o= f the slaves in step 5? Some further explanation might be in order.
    _____
    Stanforth: As above a low power slave, under FCC rule,= does not have to provide any of this information but a high power slave do= es.
    _____
    Resnick: Does a low power slave talk to the d= atabase at all?
    _____
    Mancuso: I moved related slave requests into the corre= sponding sections for the master.
    ______
    4.1, item 8: I= t says that the white space is allocated to slaves "for communication = over the network". That's not right is it? In this scenario, the a= llocated white space could be used for network (I read "Internet"= ) communication *or anything else*, can't it?
    _____
    Stanforth: High power again. A slave may not get the s= ame channel list as the master and may not be able to use the channel the m= aster is currently using so a negotiation will be necessary.
    _____
    Resnick: I'm not sure whether you agree or disagree wit= h my point here. I don't understand your reply.
    _____
    Mancuso: The network refers to the local master-slave network, not to co= nnectivity to the Internet. I deleted "for communication over the netw= ork" for clarity.
    _____

    3.2.1, item 9: Is this an important par= t of the scenario? Why wouldn't it be perfectly reasonable for communic= ation between the master and slaves continue on its original connection and= that the white space is only used for other communications the slave wishe= s to do?
    _____
    Stanforth: same as Iten 8, above.
    ____
    =
    Mancuso: Changed to "may occur". Technically, the "netw= ork" we are talking about here is the white space network, which only = uses white space (after initial bootstrapping communications between slaves= and masters). But I agree that we should recognize (implicitly) the abilit= y of devices to use other spectrum/technologies for ongoing communications.=
    _____

    4.2: This scenario was confusing to me = because the master seems completely unnecessary to the example. Please expl= ain.
    _____
    Mancuso: As noted, the master is optionally = used by the slave to query the db for spectrum. And again, master only conn= otes the device's ability to query the db directly.
    _____

    4.4 and 4.5: Another example of the ter= m "master" seems unnecessary in the example, since there are no s= laves.
    ____
    Mancuso: Again, master only connotes abilit= y to query the db directly by the device.
    ____

    Problem Statement

    5: "Master" seems unnecessary to the example. Also, I suggest = in the second-to-last paragraph, you say "The databases are locale spe= cific" instead of "country specific", and delete the word &q= uot;competing" from the last sentence of that paragraph.