Subject: [paws] next steps for the wg

From: <[email-masked]>
Date: Fri, 13 Jan 2012 01:26:52 +0000

As the AD noted, the list has been inactive for the last few weeks.

In this email I am trying to summarize where we are and what we need to do next in the WG:

1. use cases: We had a long discussion about the use cases in the last f2f, and it seems that the only use case requiring a re-write is the m2m one. Juan-Carlos promised to revise the use case based on the comments received and post the revised version to the list asap.
Brian promised to contribute a use case on mesh-networking, as that seems to be different from the m2m one.
With the revision of the m2m and addition of the mesh-networking one, the use case part should be complete.

2. requirements. In the last f2f 
we agreed to modify requirement D.1 to include the suggestions from slide 7-10 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9
slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also contain suggestions on how to revise this requirement.
Agreed to revise requirement D.2 as suggested in slide 11 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf and slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf 
We seem to have agreed with the reformulation suggested to D.3 in slide 12 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. The data format part is still open, but as this piece does not really belong to requirements but rather the data model spec, we are not in a hurry to decide it.
Delete d.4
D.5: augment with lower/upper frequencies and time of availability, as suggested on slide 10 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf 
D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf.
D.7: change to single and multiple locations. Clarify that in case of multiple locations the channel availability for each location should be sent by the db.
D.8: delete

P.2 currently says: The protocol MUST support regulatory domain discovery.
We need to discuss this further on the list, to come up with a better formulated requirement.
The minutes captured:
Implies transmitter first queries the DB to find out the regulatory domain before it queries for the available channel list
need to spend time figuring out an implementable requirement.  Related to sending "rules" for a domain
put it as a suggestion rather than requirement.  Current regulations envision tight coupling between certified devices and owners.
need to document the coupling between regulatory domain, database, requirements.
Suggestions for P.2 expected to the list.

P.3 currently says:  The protocol between the master device and the WS Database  MUST support pushing updates in channel availability  changes to subjects.
There were comments that this requirement involves a mechanism, we should reformulate to be mechanism agnostic.
There was a suggestion to "make the requirement "quick way to change availability" rather than imply a mechanism.".
The use case is that if the channel availability changes in the DB, the client has to be able to detect it and get the new availability list within a time period set by the regulator.
Can someone send suggested text on how to reformulate this requirement?

We had no time to go through these requirements, so I am asking here on the list to please comment on them:

P.4:   The protocol between the master device and the WS Database
             MUST support mutual authentication and authorization.

P.5:   The protocol between the master device and the WS Database
             MUST support integrity and confidentiality protection.

P.6:   The protocol MUST support both username/password and
             digital certificates based authentication.

P.12:  A master device MUST be capable of validating the digital
             certificate of the WS Database.

P.13:  A master device MUST be capable of checking the validity of
             the WS Database certificate and whether it has been revoked
             or not.

Note, P.13 requires support for OCSP (RFC2560) in the client, I am not sure if that is needed, please send your opinions.

The wording of P.11 has to be enhanced to match the description of the revised D.1

We did not have any discussion on P.9, so I'd like to get comments on the list about this:
      P.9:   A master device MUST be able to query the whitespace
             database for channel availability information for a
             specific expected coverage area around its current
             location.

Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them.

I ask the editor to implement the changes above and post a revised version asap, so we can have further reviews on it.

We also have a protocol framework document available at http://www.ietf.org/id/draft-das-paws-protocol-00.txt
We did have a brief discussion on it, the author promised to update it to capture the received comments and post a new version in the next few weeks. If you have additional comments, please send those to the list, so the author can address them.

We also have a proposal available on the data model structure, available at http://www.ietf.org/id/draft-caufield-paws-protocol-for-tvws-01.txt
It was presented in the last f2f, but there was no time for comments. Please send your comments on this document to the list too.

- Gabor

---

From: "Dr. Rashid Saeed" <[email-masked]>
Date: Fri, 13 Jan 2012 06:59:19 +0000

