RE: [emergency] CAP and Signatures/Encryption

["Bullard, Claude L (Len)" <len.bullard@intergraph.com>]

NIMS sets the doctrine.  NRP sets the protocols, structures, 
and so on.  That is the game.

NIMS says control is local until it is not, then systems 
come on line as requested or as directed from the White 
House.  I don't think they will entertain chaos theory 
during an Incident of National Significance.  

That means to the best of our ability, we eliminate 
variability we can anticipate and put in adaptors where 
we can't.  I do understand the problems of complexity 
and that is why one gets rid of complexity wherever 
possible.  NIMS specifies a doctrine of local control, 
standing systems, and dynamic configuration for a 
limited set of control nodes and players.  NRP names 
the players and the command modes.  I don't 
think it perfect, but it will be reviewed and amended 
yearly.  It also has a very short fuse for initialization. 
It's a good approach.  EDXL and CAP should play very 
well in this system.

The Cursor On Target program of the USAF is working 
very well because it took command and control down 
to the bare bones essentials and spec'd only that. 
CAP stays similarly simple.  I think this committee 
is doing a good job.  GJXDM is a bear because it may 
be too many things in one package.  Likely, someone 
needs to review that.  Possibly, Mike Daconta and 
his folks will do that.

However, they will need a full up exercise somewhere 
in the early part of next year of the late part of 
this year.   The sooner the better.  This has to 
be a simulation of multiple well-timed and coordinated 
but independently executed actions of multiple types. 
The SecDef and SecHLS need to tell the commander in 
chief how well this thing takes a stressful INS. 

len


From: Art Botterell [mailto:acb@incident.com]

Certainly it would be simpler for everyone if civil emergency 
management were a determinate command-and-control system... but we 
all know it isn't.  Particularly in cultures that value things like 
individual responsibility and autonomy, home rule, democracy, free 
markets and property rights, "command" is necessarily more like 
"coordinate," and "control" is often reduced to "cajole" at best.

In fact, thinking about anything beyond very specialized segments of 
emergency management in terms of a "system" may be a bit misleading. 
There's no single aim point as in classic cybernetics.  There's no 
consensus on metrics or on the balance between local and overall 
optimization.  The analogies of grid computing or genetic-algorithm 
software development might be closer fits, but even those don't fully 
reflect the true complexity of the problem.  And that problem isn't 
going to change itself to accommodate our technologies.

Of course, the same adaptability and modularity that let us adapt, 
improvise and overcome in chaos will help us transition smoothly into 
more structured methodologies as they evolve.  In the meantime, we 
need to strike the best available balance between flexibility and 
control.

"We juggle priceless eggs in variable gravity."  Metaphors can be a 
great help in coming to grips with this sometimes-daunting task... 
but we also need to remember that the map is not the territory, nor 
is the model the reality.

- Art



At 3:07 PM -0600 1/27/05, Bullard, Claude L (Len) wrote:
>That means a  Fed push down to the States with a reference 
>architecture.   Work in
>some of the BAAs from HSARPA may instigate that.
>
>Simpler is better.  The USAF Cursor On Target approach is a good 
>one.  When one
>has to pull together a system dynamically scaling out from the command to
the
>area command, as each system comes on line and the locus of command shifts,
>the need for quick set ups dominates the need for expressiveness.
>
>The NRP is a good read.  They thought it through and have a solid 
>plan.  I suspect
>that as in most disaster planning, simulations and exercises will be done.
>
>len
>
>-----Original Message-----
>From: Bob Wyman [mailto:bob@wyman.us]
>Sent: Thursday, January 27, 2005 2:59 PM
>To: Bullard, Claude L (Len); 'Carl Reed OGC'; bob@wyman.us; 'Kon 
>Wilms'; 'Art Botterell'
>Cc: emergency@lists.oasis-open.org
>Subject: RE: [emergency] CAP and Signatures/Encryption
>
>Len Bullard wrote:
>  > Someone will have to pare this down before it has to operate in real
time.
>             I whole heartedly agree! In general, for an effort such 
>as this, options, flexibility, and variety are *bad* things. We 
>should be doing what we can to define a strict protocol that 
>provides very little opportunity for misunderstanding and maximizes 
>interoperability - even if the cost is a potential loss of 
>expressiveness. The more ways there are to do something, the more 
>ways there are to misunderstand. Misunderstandings could cost lives 
>or property.
>             The "normal" rules and customs which encourage 
>flexibility in other communications and applications protocols 
>should not apply to this effort.
>
>                         bob wyman
>
>
>From: Bullard, Claude L (Len) [mailto:len.bullard@intergraph.com]
>Sent: Tuesday, January 25, 2005 11:07 AM
>To: 'Carl Reed OGC'; 'bob@wyman.us'; 'Kon Wilms'; 'Art Botterell'
>Cc: 'emergency@lists.oasis-open.org'
>Subject: RE: [emergency] CAP and Signatures/Encryption
>
>I hope someone is simulating this system.    As I read through the 
>byzantine numbers of
>organizations, protocols, structures and policies that make up the 
>NRP document, and
>try to imagine assembling a just in time interoperating network of 
>networks for C2 given
>an ongoing INS, it makes the problems of 9/11 pale in comparison.
>
>It is one thing to be transport-agnostic; it is quite another to 
>have so many options at
>so many layers that the system simply cannot be operational quickly 
>enough to meet
>the requirements.
>
>Someone will have to pare this down before it has to operate in real time.
>
>len
>
>
>From: Carl Reed OGC [mailto:creed@opengeospatial.org]
>Interesting discussion. I would like to add that are also a number 
>of Internet standards (IETF) that deal with encryption and are used 
>for encrypting messages, such as e-mail. This includes the work of 
>the IETF S/MIME working group, specifically the S/MIME electronic 
>mail security protocol that is widely implemented in commercial mail 
>agents. If you want something a bit more low-level, I would also 
>check out the work of the IPSEC group, specifically RFC 3686 - Using 
>Advanced Encryption Standard (AES) Counter Mode With IPsec 
>Encapsulating Security Payload (ESP). This standard incorporates the 
>NIST standard that defines five modes of operation for AES and other 
>FIPS approved block ciphers [MODES].
>As Bob suggests, rather than the EM TC define a new method of 
>encryption, I would opt for a statement of best practices for 
>encrypting a CAP message using existing, well known industry 
>standards.
>
>Regards
>
>Carl


To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgro
up.php.