Subject: Re: [paws] Overview & Use Cases I-D draft-probasco-paws-overview-usecases-00.txt

From: Paul Lambert <[email-masked]>
Date: Tue, 1 Mar 2011 00:09:22 -0800

Paul A. Lambert |  Marvell  | +1 650 787 9141

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rex Buddenberg
> Sent: Monday, February 28, 2011 4:28 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [paws] Overview & Use Cases I-D draft-probasco-paws-
> overview-usecases-00.txt
> 
> Scott,
> 
> On page 5, para 3 you refer to 'trusted database administrator'.  The
> data in the database obviously must be trusted -- you got that.  But
> that means that the data sent to the database must be authentic over
> the
> (untrusted) comms system.  Paras 2, 3, 4 can easily be amended to point
> out that the transactions between the user (AP) and database must be
> signed.

Signed is only one approach for data authentication and is a design decision that should not be made prematurely.

Paul

> 
> On Mon, 2011-02-28 at 23:46 +0000, [email-masked] wrote:
> > Hello,
> >
> >
> >
> > Just wanted to let you know that we have posted an overview and use
> > case scenario I-D.
> >
> > I-D: Protocol to Access White Space database: Overview and Use case
> > scenarios
> >
> >
> >
> > http://www.ietf.org/internet-drafts/draft-probasco-paws-overview-
> usecases-00.txt
> >
> >
> >
> > Please review and provide comments to further improve the I-D.
> >
> >
> >
> > Regards,
> >
> > Scott
> >
> >
> > _______________________________________________
> > paws mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/paws
> 
> 
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Paul Lambert <[email-masked]>
Date: Tue, 1 Mar 2011 00:14:47 -0800

> Hi HaNguyen,
> One such reason could be to assist in identifying a Secondary
> transmitter which is causing interference to a Primary user of the
> radio spectrum.

Telling the DB the "seleted channel" is not necessary and would unduly limit the channel usage. Actual channel usage will also not be so easily represented as just the TV channels - for example some systems will use smaller channels sizes. 

Paul

> ext Ha Nguyen Tran
> Sent: Monday, February 28, 2011 10:36 PM
> To: [email-masked]
> Hello Scott,
> I asked about spectrum usage of secondary users since it may affect
> the protocol design.
> If there is no such assumption the step 7 of 4.1 is not clear to me.
> Why AP should tell the DB which channel it has selected?
> 
> Best regards,
> HaNguyen.
> 
> 
> On Tue, Mar 1, 2011 at 1:29 PM,  <[email-masked]> wrote:
> > Hello HaNguyen,
> >
> > There is no assumption that the database manages the spectrum among
> secondary users. The guiding principle for secondary user access to the
> spectrum is: secondary users cannot cause interference and they cannot
> expect any protection from interference. However, it is possible some
> other entity or mechanism manages the spectrum access of the secondary
> users, one example is being developed in 802.19.1. But such coexistence
> mechanism is outside the scope of PAWS.
> >
> > I agree with your comment on use case 4.2, some regulators may
> require additional information beyond simple latitude and longitude.
> >
> > Regards,
> > Scott
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Ha Nguyen Tran
> > Sent: Monday, February 28, 2011 9:47 PM
> > To: [email-masked]
> > Hello Scott,
> > In use case 4.1 (hot spot) step 7 is there assumption that the WS
> database
> > manages the spectrum usage of secondary users?
> >
> > In use case 4.2 maybe latitude and longitude are not enough. Some
> regulators
> > e.g. FCC also require altitude information in order to determine the
> > height above
> > average terrain (HAAT).
> >
> > Regards,
> > HaNguyen.
> >
> > On Tue, Mar 1, 2011 at 8:46 AM,  <[email-masked]> wrote:
> >> Hello,
> >>
> >>
> >>
> case
> >> scenario I-D.
> > --
> > Ha-Nguyen Tran
> > [email-masked], [email-masked]
> --
> Ha-Nguyen Tran
> [email-masked], [email-masked]

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 01 Mar 2011 08:37:35 -0800

OK.  Yeah, define the requirement first.

Getting ahead of the requirements discussion a bit ... to me, this
screams for simply extending the MIB for white space devices to include
the variables required (most are already there) and use the
already-existing get/set SNMP mechanism ... after all, this is
configuration management.  Which allows us to use the SNMPv3
authentication mechanisms .... which is signing.

---

From: Serge Manning <[email-masked]>
Date: Wed, 2 Mar 2011 17:48:42 -0600

I agree and also have some concerns with "writing" secondary device usage
into the database in a dynamic way, per steps 3 and 7 of the use case in
4.1. The FCC has specifically said that this behavior is not useful in
determining sources of interference to primary users. Do people expect other
regions to support or mandate this kind of behavior?

Not to be overly restrictive as we start a framework, but do we then need to
consider other dynamic behavior? Such as:
- Should WS devices contact the database upon starting to transmit and again
upon stopping transmission? This may increase database messaging a great
deal.
- Should channel availability to WS devices be removed when in use by other
WS devices?
- Related to the previous, do these database updates from WS devices need to
be propagated (i.e., pushed) to all other WS devices operating in a close by
region?
- Querying (read only) access to a database is one thing, but the ability to
write implies different/more security requirements.

Just wanted to get a more clear understanding before (perhaps) opening a can
of worms.

Thanks.

On Tue, Mar 1, 2011 at 2:14 AM, Paul Lambert <[email-masked]> wrote:

> Telling the DB the "seleted channel" is not necessary and would unduly
> limit the channel usage. Actual channel usage will also not be so easily
> represented as just the TV channels - for example some systems will use
> smaller channels sizes.
>
> Paul
>
> >
> > Regards,
> > Scott
> >

-- 
--Serge