----- Original Message ----- From: "Joel M. Halpern" <jmh@xxxxxxxxxxxxxxx> To: "Rex Buddenberg" <budden@xxxxxxxxxxxx> Cc: "Paul Lambert" <paul@xxxxxxxxxxx>; <paws@xxxxxxxx>; <iesg@xxxxxxxx>; "IETF discussion list" <ietf@xxxxxxxx> Sent: Wednesday, April 20, 2011 4:17 AM Subject: Re: [paws] WG Review: Protocol to Access White Space database (paws) > Actually, as far as I can tell, there is very little parallel between > the PAWS problem and SNMP. > SNMP tends to be initiated by the manager, and used to extract > information from the device in the network, or set information in teh > device. Joel I see one small parallel with SNMP. All the recent work on SNMP has been on security, and while setting up a secure channel is easy, TLS or SSH, knowing that it goes where you want it to as opposed to via a MITM is more difficult, both when the device calls home to send an alert, or when home calls the device to solicit information. And the credentials used by the transport need binding securely to the identity at a higher layer. This was troublesome and I will be interested to see how this is solved. By comparison I expect that the application will fall out in the wash. Channel binding anyone? One for the security area? Tom Petch > This protocol is used by the client. It extracts basically stable > information about what frequencies can be used in this geographic region > at this time. > There is no "network management" going on. the interaction does not > look like SNMP. And the effect does not look like SNMP. While Radius > or Diameter are closer, this protocol is not even a policy decision > protocol. There is no "policy". > > So no, I do not think this looks anything like network management. > The protocols, the transaction drivers and behavior, the problem space, > and the underlying data behavior are all very different from any of our > NM work. > > Yours, > Joel > > On 4/19/2011 5:21 PM, Rex Buddenberg wrote: > > 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 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf