Archive for the ‘Uncategorized’ Category.
Direct Access Storage in 1983 vs 2013
I went back to re-read my master’s thesis from nearly thirty years ago. The basic conclusion that there can be actual diseconomies of scale, as opposed to economies of scale, from centralized control of computing assets has not changed. But the the base numbers are crazy different. My statistics showed that the U.S. Marine Corps had less than 100 Gigabytes of Direct Access Storage spread across 6 different mainframe computer sites in 1983. I bought 6 terabytes for my home last weekend for about $300 dollars. Times have changed. You can find my thesis here.
Web Services Security – A Link to a Really Good Non-Technical Description
Why you should attach security at the message level, not just use SSL.
I found the following today as a good explanation. It goes all the way back to 2005, but the metaphor still works. See: Naked Motorcycle Riding
The National EAS Test and IPAWS-OPEN
Funny thing about the national test held on Wednesday 9 November. It was a test of the old stuff; not the new. IPAWS-OPEN and the Common Alerting Protocol (CAP) were not even part of the test. It worked – with glitches – but it worked. The glitches seemed to be mostly about garbled messages and misinterpreted tones; things that the text and Internet-based IPAWS-OPEN solution are designed to prevent. I am confident that the next test, when it happens, will go MUCH better from that standpoint.
The comments about the national test that were most amusing were the ones that connected the National test with an attempt by the federal Government to “take over the airwaves and the Internet.” The internet was not even used. I am not going to comment on whether the Government wants to regulate (or over-regulate) the Internet. That may, or may not be, depending on your personal political perspective. What I can say his that FEMA’s IPAWS program is absolutely not involved in that sort of activity. Input can come from the president, but it can also come from local authorities at all levels of government using alert origination tools provided mostly by private industry. Dissemination is the same. It is primarily voluntary; using a Government provided query architecture that allows local agencies and information providers to weed out unwanted material, making it the very opposite of a Government forced content push. Finally, the “last mile distribution” is almost completely through commercial providers and/or a very wide variety local government controlled software from the commercial sector. So, while IPAWS is designed to provide a way for the president to get an emergency alert to as many people as possible at one time, its architecture is actually built with local alerting and local control at its very core. Check it out for yourself. I will be at the annual International Association of Emergency Managers (IAEM) convention in Las Vegas next week. Drop by the IPAWS booth to say “hi” and to get a live demonstration. Good stuff.
NIEM Compliant and Not Standards Conforming – Absolutely Possible
There have been at least two situations that I have heard of recently that claim NIEM Compliance and External Standards Conformance in the same breath. While it can be done, neither actually did so. In one case, NIEM elements were mixed into non-NIEM schemas, but the NIEM attributes were removed. This is clearly not the correct approach (although at least NIEM concept re-use was achieved). In another approach, external standard concepts were “NEIMified” in a tool and mixed with NIEM elements in a combined IEPD without the use of adapters. This approach is NIEM conforming, but NOT standards conforming. This approach can claim to use input from existing standards but cannot claim to actually use those standards. Especially, this approach cannot claim to conform to them. I firmly believe in NEIM as a methodology and as an excellent model for concept re-use, but building a NIEM conforming schema is not the same as building a standard. A standard involves acceptance of the exchange schema by a formal standards body or by a wide body of users as a reusable exchange. When you build a NIEM complient IEPD you have 3 options:
1. Build it as a NIEM IEPD and ignore other standards.
2. Build an IEPD and use pieces of external standards but ignore validation or conformance to the the standards that are reused.
3. Build an IEPD with standards conforming components in adapters and add any other needed data using NIEM want list methods or current NIEM elements .
In all three cases, the result is not a standard until it is recognized as one, either de facto or through a recognized standards body. So, the IEPD is just the beginning. Before it becomes a standard, it must be recognized, either by a formal standards body, or through industry dominant re-use.
Bottom line: If you choose path 2, you should not advertise it as standards conforming. While you can claim NIEM Conformance, you cannot honestly claim conformance to the external standards used as input in any way whatsoever.
Upcoming NIEM NTE Presentation – Using NIEM Metadata in an EDXL-DE wrapper to Support IPAWS
If you work with the National Information Exchange Model (NIEM) as well as with other standards, you often run into issues related to how your overall work should incorporate (or not incorporate) NIEM. The rules for NIEM allow you to use recognized external standards independently. FEMA’s Integrated Public Alert and Warning System (IPAWS) does this with it implementation of the Common Alerting Protocol (CAP). You can also use components from an external Standard within a NIEM conforming schema, but only if you use the formally defined NIEM “Adapter” approach. You can also use NIEM inside an externally defined standard wrapper as shown in the graphic below.
My talk at the NIEM National Training Event (NTE) in Philadelphia this August will discuss using an OASIS Emergency Data Exchange Language – Distribution Element (EDXL-DE) as a wrapper as shown, but it will go beyond that. It will show how NIEM conforming data structures can be used within the EDXL-DE wrapper itself as DE conforming metadata to describe the content and desired distribution of the Information Exchange Package (IEP). The goal is to show an innovative use of NIEM that is actually made possible by the (also) innovative structure designed into the EDXL-DE standard. The actual content of the IEP will be an IPAW Profile conforming CAP message. The wrapping DE will use NIEM conforming metadata to define IPAWS distribution and content identification needs.
IPAWS-OPEN Live Demonstration (XML Geeks only)
Live Demonstration, XML Messages To and From
The Integrated Public Alert and Warning System (IPAWS)
Open Platform for Emergency Networks (OPEN) 2.0
Wednesday February 16, 12:00 Noon EasternPlease note: The audio set up for this program has changed per below. In order to check your audio set up, staff member Amy Sebring will be logged in by 11:30 AM Eastern to provide assistance.
IPAWS-OPEN enables the interoperable sharing of emergency alerts and incident-related data between systems that comply with non-proprietary information standards, and serves as the message aggregator for the Integrated Public Alert and Warning System. During our next Webinar, System Architect Gary Ham will demonstrate a live soapUI view into IPAWS-OPEN 2.0 to show XML messages being transmitted to and from the system.
This program is intended primarily for third party IPAWS-OPEN developers and testers. Please make plans to join us via Live Meeting. As always, your questions and comments are welcome.
IMPORTANT: The format of our Live Meeting has changed. The audio portion will be delivered via your computer speakers and no telephone bridge will be provided for attendees. The primary reason for this is to eliminate audio quality problems associated with using a bridge. The Live Meeting client must be used in order to receive the audio. Prior to the program, all attendees are urged to review the revised instructions available from:
http://www.fema.gov/about/programs/disastermanagement/archive/LiveMtgInstruct.pdf(1) Login to MS Live Meeting for visuals: The following login link can only be used 30 minutes prior to the scheduled meeting time:https://www.livemeeting.com/cc/eiip/join?id=DMprogram&role=attend
If you are unable to attend this month’s meeting due to other commitments, a recording will be accessible from FEMA.gov.
Twitter Weekly Updates for 2010-12-26
- Diseconomies of scale in IT. 1 cause: disassociation of the correction of error conditions from those affected by the error. #
- Probably the greatest Geek Christmas comic ever written!!! http://xkcd.com/835/ #
- And do check out the mouse over added comment!!! Particularly if you have ever taken a data structures course. http://xkcd.com/835/ #
CAP For IPAWS – Defining Content Guidance
What have we done to the Common Alerting Protocol (CAP)? In 2003, CAP 1.0 was released a simple, straightforward XML schema for alerting. It was, and is, a great idea and has achieved almost worldwide acceptance. As with any great idea, folks have discovered a need to tweak here and there and to impose their own rules for usage, security, etc. The great thing is that the basic structure remains in tact. The devil, however, remains in the details of implementation in systems throughout the world. We are on CAP 1.2. Europe has adopted CAP 1.1. Canada has published its own CAP Canadian Profile. We, in the U.S., also have the CAP IPAWS profile as an OASIS TC Committee specification and a requirement for broadcast of messages through FEMA’s Integrated Public Alert and Warning System (IPAWS).
I am currently trying to define a document to help CAP message origination software builders build an appropriate message for use in the world of FEMA’s IPAWS. This world includes both “regular CAP” and IPAWS Profile CAP, including its variations (EAS, NOAA NWEM, and CMAS). It is no small task. There are at least seven different documents that need to be “amalgamated” for the purpose (one of which has not even been formalized in writing yet):
- The first is the actual CAP Standard; now version 1.2 (OASIS Common Alerting Protocol, Version 1.2, OASIS Standard, 01 July2010).
- This is modified by the CAP IPAWS profile specification (Common Alerting Protocol, v.1.2 USA Integrated Public Alert and Warning System Profile Version 1.0, Committee Specification 01, 13 October 2009).
- For messages bound for Emergency Alert System (EAS) disseminators there is the CAP ECIG recommendation (ECIG Recommendations for a CAP EAS Implementation Guide, EAS CAP Industry Group – ECIG, EAS-CAP Implementation Guide SubCommittee, Version 1.0, 17 May2010).
- For messages bound for broadcast via NOAA Radio, there are additional rules (National Weather Service Instruction 10-1701, Text Product Formats and Codes, February 12, 2003).
- For messages bound for cell phone broadcast there are rules requires to implement the ATIS/TIA Standard (Joint ATIS/TIA CMAS Federal Alert Gateway to CMSP Gateway Interface Specification, October 2009)
- Originators will also need the documentation for connection to IPAWS-OPEN itself (Federal Emergency Management Agency (FEMA), Integrated Public Alert and Warning System (IPAWS) Open Platform for Emergency Networks (IPAWS-OPEN v2) Web-Service Interface Design Guidance Version 1.2, November 12, 2010). Note: the document is provided to external vendors and programs upon completion of MOA documentation.
- Finally there will be formal rules on originator approval; NWEM and EAS Alert Originator Approval and Permission Procedures for IPAWS COGs (to be published).
My goal is to provide this document in iterations (think beta versions) to IPAWS-OPEN partners with completed MOAs. It will take some time, but, eventually, a formal version will also be published. Your input will be appreciated.
IPAWS-OPEN 2.0 Interoperable Connectivity Underway!
I sent out the first 8 sets of credentials to independent interoperable systems this week. The test environment can now actually be used. Those of you who are familiar with FEMA procedures know what it took. Whew!!!!
For those who may not be totally familiar with IPAWS-OPEN, Check my permanent page on IPAWS.