Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

From: [email-masked]
Date: Fri, 21 Dec 2012 09:10:51 -0800

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/

---

From: Nancy Bravin <[email-masked]>
Date: Fri, 21 Dec 2012 09:58:12 -0800

HI Gabor,

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

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

Nancy

Begin forwarded message:

> From: [email-masked]
> Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
> Date: December 21, 2012 9:10:51 AM PST
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Anthony Mancuso <[email-masked]>
Date: Fri, 21 Dec 2012 10:39:20 -0800

PAWS list members,

I just submitted a new version of the PAWS Use Cases & Requirements doc for
review and discussion.

The latest draft (v. 09):

   - incorporates the suggestions contained in the post by Pete Resnick,
   AD, which included, among other things, recommendation to coordinate
   architecturally-and protocol-common use cases
   - adds a new use case (local TV broadcast)
   - Deleted security threat 5 and added language to security
   considerations to match the protocol security considerations that have
   evolved in the WG
   - Clarified protocol normative requirement 6.3 to: "The protocol MUST
   support determination of regulatory domain governing its current location."
   - Cleaned up language and usage:
   consistent use of primary, secondary users
   changed "channel" availability references to "spectrum" availability
   where appropriate
   deleted references specific to TV band and generalized these to radio
   spectrum
   changed references to regulatory domain to rule set of regulatory domain
   as appropriate to clarify that the latter controls device behavior
   regardless of country (Brazil adopts US "FccWhitespace2010" rule set)
   cleaned up language and syntax throughout

Thanks for any feedback,

Tony Mancuso

On Fri, Dec 21, 2012 at 9:58 AM, Nancy Bravin <[email-masked]> wrote:

> HI Gabor,
>
> I do not understand when doing a global standard, and only referring to
> underserved areas, which is more common in developed countries,
> why use cases are left out for not only rural, but remote, which happens
> to involve many countries that can or do not relate to underserved,
> The constant use of the term wifi, and no other technology or use cases
> left out seems to promote one technology over others.
> Combining use cases as was done is not in the best interests of the
> market, their choices of what to use, or a global effort in demographics,
> whether population, terrain, or different regs that apply or options that
> other countries can use to determine what is the best course for their
> sovereign nation.
>
> *From: [email-masked]
> *Subject: **[paws] I-D Action:
> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt*
> *Date: *December 21, 2012 9:10:51 AM PST
> *To: [email-masked]
> *Cc: [email-masked]
>
>

---

From: Nancy Bravin <[email-masked]>
Date: Sat, 22 Dec 2012 10:23:15 -0800

Thank you Anthony for your insight off line as to my concerns. I apologize for my comments, and feel more comfortable that
my concerns have been managed well in the current draft. 

Sincerely, 
Nancy Bravin