[CAP] Presidential CAP questiion
matt hoffman
matthoffman at acm.org
Mon Oct 15 15:24:29 PDT 2007
David,
I don't necessarily disagree with you. I don't mean to start a debate
about whether the standard *ought* to empower event sources to dictate
how the alert is treated. I only mean to say that, as I understand the
current EAS and the FCC rulings about it, broadcasters are required to
interrupt their broadcast to carry EAN ("Presidential") messages in
audio form -- thus, preemption is currently a requirement. You are
arguing that broadcasters currently have many ways of presenting data to
the public, and I agree with you. From a technical standpoint, I'd argue
that if the policy remained that the President must be able to directly
broadcast across the nation in real-time, in the spirit of the EAN, then
preemption would still be required for broadcasters. But if you're
arguing that direct, audio preemption is not necessary for getting
information across, and that broadcasters should be able to choose what
means are necessary for disseminating alerts, I won't argue with you.
That's a policy decision, not a technical one.
You are no doubt are more informed than I about the current status of
DEAS requirements, so perhaps such requirements have already been
dropped for the various DEAS candidates. And my understanding of the
current system is certainly limited. The original poster was only
asking, if I understood, whether such EAN messages, which are currently
required to be preemptive, were currently available in CAP -- or other
text -- format.
Matt
David Aylward wrote:
> Matt:
>
> Your "single channel" concept is a much more limited view of
> broadcasters than I think we should have. At least television, and
> often radio, broadcasters have multiple channels of communication to the
> public.
>
> Certainly, priority is an issue if you want real time communication of
> voice, video (and data), i.e. a presidential speech. But I thought we
> were talking about CAP messages.
>
> Any TV station worth its salt will be registered wherever it needs to be
> (or polling relevant servers constantly) to get every
> alert/warning/incident report affecting its area. It can use those
> warnings in news broadcasts, crawls across the bottom of the screen,
> list them all on its website, sent out all or some of them to those who
> have registered for news alerts on its website. It can devote one of
> its 4-5 digital channels to full time reporting on a disaster(s), while
> mentioning other incidents on its other channels.
>
> As to Presidential priority, I not sure we should always assume that the
> top person in the hierarchy has the most important message. How can
> the President or anyone other than people in Topeka know the relative
> importance of a flood warning requiring evacuation of Topeka in the next
> 24 hours versus a chlorine spill on Main Street right now? And it's not
> like we have to force TV stations to broadcast alerts and news about
> emergencies!
>
> I think we should focus on the standards (e.g. CAP) and architecture for
> getting warning and alert messages to the systems that reach the public,
> and then let the systems and their customers sort out what is important
> to them.
>
>
>
>
>
> David K. Aylward, Director
>
> COMCARE - Emergency Response Alliance
>
> 1701 K Street NW Fourth Floor
> Washington, DC 20006
> Telephone: 202.429.0574 ext. 201 202.255.3215 (mobile)
> 202.296.2962 (fax)
> daylward at comcare.org
>
> This communication is intended for the use of the recipient to which it
> is addressed, and may contain confidential, personal and/or privileged
> information. Please contact us immediately if you are not the intended
> recipient of this communication, and do not copy, distribute, or take
> action relying on it. Any communication received in error, or subsequent
> reply, should be deleted or destroyed.
>
>
>
>
> -----Original Message-----
> From: cap-list-bounces at lists.incident.com
> [mailto:cap-list-bounces at lists.incident.com] On Behalf Of matt hoffman
> Sent: Monday, October 15, 2007 4:39 PM
> To: Rex Buddenberg
> Cc: cap-list at lists.incident.com; Art Botterell
> Subject: Re: [CAP] Presidential CAP questiion
>
> Agreed, you point out very well why preemption doesn't really apply in a
>
> packet-switched network, but the destination systems are still very
> likely to have that need, correct? TV and radio broadcasts are just as
> single-channeled as they ever were. So a Presidential message, while
> not needing to preempt other messages at the router level, would have
> enough priority to be handled differently at the broadcast level
> (potentially pre-empting other broadcasts, if the current model is
> followed) as well as being treated favorably at the server level, using
> priority queuing techniques as you mention.
>
> So, from the network perspective, we can say "high-priority" instead of
> "pre-empting", but from the broadcasters' point of view, "pre-empting"
> still applies.
> The original poster, if I read him correctly, was asking whether there
> was a source of messages that were of that highest priority that would
> cause broadcasters to interrupt current broadcasts, as per the various
> Executive Orders. The details of how the message gets from the source
> to the destination needn't apply.
>
>
> Rex Buddenberg wrote:
>
>> I think the question really has to do with the nature of packet
>> switching and the archaic circuit switched notion of pre-emption.
>>
> (With
>
>> Presidential as just one instantiation)????
>>
>> In circuit-switched networks, a channel can carry only one application
>> at a time. Which translates to user terms of 'gotta hang up on one
>> conversation to pick up another'. Pre-emption is a means of forcing
>>
> the
>
>> first conversation to close so one can barge in with the second. In
>>
> the
>
>> interior of the network, pre-emption is represented by a parallel
>>
> 'grab
>
>> the circuit'. In abstract terms, circuit switched networks are
>> connection-oriented.
>>
>> But in packet switched systems things change. Packets arrive at
>>
> routers
>
>> from multiple applications in no particular order or organization.
>> Layer 3 plumbing in the internet is expressly connectionless and
>> stateless. Therefore, pre-empting' a connection makes no sense --
>>
> there
>
>> aren't any. (*more below)
>>
>> This doesn't translate quite as intuitively to end system
>>
> applications.
>
>> It may make sense to interrupt one human conversation to get a
>> converser's attention. But this has nothing to do with the underlying
>> plumbing any more.
>>
>> There was a working group in IETF a few years ago thrashing emergency
>> services issues. Great amounts of flame and heat trying to get some
>>
> of
>
>> the members to understand that 'pre-empt' belonged in places like SIP
>> servers, not routers.
>>
>>
>>
>>
>> *in most of the internet infrastructure, there's enough
>>
> overprovisioning
>
>> that fiddling with packet priorities within a router makes no sense
>> either -- there's nothing you can do to 'improve' service if there's
>>
> no
>
>> congestion. The place where this does become important is at the
>>
> parts
>
>> of the internet where we reach to mobile platforms -- the radio-WANs.
>> But that's a different conversation, so I won't chase it here unless
>> somebody rings back (it's my research area). Here the issue is not
>> pre-emption in the customary sense, but a packet prioritization sense
>> where 'the most important packets get handled first'. The definition
>>
> of
>
>> 'most important' is always disputed along with the means of marking
>> packets with appropriate labeling.
>>
>>
>>
>> On Mon, 2007-10-15 at 14:16 -0400, matt hoffman wrote:
>>
>>
>>> Art is certainly the authority on this, but I'll second that
>>>
> impresson.
>
>>> I've worked on IPAWS-related prototypes implementing CAP interfaces,
>>>
> but
>
>>> I have never heard mention of any system that disseminated
>>>
> Presidential
>
>>> messages via anything other than the existing EAS framework.
>>>
>>> Matt
>>>
>>>
>>> Art Botterell wrote:
>>>
>>>
>>>> Jim -
>>>>
>>>> I can't speak for FEMA, but I would expect that presidential
>>>>
> messages will go from WACA to FEMA for distribution through the IPAWS
> framework to EAS, cellular and other dissemination media. Of course,
> presidential alerts have been, to date, vanishingly rare.
>
>>>> - Art
>>>>
>>>>
>>>> Art Botterell, Manager
>>>> Community Warning System
>>>> Contra Costa County Office of the Sheriff
>>>> 50 Glacier Drive
>>>> Martinez, California 94553
>>>> (925) 313-9603
>>>> fax (925) 646-1120
>>>>
>>>>
>>>>
>>>>
>>>>>>> "Jim Trawick" <JimTrawick at viaRadio.com> 10/15/2007 7:45 AM >>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> Although there's been a lot of talk about the Presidential messaging
>>>> possibilities in DEAS and at least three different versions of what
>>>>
> that
>
>>>> might be (PBS, NOAA and DHS variations, that I'm aware of), is
>>>>
> anyone aware
>
>>>> of a specific, currently available Presidential source (i.e.,
>>>>
> pre-empting
>
>>>> all others, even those in progress, per various Executive Orders),
>>>>
> which is
>
>>>> available in CAP format (or any other digital, text-oriented
>>>>
> format), and if
>
>>>> so, what that current source might be, and through whom it might be
>>>> currently available? Surely one must have been employed in the DMIS
>>>>
> EAN test
>
>>>> back in June.
>>>>
>>>>
>>>> Jim Trawick
>>>> Senior Software Engineer
>>>> viaRadio Logo Scaleable smaller no tag no background
>>>> This list is not for announcements, advertising or advocacy of any
>>>>
> particular program or product other than the CAP itself.
>
>>>> _______________________________________________
>>>> This list is for public discussion of the Common Alerting Protocol.
>>>>
> This list is NOT part of the formal record of the OASIS Emergency
> Management TC. Comments for the OASIS record should be posted using the
> form at
> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergen
> cy
>
>>>> CAP-list mailing list
>>>> CAP-list at lists.incident.com
>>>> http://eastpac.incident.com/mailman/listinfo/cap-list
>>>>
>>>> This list is not for announcements, advertising or advocacy of any
>>>>
> particular program or product other than the CAP itself.
>
>>>>
>>>>
>>> _______________________________________________
>>> This list is for public discussion of the Common Alerting Protocol.
>>>
> This list is NOT part of the formal record of the OASIS Emergency
> Management TC. Comments for the OASIS record should be posted using the
> form at
> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergen
> cy
>
>>> CAP-list mailing list
>>> CAP-list at lists.incident.com
>>> http://eastpac.incident.com/mailman/listinfo/cap-list
>>>
>>> This list is not for announcements, advertising or advocacy of any
>>>
> particular program or product other than the CAP itself.
> _______________________________________________
> This list is for public discussion of the Common Alerting Protocol.
> This list is NOT part of the formal record of the OASIS Emergency
> Management TC. Comments for the OASIS record should be posted using the
> form at
> http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emergen
> cy
> CAP-list mailing list
> CAP-list at lists.incident.com
> http://eastpac.incident.com/mailman/listinfo/cap-list
>
> This list is not for announcements, advertising or advocacy of any
> particular program or product other than the CAP itself.
More information about the CAP-list
mailing list