Your draft is about the way to warn people of a local danger (like the Tsunami). The AFRAC project may bring some elements in addition to the examples you quote in appendix. We will document them in a later Draft once we have morre practical experience. I copy Area Directors since this documents some of the needs I want to address throug a WG-Tags and some other concepts we currently or work/suggest to work on.
I am interested in comments. We have on 24/01 a BoD meeting where actions on the matter will be decided.
Best regards.
jfc
FIRST NECESSITY INFORMATION
AFRAC (http://afrac.org) is an incorporated non-profit French CRC experimentation. In AFRAC parlance a CRC is a "Common Reference Center". Its purpose is to maintain and store or link the information common to the members of an "externet" so they may call on it when they need it without having to maintain it. This information is to be identified by a crc-tag. An "externet" is understood as all the tiers and external resources sharing a same CRC, as a "class" of the users and a "group" of the resources (these resources can include ONES (open network extended services, a generalization of the OPES, such as the current WG-OPES work on SMTP could be understood).
One can simultaneously belong to many externets. The granularity of the CRCs should be intergoverned in subsidiarity (this means that each CRC is to respect and support the duties of the other CRCs it may relate with, proposing them information they may or not accept - like a sort of authoritative semantic web).
AFRAC started with four main interest/examples with a systematic three phased objective (copy, rebuild, control, as documented in the first example):
- national root - a simple copy of the NTIA root permitting risk containment, sovereign management (stopping intelligence leaks) and critical situation management (in case of a voluntary or accidental disfunction of the root system, in case of a critical national situation calling for a reassignment of the network resources). We maintain the daily http://afrac.org/intlfile.txt to help watching the status of the first level. We also identify the need of a stabilization of a generalized reference naming system to avoid the fragmentation of the name space in a 3rd generation environment (we qualify operator centric systems as 1st generation, network centric as 2nd generation, and user centric as 3rd generation) which will most probably generalize private keyword usage.
The target we assigned ourselves is to document, test and develop a solution and governance permitting any peacemaker to get "hart.sos" in any language resolved at the nearest hospital emergency center, wherever in the world, 24/366, as part of a national public service.
- national geopolitical reference grid (Webs de France) documenting every city, business area, etc to support proximity web sites with a consistent way to reference and sort information. It documents 33.000 French cities, geo location, population, administrative situation, their economic zone, and provides algorithm to tell what is the nearest agency of any security, business, health, non-profit, recreational, etc.. network, etc.
- language support, to provide first a cross-reference center for the various forms and usage of the French language and of the languages of France (there are more than one hundred languages and dialects). This work is now investigating a "CulturaMundi" program to tag and document all the cultures, languages, music, arts, history, etc;
- first necessity information: this is understood as a local formatted "in the air" information string, giving in real time the life-saving/vital information. This may be accurate weather information and alerts, hospital emergency bed availability, road accidents, traffic patterns, DoS information, security/military warning, etc. This is obviously related to the three objectives above.
In this we capitalized on the work achieved at the DNSO/BC (Business Constituency) when I proposed ICANN to work on an ICP-4 network security document, and on the draft presented by Kathleen Morriarty on DoS alerts. The need of a "red telephone" between ISPs and of an alert to users were among the propositions.
However we have not advanced as much as we hoped on these matters because we have met different architectural problems, in particular due to the extensive use of HTTP.1.1 and the lack of easy support of multilingualism, of the lack of tagging standards (ex. recent debate on langtags), of the ICANN/ccTLD real live root support, of the delay in IPv6 deployment, of the lack of work in TV support on Teletex (which should be an ideal ubiquitous and free vehicle for first necessity information), of the delay in getting digital convergence, etc. and of lack of semi-industrial interest at this stage - while the industrial market should be extremely important.
The first and urgent need we have is to define a tagging system that we can use to designate and a what, where, by who format. For obvious security and cost/deployment reasons we need it to be as universal as possible. Obviously a consistent geoallocation of the IPv6 addressing would permit to sort the infos for global alerts.
One of the conclusions is certainly to switch as much as we can to a third generation (user centric) approach and to give the users a real "corebox" control panel. The word "corebox" has been coined by analogy to "middlebox" to identify the real core of a user's global management of his own global vision of the digital continuity and of the externets he belongs to. This may be a real machine (a Linksys Wi-Fi, a French Freebox (Free) or Livebox (France Telecom) are typical examples with extended software or a $ 100 QNX PC) or a virtual concept embodied behind its control panel (which can be a FireFox plug-in) supported by regular mail retrievals (1st generation, client), as a peer to peer (2nd generation, peer) or as a 3rd generation standalone smart gateway. This support can also be assumed by an OPES which will insert the first necessity information in an existing HTTP or SMTP data stream, the only change on the user side being a filtering of the entries.
In the scheme you describe, the information is sent to the CRCs of the various national, local, private, cultural, etc. externets which are permanently scanned (and used) by users' coreboxes at different layers (filtering of the data stream, OCP of their resident OPES) - in the AFRAC planned context shows that a national CRC could be associated to the ccTLD (as one of the community services). The main problem is the automatic sorting of the information. It should result from the tagging, the author of the information being the default authority. This authority must obviously be part of the tagging.
The resulting info size can be extremely reduced (one bit in the first necessity info datagram) - in critical emergency cases, scarce resources must not be loaded by warnings and left to real operational exchanges (the bit will trigger an emergency collection). This means a "TTK" (Time to Know) very reduced as the alert itself (call emergency information source) can pass in seconds. Various coreboxes can react very fast, for example in calling an http://xxx.sos site (we think to add to the root an .sos TLD - probably with a null TTL - routed to a local server: to be for http://test.sos to know the date/version of the root one uses and test the alarm system).
Another key element is that this signaling can trigger appropriate reaction by the alerted systems. For example, telemates (automated remote hardware/software actors, such as camera, sound alarms, automated doors, traffic light, level of security in an application, etc. etc.) can call their own group of supervisory systems (in emergency cases, there must be several supervisors with several IP addresses on several ISPs - what may require an ISP rotation solution not to overload a small CPU with complex procedures).
The speed and the constant verification of the alarm system permits to dedicate some seconds to cross check the source of the alarm and in adjusting the information presentation (using/updating HTML presentations - knowing that OCP, SMTP, FTP information has already been sent, is a way to tranquilize the populations).
This kind of alarm dissemination system is of interest because it scales very simply through alarms/CRC subscription. In a way it is similar to police frequencies that everyone CAN listen.
Obviously this kind of warning system applies to every kind of information. You thought about major/critical risks. Security breaches, antivirus alarms (update you anti-virus), DoS, are also concerned. Solutions to authenticate the origin of an alarm will certainly get a good users/Govs image and will be appealing to CIOs. etc.
At 23:09 11/01/2005, Fred Baker wrote:
Date: Tue, 11 Jan 2005 15:36:10 -0500 Subject: I-D ACTION:draft-baker-alert-system-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Structure of an International Emergency Alert System
Author(s) : F. Baker, B. Carpenter
Filename : draft-baker-alert-system-00.txt
Pages : 19
Date : 2005-1-11
The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-alert-system-00.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request@xxxxxxxx with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-baker-alert-system-00.txt".
A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to: mailserv@xxxxxxxxx In the body type: "FILE /internet-drafts/draft-baker-alert-system-00.txt".
NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------- CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------- In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email.
This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved.
Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows:
"CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
For further reference information about viruses and email antivirus efforts within Cisco, please visit:
http://wwwin.cisco.com/it/ems/services/antiviral
If your concern isn't addressed by the information in this notification or the above web page, you may open a support request:
http://wwwin.cisco.com/support/
Select "Messaging", "Email-Related", "Mail Routing"
Please include in the text of your case the following information:
* Full headers of the message. Documentation on displaying the full headers is available at this URL:
http://wwwin.cisco.com/support/library/faqs/solution002471.html
* This unique quarantine identifier: j0BLINWG015337
If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue.
Americas: 1 408 526 8888
Asiapac +61 2 8446 8888
EMEA +31 20 485 4888
Japan +81 3 5549 6888
US (Toll Free) 1| 800| 888| 8187| (ext.68888)
Thank you for your cooperation,
Enterprise Messaging Services Cisco Systems, Inc _______________________________________________ I-D-Announce mailing list I-D-Announce@xxxxxxxx https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf