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 protected]] Sent: 20 January 2012 03:24 To: Sago,AJ,Andy,COD R Cc: [email protected]; [email protected] 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 On Jan 19, 2012, at 4:33 PM, <[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
