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 On 1/20/12 1:08 PM, "ext Peter Stanforth" <[email protected]> wrote: >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" > > > >On FriJan/20/12 Fri Jan 20, 12:59 PM, "[email protected]" ><[email protected]> wrote: > >> >>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: >> >>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 >> >> >>On 1/20/12 11:50 AM, "ext [email protected]" >><[email protected]> wrote: >> >>>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 protected]" <[email protected]> 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 >>>> >>>>-----Original Message----- >>>>From: [email protected] [mailto:[email protected]] On Behalf Of >>>>[email protected] >>>>Sent: 19 January 2012 19:42 >>>>To: [email protected] >>>>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. >>>>> >>>> >>>>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 >>>> >>>>-----Original Message----- >>>>From: [email protected] [mailto:[email protected]] On Behalf Of >>>>ext Joel M. Halpern >>>>Sent: Thursday, January 19, 2012 11:12 AM >>>>To: Rosen, Brian >>>>Cc: [email protected] >>>>Subject: Re: [paws] next steps for the wg >>>> >>>>Thanks Brian. That works much better for me. >>>>Yours, >>>>Joel >>>> >>>>On 1/19/2012 9:08 AM, Rosen, Brian wrote: >>>>> 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 >>>>> >>>>_______________________________________________ >>>>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 >> >>_______________________________________________ >>paws mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/paws > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
