From internet-drafts@ietf.org Mon Mar 12 12:02:53 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121F721E8080; Mon, 12 Mar 2012 12:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjZIHc5Jjgrz; Mon, 12 Mar 2012 12:02:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9734621E8067; Mon, 12 Mar 2012 12:02:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312190252.20304.18681.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 12:02:52 -0700 Cc: atoca@ietf.org Subject: [atoca] I-D Action: draft-ietf-atoca-requirements-03.txt X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 19:02:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Authority-to-Citizen Alert Working Gr= oup of the IETF. Title : Requirements, Terminology and Framework for Exigent Comm= unications Author(s) : Henning Schulzrinne Steve Norreys Brian Rosen Nokia Siemens Networks Filename : draft-ietf-atoca-requirements-03.txt Pages : 16 Date : 2012-03-12 Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atoca-requirements-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-atoca-requirements-03.txt From rbarnes@bbn.com Fri Mar 30 04:32:43 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AFE21F8688 for ; Fri, 30 Mar 2012 04:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48T7rjUrHNLm for ; Fri, 30 Mar 2012 04:32:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9335A21F8652 for ; Fri, 30 Mar 2012 04:32:42 -0700 (PDT) Received: from [128.89.255.55] (port=63273 helo=neutrino.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SDa4B-000Esp-2Q for atoca@ietf.org; Fri, 30 Mar 2012 07:32:27 -0400 Message-ID: <4F7599D8.1010107@bbn.com> Date: Fri, 30 Mar 2012 13:32:40 +0200 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: atoca@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:32:43 -0000 Hey all, As I said in the meeting today, I've put together a proposed mechanism for discovering alert servers. Much like Brian said today, it's based on HTTP, but can bootstrap out of DHCP and/or LoST. Alert Metadata Protocol (AMP) Reviews welcome! Thanks, --Richard From artbotterell@gmail.com Fri Mar 30 10:40:26 2012 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A80721F870F for ; Fri, 30 Mar 2012 10:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwCEa5Z3Z1h3 for ; Fri, 30 Mar 2012 10:40:25 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9895521F869E for ; Fri, 30 Mar 2012 10:40:25 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2050963pbb.31 for ; Fri, 30 Mar 2012 10:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EOzc/ma7sdbA/233z27WzNk5C1itj9+s0XUZcrjQkdU=; b=V7rPZ+TQA7YEWYlUc6lCEWYKgSE4Tp69UGSePITZps+LM4ID556ieOsBYmapE7WHlL kbF2kHDBPhBEaw7hGhGBTCKfbNMsjGvK1UwTYQBtIR39fRI1yirD4WYW6eL6+61eiwum sZxemY1q70BtcE8rRLnHUaR5KqQRjMxrZffhNTX9lUjAoc0G+UPUYE1c3bi0Q+sP6D+P qTwXGmQFXr0gWU4ccaS6LRPKU3Z0j8pyNZh8RdVxmLfF0v8Mmv6X7rx57+6nyM8W8cb2 HCrEzuiVOB2xzGwont6pFuxEGq9+WCaLxpIRioqcJgwapm8jpUCvfzcmrMnCbWWERvUL AkXQ== Received: by 10.68.201.201 with SMTP id kc9mr11488157pbc.50.1333129225431; Fri, 30 Mar 2012 10:40:25 -0700 (PDT) Received: from [10.0.1.37] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id v6sm7809168pbu.41.2012.03.30.10.40.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 10:40:23 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: <4F7599D8.1010107@bbn.com> Date: Fri, 30 Mar 2012 10:40:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <351A6DE9-1BC4-48D4-A8FE-1738F8657EE1@incident.com> References: <4F7599D8.1010107@bbn.com> To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1257) Cc: atoca@ietf.org Subject: Re: [atoca] Discovery mechanism X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 17:40:26 -0000 This strikes me as a very worthwhile project. A couple of quick notes: 1) Might the definitions section include a definition for an "alert = source"? If only to disambiguate between the function of the AMP server = and an actual alert "feed" or whatever? 2) If I'm reading this correctly it seems like all we're attempting so = far is to get from a general domain to a specific alert source URL. = Useful, I suppose... although it seems much the same thing could be = achieved by conventionalizing a prefix like "alerts." (on the pattern of = "www." for http servers... but why stop there? Wouldn't it be useful to = enable folks to discover alert sources serving a geospatial location or = polygon? And/or sources that provide certain types of information, as = per the CAP "category" element? 3) Does the proposed discovery mechanism provide information as to the = specific protocol, access controls, etc. implemented by a particular = alert source? E.g., many of the interfaces are ATOM or RSS feeds, but = some are in the form of various styles of web service queries. 4) I'm confused a bit... and maybe this is related to #3... by the = inclusion of the Alert type message. Is it intended that the discovery = system also serve as a pub/sub broker for actual alerts? Seems like = that's a bit of a drift from the core... and IMHO, crucial... function = of alert source discovery. And possibly a bit of an overlap with what = Google's doing at http://alert-hub.appspot.com/ ? Apologies if I'm asking anything too ignorant here. Again, I think the = basic question of discovery mechanisms is really important. - Art On Mar 30, 2012, at 4:32 AM, Richard L. Barnes wrote: > Hey all, >=20 > As I said in the meeting today, I've put together a proposed mechanism = for discovering alert servers. Much like Brian said today, it's based = on HTTP, but can bootstrap out of DHCP and/or LoST. >=20 > Alert Metadata Protocol (AMP) > >=20 > Reviews welcome! >=20 > Thanks, > --Richard > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca