Subject: Re: [paws] updated charter proposal

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 1 Apr 2011 09:33:47 +0200

Hi,

I reported in the IESG and IAB meeting this morning about the PAWS BOF,
which in my opinion went quite well. My recommendation to continue the
process with the chartering of a PAWS WG was well received. The WG (if
approved after the review process) will be in the OPS area with a
Technical Advisor from APPS. 

The first step in the review process is internal review of the charter
with the IESG and the IAB, which will result into discussion in the IESG
telechat on 4/14 and then sending of the charter to external (all IETF
review). 
 
Question - is this charter text OK for the internal review, or are there
any text changes following the BOF? 

Thanks and Regards,

Dan

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
	Sent: Thursday, March 24, 2011 12:24 AM
	To: [email-masked]
	Subject: [paws] updated charter proposal

	Folks,

	Here's an updated charter proposal.

	But please read these two drafts before you come to the BOF:

	I-D: Protocol to Access White Space database: Problem statement
and Requirements

	http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt

	I-D: Protocol to Access White Space database: Overview and Use
case scenarios

http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt

	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.

	Since the location of a user device is involved, privacy
implications arise, and the protocol will have to have robust security
mechanisms.

	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.

	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

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 1 Apr 2011 03:47:56 -0400

Good news!  There were charter changes requested in the BoF in the security section.

I suggest that the line in the charter:
Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms.

Be changed to:
Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security and privacy mechanisms.  There are other security concerns, including spoofing and man in the middle attacks that will require analysis and mechanisms for mitigation in the protocol.

Brian

On Apr 1, 2011, at 9:33 AM, Romascanu, Dan (Dan) wrote:

Hi,

I reported in the IESG and IAB meeting this morning about the PAWS BOF, which in my opinion went quite well. My recommendation to continue the process with the chartering of a PAWS WG was well received. The WG (if approved after the review process) will be in the OPS area with a Technical Advisor from APPS.

The first step in the review process is internal review of the charter with the IESG and the IAB, which will result into discussion in the IESG telechat on 4/14 and then sending of the charter to external (all IETF review).

Question - is this charter text OK for the internal review, or are there any text changes following the BOF?

Thanks and Regards,

Dan

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, March 24, 2011 12:24 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] updated charter proposal

Folks,

Here’s an updated charter proposal.

I-D: Protocol to Access White Space database: Problem statement and Requirements
http://www.ietf.org/id/draft-patil-paws-problem-stmt-00.txt

I-D: Protocol to Access White Space database: Overview and Use case scenarios
http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt

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.
Since the location of a user device is involved, privacy implications arise, and the protocol will have to have robust security mechanisms.
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.
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

<ATT00001..txt>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 1 Apr 2011 10:52:54 -0700

Friendly edit (below):

Since the location of a user device is involved, privacy implications arise.  The protocol must have robust mechanisms for mutual authentication and must prevent the unauthorized disclosure of a users location.

Paul

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, April 01, 2011 12:48 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked] (Nokia-CIC/SiliconValley); [email-masked]; Polk, William T.
Subject: Re: [paws] updated charter proposal

Be changed to:

Brian

Hi,

Thanks and Regards,

Dan

<ATT00001..txt>

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 1 Apr 2011 13:58:04 -0400

I think Tim Polk wanted more words about security beyond just these.

Brian

On Apr 1, 2011, at 7:52 PM, Paul Lambert wrote:

Friendly edit (below):

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Friday, April 01, 2011 12:48 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]<mailto:[email-masked]> (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>; Polk, William T.
Subject: Re: [paws] updated charter proposal

Be changed to:

Brian

Hi,

Thanks and Regards,

Dan

<ATT00001..txt>

---

From: Paul Lambert <[email-masked]>
Date: Fri, 1 Apr 2011 11:25:49 -0700

> I think Tim Polk wanted more words about security beyond just these.
Oh ... ok

I believe these are the overall threat areas:
device identity spoofing
modification of device requests
modification of channel enablement information
impersonation of registered database services
unauthorized disclosure of a users location

There may be other broader ways to phrase these - but we need to be careful not to slip into device internal security versus the security of the protocol.

Translating the above into charter speak and as a revised suggestion:

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.

Hope this helps ...

Paul

From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, April 01, 2011 10:58 AM
To: Paul Lambert
Cc: Romascanu, Dan (Dan); [email-masked] (Nokia-CIC/SiliconValley); [email-masked]; Polk, William T.
Subject: Re: [paws] updated charter proposal

Brian

Friendly edit (below):

Paul

Be changed to:

Brian

Hi,

Thanks and Regards,

Dan

<ATT00001..txt>

---

From: Teco Boot <[email-masked]>
Date: Mon, 4 Apr 2011 11:49:40 +0200

I'm not sure on requirements for non-repudiation. Should a secondary user keep evidence that it legally use (or used) a granted channel? It may have impact on the protocol.

Teco

Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven:

> Oh … ok
> There may be other broader ways to phrase these – but we need to be careful not to slip into device internal security versus the security of the protocol.
>  
> Hope this helps …
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: <[email-masked]>
Date: Tue, 5 Apr 2011 07:15:45 +0000

Hi,

IMHO "Robust security mechanisms" is broad enough to include non-repudiation without having to identify it specifically. Not saying at this point that non-repudiation must be included in PAWS (a subtle vote for WG name), only that I believe the proposed charter wording allows the possibility, if the group decides it is needed.

Regards,
Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Teco Boot
Sent: Monday, April 04, 2011 4:50 AM
To: Paul Lambert
Cc: [email-masked]; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: Re: [paws] updated charter proposal

Teco

---

From: Ian Ferrell <[email-masked]>
Date: Tue, 5 Apr 2011 14:23:47 +0000

Teco, are you concerned that a rogue entity could set up at a location and tell devices around it that Channel X is available--when in fact the channel is occupied by a licensed broadcaster--and thus wreak havoc? So, in this scenario, devices would need some mechanism to defend their channel use?

FWIW, I didn't see anything about this in the FCC order--I think the assumption on their part is that Device FOO has some mechanism to determine it is talking to a legal database so rogue entities would not be able to spoof bad permissions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 05, 2011 12:16 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [paws] updated charter proposal

Hi,

Regards,
Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Teco Boot
Sent: Monday, April 04, 2011 4:50 AM
To: Paul Lambert
Cc: [email-masked]; Rosen, Brian; Polk, William T.; Bajko Gabor (Nokia-CIC/SiliconValley)
Subject: Re: [paws] updated charter proposal

Teco

Op 1 apr 2011, om 20:25 heeft Paul Lambert het volgende geschreven:

> modification of channel enablement information impersonation of 
> registered database services unauthorized disclosure of a users 
> location
>  
> 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.
>  
>  
>  
> Hope this helps ...
>  
> Paul
>  
>  
> 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.

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Apr 2011 10:42:33 -0400

First of all, I don't think we need this level of detail in the charter.  We should discuss it when we get to requirements.

It is important to have authentication of both ends of the query.  The device needs to know that it is talking to the authoritative server for the location and band he is operating in.  The server may need to know which client it is serving, especially when there is a subscription relationship of some kind: some databases may only serve certain devices with whom they have some relationship.   That would address a rogue server (or a rogue device).

Non repudiation is another story.  I don't think we have a requirement for that, but we'll see.  That scenario would be that an authoritative server sent an incorrect channel to the device, and the device interfered.  The device may could want to prove that the server sent it bad data.  I don't think that is a credible threat.  

Brian

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 5 Apr 2011 10:51:57 -0400

Brian is absolutely right here ..this level of specificity is not necessary
at the charter phase.  The need here is to define reasonable scope,
realistic deliverables and let the WG get on with it. 

The proposed charter is fine as is. It can always be amended. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Tuesday, April 05, 2011 10:43 AM
To: Ian Ferrell
Cc: [email-masked]
Subject: Re: [paws] updated charter proposal

First of all, I don't think we need this level of detail in the charter.  We
should discuss it when we get to requirements.

It is important to have authentication of both ends of the query.  The
device needs to know that it is talking to the authoritative server for the
location and band he is operating in.  The server may need to know which
client it is serving, especially when there is a subscription relationship
of some kind: some databases may only serve certain devices with whom they
have some relationship.   That would address a rogue server (or a rogue
device).

Non repudiation is another story.  I don't think we have a requirement for
that, but we'll see.  That scenario would be that an authoritative server
sent an incorrect channel to the device, and the device interfered.  The
device may could want to prove that the server sent it bad data.  I don't
think that is a credible threat.  

Brian

On Apr 5, 2011, at 10:23 AM, Ian Ferrell wrote:

> Teco, are you concerned that a rogue entity could set up at a location and
tell devices around it that Channel X is available--when in fact the channel
is occupied by a licensed broadcaster--and thus wreak havoc? So, in this
scenario, devices would need some mechanism to defend their channel use?
> 
> FWIW, I didn't see anything about this in the FCC order--I think the
assumption on their part is that Device FOO has some mechanism to determine
it is talking to a legal database so rogue entities would not be able to
spoof bad permissions.
> IMHO "Robust security mechanisms" is broad enough to include
non-repudiation without having to identify it specifically. Not saying at
this point that non-repudiation must be included in PAWS (a subtle vote for
WG name), only that I believe the proposed charter wording allows the
possibility, if the group decides it is needed.
> I'm not sure on requirements for non-repudiation. Should a secondary user
keep evidence that it legally use (or used) a granted channel? It may have
impact on the protocol.
>> There may be other broader ways to phrase these - but we need to be
careful not to slip into device internal security versus the security of the
protocol.
>> enablement information, impersonation of registered database services and
unauthorized disclosure of a users location.
>> Cc: Romascanu, Dan (Dan); [email-masked]
(Nokia-CIC/SiliconValley); [email-masked]; Polk, William T.
>> Since the location of a user device is involved, privacy implications
arise.  The protocol must have robust mechanisms for mutual authentication
and must prevent the unauthorized disclosure of a users location.
>> Since the location of a user device is involved, privacy implications
arise, and the protocol will have to have robust security mechanisms.
>> 
>> Be changed to:
>> Since the location of a user device is involved, privacy implications
arise, and the protocol will have to have robust security and privacy
mechanisms.  There are other security concerns, including spoofing and man
in the middle attacks that will require analysis and mechanisms for
mitigation in the protocol.
which in my opinion went quite well. My recommendation to continue the
process with the chartering of a PAWS WG was well received. The WG (if
approved after the review process) will be in the OPS area with a Technical
Advisor from APPS.
> 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.
>>    - standardize a protocol for querying the database, which includes a
location sensitive database discovery mechanism and security for  the
protocol, and application services.
>> Since the location of a user device is involved, privacy implications
arise, and the protocol will have to have robust security mechanisms.
>> 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.

---

From: "Jesse Caulfield" <[email-masked]>
Date: Tue, 5 Apr 2011 11:35:30 -0400

Non-repudiation, or at least its functional equivalent in
mutual-authentication + encryption, is required for US operation.

Agree with B.Rosen and S.Probasco that such details are likely not needed in
a charter and "robust security" is a sufficiently flexible mention.
--
J.Caulfield

-----Original Message-----

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Teco Boot

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 5 Apr 2011 11:44:20 -0400

Nit picking, but there is a big difference between mutual authentication (do I know who I am talking to?) and non-repudiation (can I prove you sent me something, even if you claim you didn't?).  We need the former, I don't think we need the latter (here, in the device to db query).

Brian

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 5 Apr 2011 17:45:27 +0200

Hi, 

The Requirements and Framework informational document is probably the
place were the detailed requirements (including those derived from the
US regulatory requirements) should be listed. 

Regards,

Dan 

> Behalf Of Jesse Caulfield
> Sent: Tuesday, April 05, 2011 6:36 PM
> To: [email-masked]
> Agree with B.Rosen and S.Probasco that such details are 
> likely not needed in a charter and "robust security" is a 
> sufficiently flexible mention.
> --
> J.Caulfield
> 
> 
> Behalf Of Rosen, Brian
> First of all, I don't think we need this level of detail in 
> the charter.  We should discuss it when we get to requirements.
> 
> It is important to have authentication of both ends of the 
> query.  The device needs to know that it is talking to the 
> authoritative server for the location and band he is 
> operating in.  The server may need to know which client it is 
> serving, especially when there is a subscription relationship 
> Non repudiation is another story.  I don't think we have a 
> requirement for that, but we'll see.  That scenario would be 
> that an authoritative server sent an incorrect channel to the 
> device, and the device interfered.  The device may could want 
> to prove that the server sent it bad data.  I don't think 
> that is a credible threat.  
> 
> Brian
> 
> 
> 
> > Teco, are you concerned that a rogue entity could set up at 
> a location 
> > and
> tell devices around it that Channel X is available--when in 
> fact the channel is occupied by a licensed broadcaster--and 
> thus wreak havoc? So, in this scenario, devices would need 
> some mechanism to defend their channel use?
> > 
> assumption on their part is that Device FOO has some 
> mechanism to determine it is talking to a legal database so 
> rogue entities would not be able to spoof bad permissions.
> > 
> > 
> > 
> > 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of
> [email-masked]
> non-repudiation without having to identify it specifically. 
> Not saying at this point that non-repudiation must be 
> included in PAWS (a subtle vote for WG name), only that I 
> believe the proposed charter wording allows the possibility, 
> if the group decides it is needed.
> > 
> > Regards,
> > Scott
> > 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of
> ext Teco Boot
> > I'm not sure on requirements for non-repudiation. Should a 
> secondary 
> > user
> keep evidence that it legally use (or used) a granted 
> channel? It may have impact on the protocol.
> > 
> > Teco
> > 
> careful not to slip into device internal security versus the 
> security of the protocol.
> >> 
> >> The protocol must protect both the channel enablement 
> process and the
> privacy of users.
> >> enablement information, impersonation of registered 
> database services 
> >> and
> implications
> arise.  The protocol must have robust mechanisms for mutual 
> authentication and must prevent the unauthorized disclosure 
> of a users location.
> >> 
> >> 
> >> Paul
> >> 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Rosen, Brian
> >> Cc: [email-masked] (Nokia-CIC/SiliconValley); 
> [email-masked]; 
> >> Polk,
> William T.
> implications
> implications
> arise, and the protocol will have to have robust security and 
> privacy mechanisms.  There are other security concerns, 
> including spoofing and man in the middle attacks that will 
> require analysis and mechanisms for mitigation in the protocol.
> >> 
> >> Brian
> >> 
> which in my opinion went quite well. My recommendation to 
> continue the process with the chartering of a PAWS WG was 
> well received. The WG (if approved after the review process) 
> will be in the OPS area with a Technical Advisor from APPS.
> >> 
> with the IESG and the IAB, which will result into discussion 
> in the IESG telechat on 4/14 and then sending of the charter 
> to external (all IETF review).
> >> 
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of [email-masked]
> >> I-D: Protocol to Access White Space database: Problem 
> statement and 
> >> Requirements 
> >> I-D: Protocol to Access White Space database: Overview and 
> Use case 
> >> scenarios 
> >> 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
> 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.
> access TV
> 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.
> 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.
> >>    - standardize a protocol for querying the database, 
> which includes 
> >> a
> location sensitive database discovery mechanism and security 
> implications
> considered for use. The WG will also investigate the need for 
> 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.
> >> Milestones