Agree. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Don Joslyn Sent: Wednesday, April 18, 2012 12:05 PM To: Rosen, Brian; Peter McCann Cc: [email protected] Subject: Re: [paws] Database Discovery Question
Based on the PAWS definition of master versus slave, you are correct, the slave does not query the database. I think the confusion is that if you have a master device on a tower supporting several fixed devices, the FCC considers them all as fixed TVBDs, which means they are all master devices according to the PAWS definition. In the US, based on FCC rules, the only device type that qualifies as a PAWS slave device is the Mode I personal/portable. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rosen, Brian Sent: Wednesday, April 18, 2012 11:05 AM To: Peter McCann Cc: [email protected] Subject: Re: [paws] Database Discovery Question Perhaps I am confused, but I think in a master/slave environment, the slave does not query the database, the master does. The slave gets its allowed spectrum data from the master. There is always the question of whether the master queries on its own behalf and the slaves just get assignments within that database response, or whether the master queries on behalf of the slaves. Might have to support both models. In many cases, I think it's the latter: the master queries using the slaves location and parameters. The most common master/slave setup is tower and clients, right? The tower has an Internet connection and can query the database. The clients of the tower are the slaves. Does the database query use the location and type data of the slave or the master? Brian On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: > I think it would be a mistake to assume that the slave & master > devices both have pre-existing relationships with the same database. > In a commercial service, the slave devices would all come from > different manufacturers and would certainly have different owners. > Wouldn't we want them to interoperate with any master device, assuming > they are RF-compatible? > > -Pete > > Rosen, Brian wrote: >> Doesn't the slave get it's database access through the master? >> If that's true, the problem you are worried about doesn't exist. >> >> Brian >> >> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >> >>> I agree with Brian that LoST could be a good model for discovering >>> the appropriate database for the region you're in. A nation may >>> decide to subdivide their territory into provinces or states, each >>> of which maintains its own database. >>> >>> I think it would be a mistake to assume that there is a single, >>> pre-defined relationship for one device with just one database. In >>> particular, I think there is a thorny issue that will arise with >>> management of secure credentials on whitespace devices, illustrated >>> by the first use case in Section 4.2.1 of >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use >>> case says: >>> >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to >>> the slave/user device. >>> My question is, what if the master device has a relationship with >>> one database, but the slave device has a relationship with another? >>> How is the master's database supposed to validate the credentials of >>> the slave device, if we don't have some sort of common trust anchor? >>> Or will this "validation" be simply an insecure check of an ID >>> against a whitelist/blacklist? Who will allocate Device IDs? Will >>> they be specific to a particular database operator, or do we need >>> some common top-level allocation format? >>> >>> -Pete >>> > > > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
