Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-15

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    paws mailing list <paws@ietf.org>,
    paws chair <paws-chairs@tools.ietf.org>
Subject: Document Action: 'Protocol to Access White Space (PAWS) Database: Use Cases and Requirements' to Informational RFC (draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt)

The IESG has approved the following document:
- 'Protocol to Access White Space (PAWS) Database: Use Cases and
   Requirements'
  (draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt) as Informational
RFC

This document is the product of the Protocol to Access WS database
Working Group.

The IESG contact persons are Pete Resnick and Barry Leiba.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/

Ballot Text

Technical Summary

   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.  This document
   includes the problem statement for the development of a protocol to
   access a database of whitespace information followed by use cases and
   requirements for that protocol.  Finally, requirements associated
   with the protocol are presented.

Working Group Summary

   This document went through significant change during the WG process.
   Early in the WG process, there were disagreements on what the rules
   mean and what requirements should be derived from them. Those
   disagreements were resolved and the document was submitted to the
   IESG for publication. At that time, many issues were raised during AD
   Review. Unfortunately, at about the same time, the original authors
   (Probasco and Patil) changed employment and were unable to continue
   as document editors. A new editor was found and a few rounds of
   changes were undertaken. Discussion took place between the AD and the
   WG, resulting in the draft that got Last Called. Last Call comments
   required several changes, and those issues have also been addressed.
   The WG has consensus on the present document.

Document Quality

   This document specifies only requirements, not the protocol, so
   implementations are n/a. The document was reviewed by people who are
   familiar with the regulatory rules in the white-space area. Select
   IEEE 802 groups were notified of the existence of this draft and the
   Last Call.

Personnel

   Document Shepherd is Gabor Bajko. Responsible AD is Pete Resnick.

RFC Editor Notes

Section 4.1:
OLD
   Common steps may occur in master-slave networks include the
NEW
   Common steps that may occur in master-slave networks include the

Section 4.3:
OLD
   Once the bridged device (WS + Wi-Fi) is connected to a master and WS
NEW
   Once the bridged device (Slave Bridge + Wi-Fi) is connected to a master and WS


OLD
   1.  A bridged slave device (WS + Wi-Fi) is connected to a master
NEW
   1.  A bridged slave device (Slave Bridge + Wi-Fi) is connected to a master

Author's Addresses:
(Note: If you have some way to confirm contact information for all authors, please do.)
OLD
  Basavaraj Patil
NEW
  Basavaraj Patil
  Cisco Systems

RFC Editor Note