New TVWS book, FYI...

  

 

 

  
  Stay Up to Date on Information & Communications
  Technology Standards

 

 

  

  TV
  White Space Spectrum Technologies: Regulations, Standards and Applications
  explains how to use white space technology to enable the additional spectrum
  access that is so badly needed around the world. In this forward-thinking
  book, prominent industry players, researchers, and standards developers:
  Examine IEEE and FCC standards and
       regulationsHighlight potential business
       opportunities, including broadband Internet applicationsAddress deployment problems likely to
       ariseDiscuss system requirements, spectrum
       sharing, privacy, and security
  Learn
  how to use these technologies in practice

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Jan 2012 10:56:54 -0700

Gabor, thank you for the very comprehensive summary! I'm looking forward
to discussion by WG participants and work by the document editors to
address and incorporate these issues.

On 1/12/12 6:26 PM, [email-masked] wrote:
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Jan 2012 10:58:10 -0700

Oh, and please note that WG sessions for IETF 83 need to be scheduled
less than 2 weeks from now:

http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 23:08:40 +0000

Hi Gabor,

On 1/12/12 8:26 PM, "ext [email-masked]" <[email-masked]>
wrote:

>P.3 currently says:  The protocol between the master device and the WS
>Database  MUST support pushing updates in channel availability  changes
>to subjects.
>There was a suggestion to "make the requirement "quick way to change
>availability" rather than imply a mechanism.".
>The use case is that if the channel availability changes in the DB, the
>client has to be able to detect it and get the new availability list
>within a time period set by the regulator.

The requirement to enable Push notifications to be sent to a white space
device which has registered with a database is important especially in the
context of Ofcom requirements (I believe). The reasons for such push
notifications could be for purposes that go beyond just channel
availability updates. A proposal for the requirement is as follows:

Requirement: A white space database should be able to send unsolicited
messages to a master device which has registered with it. The protocol
between the WS database and master device MUST allow for push
notifications to be sent from the database to the master device.

-Raj

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 23:11:54 +0000

Hi Gabor,

>             digital certificates based authentication.

The requirement for the protocol is to allow mutual
authentication/authorization between the white space database and master
device. I do not see the need for an explicit requirement as stated above
w.r.t the authentication mechanism itself. Hence I would propose deleting
this requirement. 

-Raj

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 23:14:32 +0000

Gabor,

On 1/12/12 8:26 PM, "ext [email-masked]" <[email-masked]>
wrote:

>Note, P.13 requires support for OCSP (RFC2560) in the client, I am not
>sure if that is needed, please send your opinions.
>

If certificate based authentication is used by the protocol, then there
would be a need to mandate the above requirement. But at this time we have
no visibility about the authentication protocol to be used between the
master device and the WS database. So it is premature to specify the above
requirement. Hence I would favor dropping this requirement.

-Raj

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 23:17:50 +0000

Hi Gabor,

>             specific expected coverage area around its current

This requirement addresses the need associated with a white space master
device which is mobile.
The master device may query channel availability for a specific contour or
a set of locations on a certain path for example.
Hence this requirement is primarily about allowing the query to contain
information that goes beyond just a specific lat/long co-ordinate.

-Raj

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 17 Jan 2012 18:25:53 -0500

I would like to see this be described in a more generic way. I agree with
Raj that this is all about providing information for more than a point on
a map but there are several possible scenarios for which a query for a
"polygon" could be requested. It could be a very long thin polygon if the
request is related to a road or railroad or a fairly square polygon if the
request is for a venue or even a field.  While the use case may be a
mobile master it could also be for a master that is supporting devices
that either roam within the polygon or cannot accurately locate themselves
within the polygon.

---

From: <[email-masked]>
Date: Tue, 17 Jan 2012 23:32:37 +0000

Hi Peter,

I concur with your comment. Just a quick clarification question about the
scenario wherein the mobile master is supporting devices that either roam
within a polygon or cannot accurately locate themselves..
First of all I am not sure I understand what these other devices are that
are relying on the master. Maybe a more complete use case description
would help.
We do not have such a scenario in the current document and could consider
it.

-Raj

On 1/17/12 5:25 PM, "ext Peter Stanforth" <[email-masked]> wrote:

>>>We did not have any discussion on P.9, so I'd like to get comments on
>>>the
>>>list about this:

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 17 Jan 2012 18:41:03 -0500

This comment is a compound response to the "Security between the database
and the white space radio".
I have always believed that there is little reason to need to trust the
radio - after all if it was going to do something malicious or illegal why
would it even contact the database and request a channel list. In addition
the impact of a single rouge radio is fairly limited. However the
implications of a spoofed database that provides "all channels available
everywhere" in response to channel queries could be catastrophic.  I  am
finding it hard to evaluate this requirement, and the previous
requirements in isolation. I think it would be better to consider the
various threat levels and then decide how to provide reasonable protection
against them in a comprehensive way.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Jan 2012 21:03:06 -0500

While responses have time windows, as far as I know, requests do not 
specify when the response will be acted upon, if ever, or for how long.

As such, this seems to imply either that we add significantly more 
information to requests, or that any change in anything that has ever 
been asked for gets pushed?
That does not sound like a good design.

Yours,
Joel

On 1/17/2012 6:08 PM, [email-masked] wrote:
>
> Hi Gabor,
>
> On 1/12/12 8:26 PM, "ext [email-masked]"<[email-masked]>
> wrote:
>

---

From: <[email-masked]>
Date: Wed, 18 Jan 2012 16:38:01 +0000

Hi Joel,

The proposal to include unsolicited Push notifications from the white
space database to a master device is different from the Request/Response
mechanism itself.
A master device making a request for available channels expects a response
in some time window. Not proposing we change that.
However the white space database knows of devices which have registered
with it. And hence can send push notifications at will without necessarily
having to react to a request.

-Raj

On 1/17/12 8:03 PM, "ext Joel M. Halpern" <[email-masked]> wrote:

>>> There were comments that this requirement involves a mechanism, we
>>>should
>>> reformulate to be mechanism agnostic.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 18 Jan 2012 11:43:44 -0500

Sorry to be slow.
How does the database know which changes are of interest to any 
particular registered client?  I would hope that it does not push all 
changes to all clients.  But i not, it needs to somehow guess which 
changes matter.  Would it keep track of what answers it has sent to each 
such registered clients, and try to track which changes may affect 
actions of that client?

Yours,
Joel

On 1/18/2012 11:38 AM, [email-masked] wrote:
> On 1/17/12 8:03 PM, "ext Joel M. Halpern"<[email-masked]>  wrote:
>

---

From: <[email-masked]>
Date: Wed, 18 Jan 2012 16:50:57 +0000

An example:
A white space database may decide to withdraw channels that were
previously indicated as being available for use to a set of master devices
(reason being a need for those channels by some emergency service).
Devices register with the database as part of the initial
authentication/authorization process and hence the database would have the
capability of sending such messages only to the relevant devices and not
to all devices.
It does result in state being maintained at the database.

The requirement for such capability is needed by Ofcom (AFAIK) and hence
the proposal.

Solutions will need to consider how to deal with this optimally.

-Raj

---

From: <[email-masked]>
Date: Wed, 18 Jan 2012 17:22:15 +0000

A clarification with regard to the need for push notifications. I am not aware that this is an Ofcom requirement. In their last consultation Ofcom's description of a master device says that it must "cease transmission immediately where the time validity expires or where it moves outside of the geographic area of validity". The master polls every x hours (e.g. every two hours), using a periodicity set by regulation, in order to maintain validity for the TVWS channel it is using, and does not need to be able to receive pushed information. This works because any changes to channel availability (due to a local news event requiring wireless microphones for example) have a lead time, which give the opportunity for the channel to be cleared. Microphones needing to be operational more quickly than x hours could be operated in other spectrum (for example). The same process would enable a network to be turned off within x hours if Ofcom so desired.

Having said that, I am in favour of there being a push capability from the database to masters. I just think it would not be implemented by all masters if not required the regulator, so would be optional.

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 18 January 2012 16:51
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] next steps for the wg

An example:
A white space database may decide to withdraw channels that were previously indicated as being available for use to a set of master devices (reason being a need for those channels by some emergency service).
Devices register with the database as part of the initial authentication/authorization process and hence the database would have the capability of sending such messages only to the relevant devices and not to all devices.
It does result in state being maintained at the database.

The requirement for such capability is needed by Ofcom (AFAIK) and hence the proposal.

-Raj

On 1/18/12 10:43 AM, "ext Joel M. Halpern" <[email-masked]> wrote:

>changes matter.  Would it keep track of what answers it has sent to 
>each such registered clients, and try to track which changes may affect 
>actions of that client?
>
>Yours,
>Joel
>
>>space database to a master device is different from the 
>>Request/Response  mechanism itself.
>> A master device making a request for available channels expects a 
>>response  in some time window. Not proposing we change that.
>> However the white space database knows of devices which have 
>>registered  with it. And hence can send push notifications at will 
>>without necessarily  having to react to a request.
>>
>> -Raj
>>
>>> information to requests, or that any change in anything that has 
>>> ever been asked for gets pushed?
>>>> On 1/12/12 8:26 PM, "ext 
>>>> [email-masked]"<[email-masked]>
>>>> wrote:
>>>>
>>>>> P.3 currently says:  The protocol between the master device and 
>>>>>the WS  Database  MUST support pushing updates in channel 
>>>>>availability changes  to subjects.
>>>>>should  reformulate to be mechanism agnostic.
>>>>> There was a suggestion to "make the requirement "quick way to 
>>>>>change  availability" rather than imply a mechanism.".
>>>>> The use case is that if the channel availability changes in the 
>>>>>DB, the  client has to be able to detect it and get the new 
>>>>>availability list  within a time period set by the regulator.
>>>> The requirement to enable Push notifications to be sent to a white 
>>>>space  device which has registered with a database is important 
>>>>especially in  the  context of Ofcom requirements (I believe). The 
>>>>reasons for such push  notifications could be for purposes that go 
>>>>beyond just channel  availability updates. A proposal for the 
>>>>requirement is as follows:
>>>>
>>>> Requirement: A white space database should be able to send 
>>>> unsolicited messages to a master device which has registered with 
>>>> it. The protocol between the WS database and master device MUST 
>>>> allow for push notifications to be sent from the database to the master device.
>>>>
>>>> -Raj
>>>>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Jan 2012 12:28:45 -0500

I also think it's a valuable capability.  

Brian

---

From: <[email-masked]>
Date: Wed, 18 Jan 2012 17:30:36 +0000

Thanks for the clarification Andy.

I agree that the feature could be optional.

-Raj

On 1/18/12 11:22 AM, "ext [email-masked]" <[email-masked]> wrote:

>A clarification with regard to the need for push notifications. I am not
>aware that this is an Ofcom requirement. In their last consultation
>Ofcom's description of a master device says that it must "cease
>transmission immediately where the time validity expires or where it
>moves outside of the geographic area of validity". The master polls every
>x hours (e.g. every two hours), using a periodicity set by regulation, in
>order to maintain validity for the TVWS channel it is using, and does not
>need to be able to receive pushed information. This works because any
>changes to channel availability (due to a local news event requiring
>wireless microphones for example) have a lead time, which give the
>opportunity for the channel to be cleared. Microphones needing to be
>operational more quickly than x hours could be operated in other spectrum
>(for example). The same process would enable a network to be turned off
>within x hours if Ofcom so desired.
>
>Having said that, I am in favour of there being a push capability from
>the database to masters. I just think it would not be implemented by all
>masters if not required the regulator, so would be optional.
>
>Regards
>
>Andy
>
>previously indicated as being available for use to a set of master
>devices (reason being a need for those channels by some emergency
>service).
>authentication/authorization process and hence the database would have
>the capability of sending such messages only to the relevant devices and
>not to all devices.

---

From: Peter Stanforth <[email-masked]>
Date: Thu, 19 Jan 2012 08:40:36 -0500

I would like to suggest that we back up and ask the question. How do we
pre-empt a device if the primary spectrum user needs it back? The use case
I can think of is public safety, where they don't generally need the
spectrum until there is an emergency. They do not know when or where that
will happen so they would need a mechanism to clear the spectrum in a
specific location quickly.
A push mechanisms only one way to do this. Another, off the top of my head
is to only give channel permissions for time durations less than the time
they need to clear the channels. There may be other options and there are
clearly advantages and disadvantages to all.
Peter S.

On WedJan/18/12 Wed Jan 18, 11:38 AM, "[email-masked]"
<[email-masked]> wrote:

>>>space

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 19 Jan 2012 05:58:29 -0800

Peter et all, 
I agree. One thing that concerned me greatly was a statement made a while ago that it would take five minutes to clear a frequency for an emergency so I am glad to see
some further discussion on how to do this. I can imagine that FIVE minutes for someone having a heart attack, in a critical accident, 
loosing blood quickly, or many other scenarios could potentially cause deaths before first responders, EMT's, Ambulances or any other medical
help arrived at the scene with a 5 minute lag time.  This seems to be something that can be done pre emptively and immediately and to me, should be.
My two cents. 
SIncerely, Nancy Bravin

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Jan 2012 09:08:38 -0500

At this stage, we should say that we have a requirement to change availability of spectrum on a short notice, we need a use case that would motivate some decision on what "short" means, and we should not worry about which mechanism we should choose to achieve it.

Push, fast poll, and notice broadcast (i.e. a single bit sent to all clients telling them to "phone home" soon) are all reasonable mechanisms to meet the requirements.

Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 19 Jan 2012 12:12:27 -0500

Thanks Brian.  That works much better for me.
Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 19 Jan 2012 19:41:55 +0000

Hi All,

I believe it is relevant to look at Ofcom's Implementing Geolocation Summary of consultation responses and next steps. Paragraph 3.42 states:

>
>Ofcom retains control over the performance of the algorithms used in the
>databases and will update them if required to manage interference. A kill
>switch is a useful reactive tool and we believe that it should form a core
>part of the protocol which describes the information exchange between
>WSDs and the database.
>

Following the notion that a kill switch should form a core part of the protocol, this could be included in a very basic use case like "Hotspot: urban internet connectivity service". I can volunteer to make this addition in the use case.

Regarding the requirement we could say the database must be able to deliver updated channel information to any registered master device. We have not specified elsewhere any time constraints on message delivery, I wonder if this is needed in this case either.

Kind Regards,
Scott

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 00:33:23 +0000

Scott

Regarding time constraints for message delivery from the database, Ofcom has moved away from specifying a time limit for a database to respond to a request, on the basis that if it is a first request then the master will not transmit if it fails to receive a response, and if it is a 'revalidation' request and the master receives no response, the master will cease transmitting anyway when the time validity timer expires. I think in principle we need not specify a time limit for delivery of pushed information; if received, the master must act on it, but if not received, it will continue to transmit until its validity timer expires. I think that is reasonable. In practice the risk of non-delivery is tiny, as is the likelihood of invoking the kill switch in the first place as a method of solving interference issues (even in an emergency). 

Regards

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 19 January 2012 19:42
To: [email-masked]
Subject: Re: [paws] next steps for the wg

Hi All,

I believe it is relevant to look at Ofcom's Implementing Geolocation Summary of consultation responses and next steps. Paragraph 3.42 states:

>
>Ofcom retains control over the performance of the algorithms used in 
>the databases and will update them if required to manage interference. 
>A kill switch is a useful reactive tool and we believe that it should 
>form a core part of the protocol which describes the information 
>exchange between WSDs and the database.
>

Kind Regards,
Scott

---

From: Nancy Bravin <[email-masked]>
Date: Thu, 19 Jan 2012 19:24:06 -0800

Dear Andy, 
In that you are looking at this from the Ofcom aspect, and many other countries are or will be implementing such controls as a "kill switch", it may be useful
to see if from an agnostic technology point of view, just how valuable this is by use case. Certainly there are other precautions
in the UK for many situations that are handled day to day, but is that the same in most countries and what their regulations require. Isn't it safer
to have this in the protocol than not? I am not an expert but I do think there are several scenarios that can call for  a kill switch besides interference, intentional or not or emergencies
natural or not.
Just my personal opinion. Sincerely, Nancy

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 10:29:29 +0000

Nancy

Thanks for your views, I am in favour of PAWS developing a protocol for a kill switch and will be happy to review Scott's proposed text for this (sub) use case when it is posted. The protocol will need to cover the anticipated regulatory requirements across different countries.

Regards

Andy

-----Original Message-----
From: Nancy Bravin [mailto:[email-masked]] 
Sent: 20 January 2012 03:24
To: Sago,AJ,Andy,COD R
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] next steps for the wg

Dear Andy,
In that you are looking at this from the Ofcom aspect, and many other countries are or will be implementing such controls as a "kill switch", it may be useful to see if from an agnostic technology point of view, just how valuable this is by use case. Certainly there are other precautions in the UK for many situations that are handled day to day, but is that the same in most countries and what their regulations require. Isn't it safer to have this in the protocol than not? I am not an expert but I do think there are several scenarios that can call for  a kill switch besides interference, intentional or not or emergencies natural or not.
Just my personal opinion. Sincerely, Nancy

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 17:50:16 +0000

Hi Andy,

I agree with you the risk of non-delivery of pushed messages is small.

The kill switch is one method in the protocol to clear secondary users
from specific channels at specific locations. Since Ofcom has included it
in their Implementing Geolocation document I believe this is sufficient
justification to include this feature in PAWS.

Regards,
Scott

On 1/19/12 6:33 PM, "ext [email-masked]" <[email-masked]> wrote:

>Scott
>
>Regarding time constraints for message delivery from the database, Ofcom
>has moved away from specifying a time limit for a database to respond to
>a request, on the basis that if it is a first request then the master
>will not transmit if it fails to receive a response, and if it is a
>'revalidation' request and the master receives no response, the master
>will cease transmitting anyway when the time validity timer expires. I
>think in principle we need not specify a time limit for delivery of
>pushed information; if received, the master must act on it, but if not
>received, it will continue to transmit until its validity timer expires.
>I think that is reasonable. In practice the risk of non-delivery is tiny,
>as is the likelihood of invoking the kill switch in the first place as a
>method of solving interference issues (even in an emergency).
>
>Regards
>
>Andy
>
>I believe it is relevant to look at Ofcom's Implementing Geolocation
>Summary of consultation responses and next steps. Paragraph 3.42 states:
>
>>
>Following the notion that a kill switch should form a core part of the
>protocol, this could be included in a very basic use case like "Hotspot:
>urban internet connectivity service". I can volunteer to make this
>addition in the use case.
>
>Regarding the requirement we could say the database must be able to
>deliver updated channel information to any registered master device. We
>have not specified elsewhere any time constraints on message delivery, I
>wonder if this is needed in this case either.
>
>Kind Regards,
>Scott
>
>> At this stage, we should say that we have a requirement to change
>>availability of spectrum on a short notice, we need a use case that
>>would motivate some decision on what "short" means, and we should not
>>worry about which mechanism we should choose to achieve it.
>>
>> Push, fast poll, and notice broadcast (i.e. a single bit sent to all
>>clients telling them to "phone home" soon) are all reasonable mechanisms
>>to meet the requirements.
>>
>> Brian
>>

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 17:59:27 +0000

I believe we have general consensus to include a requirement for
unsolicited Push notifications/messages to be sent by the white space
device to the master device.
Proposal for requirement in I-D:

-Raj

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 20 Jan 2012 14:08:17 -0500

What Brian and I were saying is that we need a mechanism to deal with
changes to spectrum availability and that push is only one option. I like
the description Brian gave:
"At this stage, we should say that we have a requirement to change
availability of spectrum on a short notice"

---

From: <[email-masked]>
Date: Fri, 20 Jan 2012 19:13:42 +0000

I am okay with your proposal. But the requirement as worded is
specifically tied to a specific usage scenario.
Whereas the Push mechanism could be applied for other reasons as well.

-Raj

---

From: "Malyar, John P" <[email-masked]>
Date: Fri, 20 Jan 2012 14:14:02 -0500

Peter,

I also believe that the description Brian shared is the most flexible way to address the functional need. It gives us an opportunity to review the possible implementations. The way it was recently described by Raj specifies a specific implementation that may/will have significant impact on the master white space device (i.e. is must also be a Server to support notifications). 

Regards,

John