On Tue, 2011-04-19 at 12:47 -0700, Paul Lambert wrote: > > How does the area that the group is assigned impact the choices of > technology? > > I'm an advocate for an efficient solution set for PAWS ... it will be > much like DNS for spectrum in the future and should be viewed as a > core infrastructural component that needs careful design. There are > good reasons that routing protocols don't use XML. While the DNS analogy works, I was thinking more a parallel -- or extension -- of SNMP. Still remain within 'applications', Joel? > > Applications now days tend to go for the simple, quick to make a web > application solutions using XML or the like ... My concern is that > "Applications" imply that efficiency does not matter. > > Paul > > > > > -----Original Message----- > > From: paws-bounces@xxxxxxxx [mailto:paws-bounces@xxxxxxxx] On Behalf Of > > Joel M. Halpern > > Sent: Tuesday, April 19, 2011 10:50 AM > > To: iesg@xxxxxxxx > > Cc: paws@xxxxxxxx; IETF discussion list > > Subject: Re: [paws] WG Review: Protocol to Access White Space database > > (paws) > > > > I think this working group is a good idea. > > My inclination would be to place it in the Applications area. It looks > > like a nice application protocol to me. > > There is a reasonable argument for placing it in RAI, as that is where > > the relevant GEOLOC work has been done up till now. > > > > Yours, > > Joel M. Halpern > > > > On 4/19/2011 12:56 PM, IESG Secretary wrote: > > > A new IETF working group has been proposed. The IESG has not made > > any > > > determination as yet. The following draft charter was submitted, and > > is > > > provided for informational purposes only. Please send your comments > > to the > > > IESG mailing list (iesg@xxxxxxxx) by Tuesday, April 26, 2011. > > > > > > > > > Protocol to Access White Space database (paws) > > > ------------------------------------------------ > > > Current Status: Proposed Working Group > > > Last updated: 2011-04-14 > > > > > > Chairs: > > > TBD > > > > > > Area Directors: > > > TBD > > > > > > Area Advisor: > > > TBD > > > > > > Mailing lists: > > > Address: paws@xxxxxxxx > > > To Subscribe: https://www.ietf.org/mailman/listinfo/paws > > > Archive: http://www.ietf.org/mail-archive/web/paws/ > > > > > > Description of Working Group: > > > > > > Governments around the world continue to search for new pieces of > > radio > > > spectrum which can be used by the expanding wireless communications > > > industry to provide more services in the usable spectrum. The concept > > > of allowing secondary transmissions (licensed or unlicensed) in > > > frequencies allocated to a primary user is a technique to "unlock" > > > existing spectrum for new use. An obvious requirement is that these > > > secondary transmissions do not interfere with the primary use of the > > > spectrum. Often, in a given physical location, the primary user(s) > > may > > > not be using the entire band allocated to them. The available > > spectrum > > > for a secondary use would then depend on the location of the > > secondary > > > user. The primary user may have a schedule when it uses the spectrum, > > > which may be available for secondary use outside that schedule. The > > > fundamental issue is how to determine for a specific location and > > > specific time, if any of the primary spectrum is available for > > secondary > > > use. One simple mechanism is to use a geospatial database that > > records > > > protected contours for primary users, and require the secondary users > > to > > > check the database prior to selecting what part of the spectrum they > > > use. Such databases could be available on the Internet for query by > > > users. > > > > > > In a typical implementation of geolocation and database to access TV > > > white space, a radio is configured with, or has the capability to > > > determine its location in latitude and longitude. At power-on, before > > > the device can transmit or use any of the spectrum set aside for > > > secondary use, the device must identify the relevant database to > > query, > > > contact the database, provide its geolocation and receive in return a > > > list of unoccupied or "white space" spectrum (for example, in a TV > > > White space implementation, the list of available channels at that > > > location). The device can then select one of the channels from the > > list > > > and begin to transmit and receive on the selected channel. The device > > > must query the database subsequently on a periodic basis for a list > > of > > > unoccupied channels based on certain conditions, e.g. a fixed amount > > of > > > time has passed or the device has changed location beyond a specified > > > threshold. > > > > > > The databases are expected to be reachable via the Internet and the > > > devices querying these databases are expected to have some form of > > > Internet connectivity, directly or indirectly. The databases may be > > > country specific since the available spectrum and regulations may > > vary, > > > but the fundamental operation of the protocol should be country > > > independent, thus extensibility of data structures will be required. > > The > > > solution will not be tied to any specific spectrum, country, or > > > phy/mac/air interface but may incorporate relevant aspects of these > > as > > > needed for proper operation. > > > > > > The proposed working group will : > > > - standardize a protocol for querying the database, which includes a > > > location sensitive database discovery mechanism and security for the > > > protocol, and application services. > > > - Standardize the data structure to be carried by the query > > > protocol. > > > > > > The protocol must protect both the channel enablement process and the > > > privacy of users. Robust security mechanisms are required to prevent: > > > device identity spoofing, modification of device requests, > > modification > > > of channel enablement information, impersonation of registered > > database > > > services and unauthorized disclosure of a users location. > > > > > > Existing IETF location data structures and privacy mechanisms may be > > > considered for use. The WG will also investigate the need for other > > > mechanisms and related protocols to the White Space DB. > > > > > > The Working Group will set up and maintain appropriate contact and > > > liaison with other relevant standards bodies and groups, including > > IEEE > > > 802.11af and IEEE 802.22 to begin with. The working group may also > > > consider input from regulatory entities that are involved in the > > > specification of the rules for secondary use of spectrum in specific > > > bands. > > > > > > Goals and Milestones > > > > > > Sep 2011 Submit 'Requirements and Framework' to the IESG for > > > publication as Informational > > > > > > Apr 2012 Submit 'Protocol for Querying a Whitespace Database' to > > > the IESG for publication as Proposed Standard > > > > > > Apr 2012 Submit 'Data Model for Whitespace query protocol' to the > > > IESG for publication as Proposed Standard > > > _______________________________________________ > > > paws mailing list > > > paws@xxxxxxxx > > > https://www.ietf.org/mailman/listinfo/paws > > > > > _______________________________________________ > > paws mailing list > > paws@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ > paws mailing list > paws@xxxxxxxx > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf