Re: Authors soliciting comments

["JFC (Jefsey) Morfin" <[e-mail]>]

Dear Fred and Brian,
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
>>[e-mail] 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:
>>         [e-mail].
>>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
>>[phone]
>>
>>EMEA
>>[phone]
>>
>>Japan
>>[phone]
>>
>>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
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>_______________________________________________
>Ietf mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf