From hannes.tschofenig@gmx.net Sat Jan 14 01:18:56 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 7571D21F863D for ; Sat, 14 Jan 2012 01:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 CZWcXCDx58C0 for ; Sat, 14 Jan 2012 01:18:56 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7C0DC21F863B for ; Sat, 14 Jan 2012 01:18:55 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 09:18:54 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp055) with SMTP; 14 Jan 2012 10:18:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+KG1e9fD+pHwyF/q0+wIW2qe1YfXmNivqG2m07S ZTdgBq2g21Olqj From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Jan 2012 11:18:52 +0200 Message-Id: <29AAD277-1C5F-45BF-8C57-8135990378EC@gmx.net> To: Randall Gellens , atoca@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [atoca] Action Items from the Taipei Meeting 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: Sat, 14 Jan 2012 09:18:56 -0000 Hi all,=20 I have just looked at the meeting minutes from the Taipei meeting and = noticed that Randy was the action item to review the = requirements/framework document. Randy, when do you think can you take a look at it or do you want to do = that during a WGLC? Ciao Hannes PS: Brian had sent his use cases to the list; that action item is = closed.=20= From hannes.tschofenig@gmx.net Sat Jan 14 01:26:09 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 B946B21F85AF for ; Sat, 14 Jan 2012 01:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 Ea7YmzCNXRPr for ; Sat, 14 Jan 2012 01:26:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C15CA21F8577 for ; Sat, 14 Jan 2012 01:26:08 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 09:26:07 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp069) with SMTP; 14 Jan 2012 10:26:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+rRRFlGh+r+bsPMI6f4telztMIneHrMSXdBOC+17 oN5R6YvIMWkjwC Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 14 Jan 2012 11:26:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Randall Gellens X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] draft-ietf-atoca-requirements-02.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: Sat, 14 Jan 2012 09:26:09 -0000 Hi Randy,=20 I just found this mail. This may be your promised review. Is it? On Nov 18, 2011, at 7:32 AM, Randall Gellens wrote: > I've read though the draft, and I think it needs to clearly identify = the problems to be solved. I'd suggest a new sub-section in the = Introduction to very briefly lay out the major types of use cases (e.g., = national emergencies, local events), and a new section before = Terminology to define the problems to be solved, ideally with a small = number of example use cases. Do the use cases Brian sent to the list address your feedback?=20 >=20 > Also, the document should be higher-layer and not dive into CAP and = other lower-level details. CAP is only mentioned twice in the document and that does not seem to be = too far fetched given that the charter says we are using it.=20 However, I could soften the language a bit, such as=20 FROM: Alert Delivery: In this step the alert message is distributed to one or multiple Receivers. The Receiver as a software module that presents the alert message to the Receipient. The alert encoding is accomplished via the Common Alerting Protocol (CAP) and such an alert message contains useful information needed for dealing with the imminent danger. TO: Alert Delivery: In this step the alert message is distributed to one or multiple Receivers. The Receiver as a software module that presents the alert message to the Receipient. The alert encoding may be =20 accomplished using Common Alerting Protocol (CAP). An alert message contains useful information needed for dealing with the imminent danger. FROM: With the usage of CAP these alert message content requirements are delegated to the authors and originators of alerts. TO: The requirements for the alert content are with the authors and the=20= originators of that alert rather than with the distribution system = itself.=20 Also, during the meeting someone said that I should replace LoST with = discovery.=20 That's fine in some sense but I don't want to be super abstract so that = nobody=20 understands the intentions anymore.=20 > Finally, I strongly recommend NOT using the term Message Handling = System (MHS) as this has specific meaning already. What terminology do you suggest?=20 Ciao Hannes >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > You are wise, witty, and wonderful, but you spend too much time = reading > this sort of trash. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From hannes.tschofenig@gmx.net Sat Jan 14 01:38:14 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 A01B521F85E7 for ; Sat, 14 Jan 2012 01:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 HlxmezOtL+VI for ; Sat, 14 Jan 2012 01:38:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1DAA221F85D4 for ; Sat, 14 Jan 2012 01:38:12 -0800 (PST) Received: (qmail invoked by alias); 14 Jan 2012 09:38:10 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp063) with SMTP; 14 Jan 2012 10:38:10 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/HLAYWSRLH3D39x8/JiGbWNOc3qPR6m1QV+U1IWN aZR9KW9M4Afq96 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <2A85B59A-913B-4340-8C26-F938C3152F62@neustar.biz> Date: Sat, 14 Jan 2012 11:38:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1867C285-B927-4318-87F5-9851F4DEC06D@gmx.net> References: <6E44DEC6-5B9A-4214-9A44-D7C45FDB4449@neustar.biz><201111180536.pAI5aa7P007978@mtv-core-4.cisco.com><8C9312A2-CF99-46D3-B174-5959A3D11C18@neustar.biz> <1B6A274DF90F4579BB875EBD53F8311B@OfficeHP> <2A85B59A-913B-4340-8C26-F938C3152F62@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "atoca@ietf.org" Subject: Re: [atoca] My use cases 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: Sat, 14 Jan 2012 09:38:14 -0000 Hi Brian, Carl, Marc, Richard, Randy James, =20 if someone of you wants to collect text about the various different = detailed use cases that's fine with me. I do, however, not see the need = in our case.=20 In Section 3 of = http://tools.ietf.org/html/draft-ietf-atoca-requirements-02 I have = currently listed a few examples to motivate the requirements for the = underlying transport protocols. These are: a) Point-to-Point Delivery of Alerts, and=20 b) Multicast/Broadcast Alert Delivery I don't see what the impact for an alert transport when a national = authority vs. local authority approves the distribution of the warnings.=20= I also do not see how the opt-in matters in many cases either, unless it = has an impact for the protocols. So far we have a few requirements = listed in Section 4.2 "Requirements for Alert Subscription" that IMHO = covers the relevant aspects.=20 What the uses cases, however, show is that there are two types of = communication protocol classes, namely one that uses unicast delivery = and a second one that relies on broadcast delivery. This is, btw, also = supported by Richard's protocol strawman proposal. It seems to design a = new protocol from scratch for (a) and (b).=20 This is also what the current document talks about. Ciao Hannes On Nov 20, 2011, at 5:10 PM, Rosen, Brian wrote: > The use cases we are looking for now define our scope. >=20 > I have no problem with gleaning what we can from other's work. >=20 > I do think we have tried to include use cases beyond what is = traditionally defined as authority to citizen alerting. >=20 > Right at the moment, we're mostly checking to see that we agree on = scope. >=20 > Brian >=20 > On Nov 18, 2011, at 11:16 AM, Carl Reed wrote: >=20 >> For argument sake, should this group be defining alert use cases or = should we be seeking well known, established and documented use cases? I = suspect that many nations and jurisdictions have already defined use = cases based on knowledge and requirements from the EM community. >>=20 >> Many are described in the ISCRAM proceedings: >> For example: = http://www.iscram.org/ISCRAM2009/papers/Contributions/167_CAP-ONES%20An%20= Emergency%20Notification%20System_Malizia2009.pdf >>=20 >> And of course the US Government: >> http://www.fema.gov/library/viewRecord.do?id=3D3999 >> = http://clarus.meridian-enviro.com/nwpassage/files/NWPassage_ClarusUseCaseS= cenarios.pdf >>=20 >> And I know, based on discussions with the alerting community in = Canada as part of ongoing CAP work, that are some excellent use cases = defined by the Canadian alerting community. >>=20 >> And of course a variety of international activities such as those in = GEO, WMO, and INSPIRE: >>=20 >> For example: = http://www.wmo.int/pages/mediacentre/factsheet/Earlywarning_en.html >>=20 >> Cheers >>=20 >> Carl >>=20 >>=20 >> -----Original Message----- From: Rosen, Brian >> Sent: Thursday, November 17, 2011 11:20 PM >> To: Randall Gellens >> Cc: atoca@ietf.org >> Subject: Re: [atoca] My use cases >>=20 >> I think that the ISPs know who the local/regional/state/national = authorities are, and can provide their credentials to endpoints. I = think "discovery" of an enterprise alert server is probably more = conventional domain based and the act of subscribing establishes the = credential exchange. While you don't really need object security for = that case, I think we have it anyway for the broadcast case. >>=20 >> It's not a bad idea to have object security. I'm not sure we really = want to use some form of transport security if we have a good object = security model. >>=20 >> So you get the credentials of the notifiers from the distribution = point, and the objects are secured with those credentials. >>=20 >> Brian >>=20 >> On Nov 18, 2011, at 1:01 AM, Randall Gellens wrote: >>=20 >>> At 12:48 AM -0500 11/18/11, Brian Rosen wrote: >>>=20 >>>> I think that there is no difference we care about between a >>>> national authority and a regional or local authority save the >>>> notion that we can have all of them. So whether it's a NOAA >>>> weather alert, a state AMBER alert, or a local hazmat alert, they >>>> have the same properties =3D broadcast for the geographic area they >>>> affect with no opt-out, opt-in sub/not out of the area. >>>>=20 >>>> I think that once you get beyond the notion of government >>>> authority, you are into something I class as "enterprise", and you >>>> are likely in the sub/not opt-in only arena. What differentiates >>>> these use cases is that they come from a distribution point that >>>> isn't tied to your ISP. >>>=20 >>> So, the authorization for an alert in the case of government is up = to >>> the ISPs in an area within the jurisdiction? And for >>> enterprise/organizational alerts, presumably the alert servers are >>> federated and have local authorization? >>>=20 >>> --=20 >>> Randall Gellens >>> Opinions are personal; facts are suspect; I speak for myself = only >>> -------------- Randomly selected tag: --------------- >>> I'm prepared for all emergencies but totally unprepared for >>> everyday life. >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From brian.rosen@neustar.biz Fri Jan 27 10:24:04 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 09B3F21F8650 for ; Fri, 27 Jan 2012 10:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.236 X-Spam-Level: X-Spam-Status: No, score=-5.236 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] 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 Z6HgIbAtCy5C for ; Fri, 27 Jan 2012 10:24:03 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5200821F8617 for ; Fri, 27 Jan 2012 10:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1327688645; x=1643029705; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=562gaK2iRb/gab2vC0OBi andeVL+IQZqIHnIlDHM7FM=; b=ZQ+cMhJYWytBTuG0mq8wkkjm/Z2ipYSh7cebL rdePlJOTAFgwxhq5GgtWPrgjpO0OAmmATxsuSJ/XhbGQBLX0A== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.4021681; Fri, 27 Jan 2012 13:24:04 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 27 Jan 2012 13:23:57 -0500 From: "Rosen, Brian" To: "atoca@ietf.org" Date: Fri, 27 Jan 2012 13:23:55 -0500 Thread-Topic: Discovering Alert Servers in draft-barnes-atoca-meta-01 Thread-Index: AczdINStMxkO9Og6RXS159OTPHXIYA== Message-ID: <45BA1851-4689-4704-A84D-8C409286C52B@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: a3fcw4wZzK4j6yDl1vP4sg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [atoca] Discovering Alert Servers in draft-barnes-atoca-meta-01 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, 27 Jan 2012 18:24:04 -0000 Richard proposes to essentially duplicate LIS discovery as the way to disco= ver a local alert server. In notes, he suggests that other mechanisms migh= t be used, specifically, LoST, with a new Service URN. I would like to argue that using LoST is preferable. First I want to note that -meta asks the client to send it's location, and = uses a REFER mechanism to handle out of area requests to the alert server. = This means that alert servers have to be set up in some way to learn about= other servers so appropriate referrals can be made. This duplicates the "= forest guide" mechanism in LoST. I am particularly interested in the "send me alerts where my daughter is" p= roblem. With the mechanism as defined, I would discover my local alert ser= ver, send it a registration with my daughter's location, and have it send m= e a REFER in the case where my daughter is not in the same area area served= by my local sever. With LoST, I would query LoST with a new service URN, and include either my= own location or my daughters, to discover the alert server I should send m= y registration to. I think it makes more sense to just re-use LoST than create a new array of = servers with the connections between them to handle out of area registratio= ns. Also, I note that -meta and all the associated drafts uses terminology inco= nsistent with our requirements, framework and terminology document. We sho= uld decide how to name the entities and be consistent. Brian= From sob@harvard.edu Sun Jan 29 15:39:47 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 F042121F84F9 for ; Sun, 29 Jan 2012 15:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 9tNEfj9LtQms for ; Sun, 29 Jan 2012 15:39:47 -0800 (PST) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9F39E21F84EA for ; Sun, 29 Jan 2012 15:39:46 -0800 (PST) Received: from exchange.university.harvard.edu (unknown [10.35.2.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 348FEE908B for ; Sun, 29 Jan 2012 18:39:46 -0500 (EST) Received: from ENTWHUBT0000002.university.harvard.edu (192.168.36.23) by ENTWEDGE0000001.university.harvard.edu (10.35.2.152) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 29 Jan 2012 18:39:31 -0500 Received: from ENTWEXMB0000004.university.harvard.edu ([169.254.3.202]) by entwhubt0000002.university.harvard.edu ([192.168.36.46]) with mapi id 14.01.0355.002; Sun, 29 Jan 2012 18:39:45 -0500 From: "Bradner, Scott" To: "atoca@ietf.org" Thread-Topic: streaming as a worry Thread-Index: AQHM3t9GDJVKSNlmkku691FOd/9Prw== Date: Sun, 29 Jan 2012 23:39:43 +0000 Message-ID: <23B186E2-E667-4F5F-9613-B1AAD2348593@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.166.5.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <83EAEA49833686459B244578037B607F@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [atoca] streaming as a worry 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: Sun, 29 Jan 2012 23:39:48 -0000 the pundits are starting to understand that broadcast TV will not be a reli= able way to distribute alerts - expect a push for regulations to fix the problem Scott http://www.awareforum.org/2012/01/recap-of-2012-ces-is-broadcast-dead= From artbotterell@gmail.com Sun Jan 29 16:14: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 93BC821F84E7 for ; Sun, 29 Jan 2012 16:14:26 -0800 (PST) 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 fPtvvDy2-rvj for ; Sun, 29 Jan 2012 16:14:26 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 013BA21F84D3 for ; Sun, 29 Jan 2012 16:14:25 -0800 (PST) Received: by dado14 with SMTP id o14so3664588dad.31 for ; Sun, 29 Jan 2012 16:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=TbhprZwb6k9kZB6TmocMpvPn7qnhtG8Cc+HHKf2auIw=; b=NXOtbQ3I5iaACiBhtUfBSUARpOTm1q0v0k14MM4rPXQBhxSiwIUiIB9xTb/LLbWzEK rGvcUNk2HfGyF+YhgyN12P6LZvTZmS3VZL/45FusLp1su/CudMGfN93+LGE4sI/YwGRa 120Yy9dBf14mfNiFqrT3m2/l8PlWq/4ATp5XQ= Received: by 10.68.189.102 with SMTP id gh6mr36719438pbc.4.1327882465780; Sun, 29 Jan 2012 16:14:25 -0800 (PST) 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 z5sm42611950pbc.5.2012.01.29.16.14.23 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 16:14:24 -0800 (PST) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: <23B186E2-E667-4F5F-9613-B1AAD2348593@harvard.edu> Date: Sun, 29 Jan 2012 16:14:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23B186E2-E667-4F5F-9613-B1AAD2348593@harvard.edu> To: "Bradner, Scott" X-Mailer: Apple Mail (2.1251.1) Cc: "atoca@ietf.org" Subject: Re: [atoca] streaming as a worry 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, 30 Jan 2012 00:14:26 -0000 Problem being that most streaming media aren't regulated, at least not = nearly to the extent of traditional broadcast media. "Authority" ain't = what it used to be. OTOH, note = http://google-latlong.blogspot.com/2012/01/public-alerts-now-on-google-map= s.html Global corporate actors are getting involved. - Art On Jan 29, 2012, at 3:39 PM, Bradner, Scott wrote: > the pundits are starting to understand that broadcast TV will not be a = reliable way to > distribute alerts - expect a push for regulations to fix the problem >=20 > Scott >=20 > http://www.awareforum.org/2012/01/recap-of-2012-ces-is-broadcast-dead > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca