RE: [emergency] Draft Reply To PPW Letter

["R. Allen Wyke" <emtc@nc.rr.com>]

I have posted this to the IF SC, which is where this discussion needs to
take place (they have the Action Item of looking into transport). Please
keep all future comments and replies there. 

On Mon, 2003-10-27 at 16:22, Kon Wilms wrote:
> >I guess I don't understand why broadcast media would need more than
> >having a binary provided or else the basic information from which to
> >produce a suitable announcement, which we ought to be able to send if
> >it has been generated, with a CAP alert message in a separate
> >payload, such as a SOAP attachment or a second message/email
> >w/attachment or providing an ftp url where it can be downloaded, all
> >of which are as good as, or better than, having it inside the CAP
> 
> Please explain how a broadcast receiver with no way to receive data but the
> broadcast signal can receive data from two-way sources such as email, ftp,
> etc. It cannot. There is no way to 'retrieve' data but to pull it from the
> broadcast signal. The 'internet' delivery model and 'internet' protocols do
> not apply here. Furthermore, most set top boxes do not have code to
> understand any of these protocols. And what do you do when multiple
> broadcast systems are utilized, each with a different transport?
> 
> None of your proposed solutions work. It is obvious, as you said, you don't
> understand.
> 
> >payload message as an inline. Or, we can establish a
> >broadcast-specific policy of sending the binary via their choice of
> >transport, provided there is an available
> >Broadcast-and-Specific-Transport-capable agency/facility/company in
> >our community which can handle that request.
> 
> Payload conversion and transport portability are not the same thing.
> 
> >I don't believe that broadcast needs to do more than announce the
> >emergency message to the public with relevant information and basic
> >instructions for immediate action if needed, and/or information for
> >the public about how to access more specific information in the same
> >way that the emergency broadcast system works now.
> 
> Digital broadcast delivery provides far greater capability than delivery of
> a simple message. Why let that capability go unused? Why are we bothering
> with CAP, if for broadcast purposes we wish to duplicate the existing
> emergency broadcast system. This is illogical.
> 
> >I don't think broadcast is an acceptable method to be sending CAP
> >messages to the Emergency Management community or first responders,
> 
> Our first responsibility, to the public and for the well being of our
> nation, is to save lives and protect property. It is in the public interest
> that emergency messages are delivered over any possible medium in order to
> alert as many people as possible. Are you saying this is not the case, and
> we should be selective about this process?
> 
> >except if it is the only way that the message can get out, which
> >seems somewhat unlikely but not impossible. Broadcast is just not set
> 
> Unlikely? What happened to all those fiber lines on 9/11? In densely
> populated areas, the landlines are usually the first method of communication
> to be destroyed or impeded. No matter the level of destruction to property
> and buildings, a transmitter will still be able to deliver a signal. And
> where a transmitter is destroyed, ones outside of the destruction radius can
> in most cases still reach into the affected areas. Where none of these work,
> uplink/downlink repeater trucks can be deployed. The turnaround time for
> pulling a wire is a lot longer than that of receiving a broadcast signal, or
> switching signals.
> 
> >up to be able to be used as a coordinating medium, nor is radio,
> 
> Broadcast is not the do-all end all for EM coordination. But EM notification
> does not solely involve coordination either.
> 
> >although the public-access cable channels could well serve that
> >purpose. Of course, PBS can also be asked to provide more focused
> >programming related to a given emergency.
> 
> The alert message should be agnostic to the transport layer and indeed
> should also be portable across any transport layer. Your comments are in
> line with keeping the message portable over select transport layers only,
> which defeats the purpose of the message in the first place, and
> inadvertently results in a variety of customized versions of the message -
> none which can interoperate without additional interfacing protocols. The
> end result of which is an unusable message and a message bound by vendor
> lock-in and proprietary systems.
> 
> Broadcast delivery does not mean broadcast delivery to PBS viewers and / or
> television sets. It also means broadcast delivery to any manner of devices,
> be that mobile phones, mobile receivers, digital set-top-boxes, and so
> forth. Not only that, but it includes transport delivery over not only your
> television broadcast signal, but WiFi, GPRS, 3G/MMS, DVB-H/T/X, and so
> forth -- including transporting data between these systems. Broadcast
> delivery is also not a one-to-all mechanism. Data and video delivery can
> easily be targeted to specific users, encrypted for groups, or delivered to
> all.
> 
> I would very much appreciate it if you could illustrate your opinions that
> broadcast EM delivery is indeed unacceptable by pointing to any unsuccessful
> digital broadcast EM trials, studies, or undertakings of any sort.
> 
> I know I can back up my comments with facts - can you?
> 
> Cheers
> Kon
> 
> 
> 
> 
> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
-- 
R. Allen Wyke
Chair, OASIS Emergency Management Technical Committee
http://www.oasis-open.org/committees/emergency