From randy@qualcomm.com Sat Feb 4 14:09:08 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 D846A21F8471 for ; Sat, 4 Feb 2012 14:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.916 X-Spam-Level: X-Spam-Status: No, score=-103.916 tagged_above=-999 required=5 tests=[AWL=2.683, 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 O8LpCL8Zrcyb for ; Sat, 4 Feb 2012 14:09:07 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5C21F847D for ; Sat, 4 Feb 2012 14:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1328393347; x=1359929347; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20=0D=0A=20<29AAD277-1C5F-45BF-8C57-8135990378EC@gmx.n et>|References:=20=0D=0A=20=0D=0A=20<29AAD277-1C5F-45BF-8C57-8135990378EC@g mx.net>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20S at,=204=20Feb=202012=2013:24:04=20-0800|To:=20Hannes=20Ts chofenig=20,=20|From:=20Randall=20Gellens=20 |Subject:=20Re:=20[atoca]=20draft-ietf-atoca-requirements -02.txt,=20etc.|CC:=20Randall=20Gellens=20|MIME-Version:=201.0|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.3 9.5]; bh=jTpiLdLjZbryVXfklwOdWmwsK7CvyaaoiD0nq6c8HP0=; b=iqtfOX4akasJWx9a0T2oCPQhc0sFGxaYrrorExq69WGNMjHwI9HZXw63 SO18DMZkUoAgr1zlTC3Ox22o7GF/eTLEq12VDk4bhFIj8wgMl9/Rlxvoi QPz1j+Jw1FxggZeOx99j4wXL3IdHrI8RK+i/Ex6dNlzPYLuIATxdYnO9h k=; X-IronPort-AV: E=McAfee;i="5400,1158,6610"; a="158308559" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 04 Feb 2012 14:09:06 -0800 X-IronPort-AV: E=Sophos;i="4.73,356,1325491200"; d="scan'208";a="119105888" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 04 Feb 2012 14:09:06 -0800 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 4 Feb 2012 14:09:05 -0800 Message-ID: In-Reply-To: <29AAD277-1C5F-45BF-8C57-8135990378EC@gmx.net> References: <29AAD277-1C5F-45BF-8C57-8135990378EC@gmx.net> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Feb 2012 13:24:04 -0800 To: Hannes Tschofenig , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [atoca] draft-ietf-atoca-requirements-02.txt, etc. 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, 04 Feb 2012 22:09:09 -0000 At 11:18 AM +0200 1/14/12, Hannes Tschofenig wrote: > Hi all, > > 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? That was sent on November 17, immediately following the meeting (I figured it was best to send it out right away and avoid it getting buried under other work). At 11:26 AM +0200 1/14/12, Hannes Tschofenig wrote: > Hi Randy, > > I just found this mail. This may be your promised review. Is it? Hi Hannes, yes, that's 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 > ... > ...snip... >>... 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? They are a step towards it, but I think more work is needed. I've sent some additional emails to the group. > > 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. There are a number of reasons to use CAP (including the fact that CMAS uses it). But, it's a fairly low level detail that needs to be built up to and justified based on the use cases and the requirements we need to meet the use cases. > However, I could soften the language a bit, such as > > 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 > 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 > originators of that alert rather than with the distribution system itself. That's an improvement, but there still seems to be a lot missing, specifically, what are the problems we need to solve, and what requirements do we have in order to solve the problems? Then, we can get into lower-level details, including the format of an alert. We might justify CAP by a desire to interoperate with CMAS, for example, but if so we should be clear as to why we have it, and where it is needed (e.g., is it needed for all governmental levels or just national?) > Also, during the meeting someone said that I should replace LoST > with discovery. > That's fine in some sense but I don't want to be super abstract so > that nobody > understands the intentions anymore. > > > Finally, I strongly recommend NOT using the term Message > Handling System (MHS) as this has specific meaning already. > > What terminology do you suggest? What about Alert Handling System? The problem with MHS and Message Handling System is the long history of use with other, quite different systems. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Antonym: The opposite of the word you're trying to think of. From randy@qualcomm.com Sat Feb 4 14:09:15 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 9A7E121F84C8 for ; Sat, 4 Feb 2012 14:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.258 X-Spam-Level: X-Spam-Status: No, score=-105.258 tagged_above=-999 required=5 tests=[AWL=1.341, 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 VVraPLiGjdm1 for ; Sat, 4 Feb 2012 14:09:14 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id DCD1421F844E for ; Sat, 4 Feb 2012 14:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1328393354; x=1359929354; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<1867C285-B927-4318-87F5-9851F4DEC06D@gmx .net>|References:=20<6E44DEC6-5B9A-4214-9A44-D7C45FDB4449 @neustar.biz><201111180536.pAI5aa=0D=0A=207P007978@mtv-co re-4.cisco.com><8C9312A2-CF99-46D3-B174-5959A3D11C18@ne =0D=0A=20ustar.biz>=0D=0A=20=0D=0A=20<1B6A274DF90F4579BB875EBD53F8311B@ OfficeHP>=0D=0A=20<2A85B59A-913B-4340-8C26-F938C3152F62@n eustar.biz>=0D=0A=20<1867C285-B927-4318-87F5-9851F4DEC06D @gmx.net>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date: =20Sat,=204=20Feb=202012=2013:14:16=20-0800|To:=20Hannes =20Tschofenig=20,=20"Rosen,=20 Brian"=0D=0A=09|From:=20Randall =20Gellens=20|Subject:=20Re:=20[atoca ]=20My=20use=20cases|CC:=20"atoca@ietf.org"=20|MIME-Version:=201.0|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.3 9.5]; bh=V8yTaOGmKLiXg+Kl/AkoE9q70EJ7lGrY+eL2GBno/9k=; b=AijUXrlncgR0v4mVxXPwllBNjv5NmQH/TlZINa49oFbBad/jzb0pwBtP dE/gLn69Dz7gmpmzRK9vux7L3rr30gz4cfGMsuhdpMgzye8xtDA670pRj pXSptIL+4HvX+icpzgYrC+ZIDCcKIMF+I0Y4zEDXaMDZFGu80YAaQh8Xa Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6610"; a="160619566" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 04 Feb 2012 14:09:14 -0800 X-IronPort-AV: E=Sophos;i="4.73,356,1325491200"; d="scan'208";a="180242848" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 04 Feb 2012 14:09:14 -0800 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 4 Feb 2012 14:09:13 -0800 Message-ID: In-Reply-To: <1867C285-B927-4318-87F5-9851F4DEC06D@gmx.net> References: <6E44DEC6-5B9A-4214-9A44-D7C45FDB4449@neustar.biz><201111180536.pAI5aa 7P007978@mtv-core-4.cisco.com><8C9312A2-CF99-46D3-B174-5959A3D11C18@ne ustar.biz> <1B6A274DF90F4579BB875EBD53F8311B@OfficeHP> <2A85B59A-913B-4340-8C26-F938C3152F62@neustar.biz> <1867C285-B927-4318-87F5-9851F4DEC06D@gmx.net> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Feb 2012 13:14:16 -0800 To: Hannes Tschofenig , "Rosen, Brian" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] 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, 04 Feb 2012 22:09:15 -0000 At 11:38 AM +0200 1/14/12, Hannes Tschofenig wrote: > 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 > b) Multicast/Broadcast Alert Delivery We may be jumping ahead of ourselves, by looking at transport semantics before we understand the use cases and requirements. I agree that we'll most likely have these two types of transport, but I think we need to have text on: - Use cases - Authorization: How is authorization to initiate an alert determined, and do the entities that need to carry the alert need to verify that was authorized? Do the authorization properties vary in the different use cases? - Transport: What are the requirements for alerts to be transported? Which entities are responsible for accepting alerts, do they need to verify them, and what requirements do these entities have for handling the alerts? - Delivery: What are the requirements for alerts to be delivered and/or presented? > I don't see what the impact for an alert transport when a national > authority vs. local authority approves the distribution of the > warnings. There may be differences in how alerts are authorized, how a transporting entity verifies the authorization, and so forth. > I also do not see how the opt-in matters in many cases either, > unless it has an impact for the protocols. There are likely to be differences in the requirements or the ability to do opt-in or opt-in with point-to-point versus multicast or broadcast. There may be differences in the ability to scale alert handling with opt-in or opt-out at one level or another. > So far we have a few requirements listed in Section 4.2 > "Requirements for Alert Subscription" that IMHO covers the relevant > aspects. It may be beneficial to explicitly derive requirements from the use cases in the document, to show why we need certain requirements in order to meet certain needs. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The significant problems that we face today cannot be solved at the same level of thinking that created them. --Albert Einstein From randy@qualcomm.com Sat Feb 4 14:09:17 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 7DFFB21F84F7 for ; Sat, 4 Feb 2012 14:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.705 X-Spam-Level: X-Spam-Status: No, score=-105.705 tagged_above=-999 required=5 tests=[AWL=0.894, 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 9mhb0d53m2Vv for ; Sat, 4 Feb 2012 14:09:17 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3E21F84C2 for ; Sat, 4 Feb 2012 14:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1328393356; x=1359929356; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20 |In-Reply-To:=20<8C9312A2-CF99-46D3-B174-5959A3D11C18@neu star.biz>|References:=20<6E44DEC6-5B9A-4214-9A44-D7C45FDB 4449@neustar.biz>=0D=0A=20<201111180536.pAI5aa7P007978@mt v-core-4.cisco.com>=0D=0A=20<8C9312A2-CF99-46D3-B174-5959 A3D11C18@neustar.biz>|X-Mailer:=20Eudora=20for=20Mac=20OS =20X|Date:=20Sat,=204=20Feb=202012=2013:17:43=20-0800|To: =20"Rosen,=20Brian"=20,=20"James =20M.=20Polk"=0D=0A=09|From:=20Randall =20Gellens=20|Subject:=20Re:=20[atoca ]=20My=20use=20cases|CC:=20"atoca@ietf.org"=20|MIME-Version:=201.0|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.3 9.5]; bh=3SWH+EVJLEOsHt8HdlU6IXp8fNmMJpj30LhlAqf6ajQ=; b=tw9gMJ6njRik0tAiS1hMcmyaCeZCpE5Lk/DVOz1rMlLnjVBReDU37rFX Y5oq6Q41YZQpDb4vrLub8FGbogerzDdR+cki6N8aVE/GLGiJmNdEeTbjv z+AotowPChuEyt0InjQFfX77FvuX25usWAFOvcoGIrpUz/M3+IU+Nx6gj g=; X-IronPort-AV: E=McAfee;i="5400,1158,6610"; a="160619568" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 04 Feb 2012 14:09:16 -0800 X-IronPort-AV: E=Sophos;i="4.73,356,1325491200"; d="scan'208";a="161923999" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 04 Feb 2012 14:09:16 -0800 Received: from loud.pensive.org (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 4 Feb 2012 14:09:15 -0800 Message-ID: In-Reply-To: <8C9312A2-CF99-46D3-B174-5959A3D11C18@neustar.biz> References: <6E44DEC6-5B9A-4214-9A44-D7C45FDB4449@neustar.biz> <201111180536.pAI5aa7P007978@mtv-core-4.cisco.com> <8C9312A2-CF99-46D3-B174-5959A3D11C18@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Sat, 4 Feb 2012 13:17:43 -0800 To: "Rosen, Brian" , "James M. Polk" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] 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, 04 Feb 2012 22:09:17 -0000 At 12:48 AM -0500 11/18/11, Brian Rosen wrote: > 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 = broadcast for the geographic area they > affect with no opt-out, opt-in sub/not out of the area. > > 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. We need to identify the entities that handle alerts, and how they verify that an alert is authorized. There may be differences at different government levels in how authorization is determined and verified. For example, national alerts might have a single designated authority and a reasonably simple mechanism for verifying authorization. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- For best results, be sure to double clutch when you paradigm shift. From mark.wood@drcf.net Sun Feb 5 09:13:01 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 E8A9E21F8557 for ; Sun, 5 Feb 2012 09:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 G9y2+UM2JjfN for ; Sun, 5 Feb 2012 09:13:00 -0800 (PST) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD5421F855D for ; Sun, 5 Feb 2012 09:13:00 -0800 (PST) X-Trace: 526186772/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AktOAHW4Lk9RVitW/2dsb2JhbABEoAKOMgF+gQaBWAEgCDIcFQEKEAQBBiQDCTIaBhkFAQEEHhCHZAaVaoMkARuQBZgUUYF/BQEpOoQzAQQEJQEJgh6BCgSabYhahDw X-IronPort-AV: E=Sophos;i="4.73,366,1325462400"; d="scan'208";a="526186772" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 05 Feb 2012 17:12:34 +0000 From: Sender: "Mark" To: In-Reply-To: Date: Sun, 5 Feb 2012 17:12:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AczjiaVJzk28wDFeQZGjGXOUBjf0sAAjalMg X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20120205171300.4FD5421F855D@ietfa.amsl.com> Subject: [atoca] Alert Gateways. 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, 05 Feb 2012 17:13:02 -0000 Friends, There is a big difference in law between 'Information' and 'Alerts'. Anyone can say "Its raining quite a lot, old chap, really, really a lot", but only 'Authorities' can say "flooding expected in this area, evacuate now via highway 13". (Art is an expert on this so I hope he can clarify the position). I have been doing a lot of research into this matter, so if you don't mind, here are my thoughts. In many countries, the matter of 'Civil Defence' is a matter of national security policy and is the remit of the 'Ministry of the Interior' of the sovereign state in whose territory the disaster is being "Hosted". Often, strictly no other authority in the world is lawfully permitted to give instructions to the public in the territory of that sovereign state, (regardless of their nationality), other than those who have statuary instruments from the sovereign government concerned. Therefore the matter will be different from Country to Country, and if that country is a Federal State, from State to State. The best known present application of CAP is the USA FEMA IPAWS OPEN system, however CAP is a flexible framework and so other member states may have their own and different "Modus Operandi" from that of the USA. It's not safe to assume that the way IPAWS OPEN implements CAP in the USA will be the same as the way than another country does it. For example, SAME codes and FIPS codes are not used in the UK, so they will definitely be different. But CAP was designed for flexibility. Certainly IETF has no right to set standards on this matter. Previous attempts by very august UN agencies to set standards in this very sensitive area have failed due to *very vigorous* push-back from the member states who on no account will tolerate any interference in their interior affairs in this regard, well meaning or not. Having said that, it's instructive to review the USA system; IPAWS as one "illustrative exemplary embodiment" but remember the above rant :-) At the present time, in the USA, the vision is for FEMA IPAWS OPEN system to be a national alert gateway, the IPAWS OPEN gateway. Any alert messages may be 'pulled' from IPAWS OPEN for subsequent distribution by any participating network, but IPAWS OPEN is the national federal source of public alert information. Regarding 'Originators', The FEMA IPAWS OPEN website explains the procedure, so that a prospective originator can become a 'Collaborating Operating Group (COG) and gain permission to submit proposals to IPAWS OPEN for further Authentication and Authorisation. There is a list of qualified originators, and Authorisation includes endorsement from the State Government, among other requirements. Here is a link to the procedure; http://www.fema.gov/emergency/ipaws/alerting_authorities.shtm I am absolutely sure that no government in the world will feel any differently. I have several clients who are looking at this matter, and they all understand this point well. Likely, the source for each jurisdiction will be well known and be appointed by the government. Likely there will be only one (logically one, but they will be clustered for redundancy). So, just subscribe to the well known 'Alert Gateway' for the jurisdiction of interest. The administrators of the gateway (probably a national or regional government agency) will guarantee the Authentication and Authorisation of the senders according to a very complex set of national criteria (which they may or may not make fully public) and will probably be highly dynamic. These may take the form of a 'Trust Protocol' matrix of multilateral MoUs or MoAs. The distributing network (such as the enterprise) needs to have immunity from prosecution in case they transmit an alert which turns out to be wrong. The only lawful way for them to do this is to be sure they have a *'Non Repudiation'* trace back to the jurisdictional "Alert Gateway" for the area concerned. Of course, the participating 'Distribution Network' may have coverage over areas which cover more than one Jurisdiction, but then it's an easy matter to get multiple feeds from the Alert Gateways in those jurisdictions as they will probably be very few. ('Information' may be different). Any other solution would be very dangerous IMHO, as the participating distribution network may find that they are vulnerable to being sued if their information turns out to be not completely reliable. There are strict laws about all this. But taking it from the "Alert Gateway" means they are covered by the statutory instruments of the government agency operating the gateway. Thus they have indemnity from legal action provided they have not altered the contents of the message in any way. For example messages in different languages are provided into the gateway and no network is expected to perform a transformation. Information Information and even 'Civic Information' is different. However member states are beginning to understand the issues now, so it's likely that there will be multiple 'Civic Information Gateways' also, for matters which don't qualify as 'Alerts' but still need mass distribution. My best guess is that they will be well advertised and that civic or non civic institutions will proudly point to them for the benefit of any distribution network wishing to participate. In some countries, non governmental actors provide valued and trusted information for the public. In which case, it may be sent to the alert gateway, or the information gateway at the pleasure of the government. Of course a distribution network may have its own multilateral arrangement such as RSS for such less sensitive information feeds. CellCast gateways, for example, are designed for either option as each government will have their own view on this and it will change a lot. Warm regards, Mark Wood, DRCF. From artbotterell@gmail.com Sun Feb 5 10:19:08 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 C419721F84A5 for ; Sun, 5 Feb 2012 10:19:08 -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 cYTtmgiD3cBS for ; Sun, 5 Feb 2012 10:19:07 -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 98EA821F8495 for ; Sun, 5 Feb 2012 10:19:07 -0800 (PST) Received: by dakl33 with SMTP id l33so4911725dak.31 for ; Sun, 05 Feb 2012 10:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=wcFDEantiGkXkSSRouhPHKO7r2062eb2EyRVs2U9o7c=; b=FHAQzYnBLmVQZx/HZKNxGuzLhwZdDkVqn9eu6DtPqCOkAHxvK2GXOWHGXVPDn2bmCy L3ON4zEURityuisUUbnaaWXF1mk8hkexwTD4oZm6s4TxTlzYuDUaRAT7dFm77vug/rLv lnvzkxVKBpNdYU/l7IzaUSuL3hg0i7++v1YLU= Received: by 10.68.240.164 with SMTP id wb4mr39751728pbc.57.1328465947433; Sun, 05 Feb 2012 10:19:07 -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 w4sm32742657pbf.4.2012.02.05.10.19.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 10:19:06 -0800 (PST) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Art Botterell In-Reply-To: <20120205171300.4FD5421F855D@ietfa.amsl.com> Date: Sun, 5 Feb 2012 10:19:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com> References: <20120205171300.4FD5421F855D@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [atoca] Alert Gateways. 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, 05 Feb 2012 18:19:08 -0000 Friends - As Mark rightly points out, the notion of "authority" is by no means a = simple one. Although we tend to equate it to "governmental authority," = in practice that equation is complicated by several factors. Among = them: 1) Delegation: There are places I know of where at least some of the = legal authority to issue public warnings has been delegated to = non-government actors within a policy framework. Thus, although the = policy is a function of government authority, the actual warning message = needs to be authenticated to a non-governmental source. 2) Changing legal contexts: While in our time the power to advocate = public behavior has sometimes been seen as a monopoly of government, = there are political philosophies afield in a number of places, including = the U.S., that would change that. Regardless of how we may feel about = such movements, viewed against the backdrop of global history the notion = of such legal or political authority can't be considered immutable. 3) Reciprocity across jurisdictions: When a hazard spans multiple = political jurisdictions, as they often do, and especially in an = environment where communications systems like broadcast and the Net also = span those boundaries, the problem of defining authority can exceed the = powers of any single agency. At the same time, governmental authority = is not always organized in a strict hierarchy; e.g., in California we = have numerous "special districts" for parks, utilities and so on that = span parts of several political subdivisions and that have legal powers = overlapping those of the political subdivision. 4) Legal vs. audience-assigned authority: Although we tend to use the = term "authority" as shorthand for "legal authority," there's also the = factor of personal or moral authority in the eyes of the affected = public. Radio and television weather forecasters are a salient example = of actors who often are viewed as "authorities" by the public. Religious = and community leaders sometimes also act in that capacity. By the same = token, it's not unheard of for the authority/credibility of a government = to be low or even negative in the eyes of some audiences; sometimes = wrongly, sometimes not. And all that is why, in my view, the real issue isn't so much authority = as attribution. As long as an alert can be traced reliably to its = source, different audiences can make their own judgements as to who they = trust in their own context and their own time. And without an = irrefutable mechanism for associating a message with its source, any = attempt at enforcing policy, even within a governmental framework, is = greatly weakened. (Whether there's ever a legitimate role for anonymous = "alerts" is another topic on which sincere folks may differ.) =20 Whereas if we set out to enforce certain trust relationships over others = we risk getting bogged down... unnecessarily, I believe... in the = eternal volatilities of politics. - Art On Feb 5, 2012, at 9:12 AM, wrote: >=20 > Friends, >=20 > There is a big difference in law between 'Information' and 'Alerts'. = Anyone > can say "Its raining quite a lot, old chap, really, really a lot", but = only > 'Authorities' can say "flooding expected in this area, evacuate now = via > highway 13".=20 >=20 > (Art is an expert on this so I hope he can clarify the position).=20 >=20 > I have been doing a lot of research into this matter, so if you don't = mind, > here are my thoughts.=20 >=20 > In many countries, the matter of 'Civil Defence' is a matter of = national > security policy and is the remit of the 'Ministry of the Interior' of = the > sovereign state in whose territory the disaster is being "Hosted".=20 >=20 > Often, strictly no other authority in the world is lawfully permitted = to > give instructions to the public in the territory of that sovereign = state, > (regardless of their nationality), other than those who have statuary > instruments from the sovereign government concerned.=20 >=20 > Therefore the matter will be different from Country to Country, and if = that > country is a Federal State, from State to State.=20 >=20 > The best known present application of CAP is the USA FEMA IPAWS OPEN = system, > however CAP is a flexible framework and so other member states may = have > their own and different "Modus Operandi" from that of the USA. It's = not safe > to assume that the way IPAWS OPEN implements CAP in the USA will be = the same > as the way than another country does it.=20 >=20 > For example, SAME codes and FIPS codes are not used in the UK, so they = will > definitely be different. But CAP was designed for flexibility. =20 >=20 > Certainly IETF has no right to set standards on this matter. Previous > attempts by very august UN agencies to set standards in this very = sensitive > area have failed due to *very vigorous* push-back from the member = states who > on no account will tolerate any interference in their interior affairs = in > this regard, well meaning or not.=20 >=20 > Having said that, it's instructive to review the USA system; IPAWS as = one > "illustrative exemplary embodiment" but remember the above rant :-)=20 >=20 > At the present time, in the USA, the vision is for FEMA IPAWS OPEN = system to > be a national alert gateway, the IPAWS OPEN gateway. Any alert = messages may > be 'pulled' from IPAWS OPEN for subsequent distribution by any = participating > network, but IPAWS OPEN is the national federal source of public alert > information.=20 >=20 > Regarding 'Originators', The FEMA IPAWS OPEN website explains the = procedure, > so that a prospective originator can become a 'Collaborating Operating = Group > (COG) and gain permission to submit proposals to IPAWS OPEN for = further > Authentication and Authorisation. There is a list of qualified = originators, > and Authorisation includes endorsement from the State Government, = among > other requirements. >=20 > Here is a link to the procedure; >=20 > http://www.fema.gov/emergency/ipaws/alerting_authorities.shtm >=20 >=20 >=20 > I am absolutely sure that no government in the world will feel any > differently. I have several clients who are looking at this matter, = and they > all understand this point well. Likely, the source for each = jurisdiction > will be well known and be appointed by the government. Likely there = will be > only one (logically one, but they will be clustered for redundancy). >=20 > So, just subscribe to the well known 'Alert Gateway' for the = jurisdiction of > interest. =20 >=20 > The administrators of the gateway (probably a national or regional > government agency) will guarantee the Authentication and Authorisation = of > the senders according to a very complex set of national criteria = (which they > may or may not make fully public) and will probably be highly dynamic. = These > may take the form of a 'Trust Protocol' matrix of multilateral MoUs or = MoAs. >=20 >=20 > The distributing network (such as the enterprise) needs to have = immunity > from prosecution in case they transmit an alert which turns out to be = wrong. > The only lawful way for them to do this is to be sure they have a = *'Non > Repudiation'* trace back to the jurisdictional "Alert Gateway" for the = area > concerned.=20 >=20 > Of course, the participating 'Distribution Network' may have coverage = over > areas which cover more than one Jurisdiction, but then it's an easy = matter > to get multiple feeds from the Alert Gateways in those jurisdictions = as they > will probably be very few. ('Information' may be different). =20 >=20 > Any other solution would be very dangerous IMHO, as the participating > distribution network may find that they are vulnerable to being sued = if > their information turns out to be not completely reliable. There are = strict > laws about all this.=20 >=20 > But taking it from the "Alert Gateway" means they are covered by the > statutory instruments of the government agency operating the gateway. = Thus > they have indemnity from legal action provided they have not altered = the > contents of the message in any way. >=20 > For example messages in different languages are provided into the = gateway > and no network is expected to perform a transformation. =20 >=20 > Information >=20 > Information and even 'Civic Information' is different. However member = states > are beginning to understand the issues now, so it's likely that there = will > be multiple 'Civic Information Gateways' also, for matters which don't > qualify as 'Alerts' but still need mass distribution. My best guess is = that > they will be well advertised and that civic or non civic institutions = will > proudly point to them for the benefit of any distribution network = wishing to > participate. >=20 > In some countries, non governmental actors provide valued and trusted > information for the public. In which case, it may be sent to the alert > gateway, or the information gateway at the pleasure of the government. = Of > course a distribution network may have its own multilateral = arrangement such > as RSS for such less sensitive information feeds. =20 >=20 > CellCast gateways, for example, are designed for either option as each > government will have their own view on this and it will change a lot.=20= >=20 > Warm regards, Mark Wood, DRCF. >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From bd2985@att.com Sun Feb 5 10:30:42 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 4258521F857D for ; Sun, 5 Feb 2012 10:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 rjHzQgGSJ8jM for ; Sun, 5 Feb 2012 10:30:40 -0800 (PST) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF0921F8572 for ; Sun, 5 Feb 2012 10:30:40 -0800 (PST) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1328466639!62107864!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13650 invoked from network); 5 Feb 2012 18:30:39 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Feb 2012 18:30:39 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id q15IUdpJ021091; Sun, 5 Feb 2012 12:30:39 -0600 Received: from dalint03.pst.cso.att.com (dalint03.pst.cso.att.com [135.31.133.161]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id q15IUaU4021076; Sun, 5 Feb 2012 12:30:36 -0600 Received: from WABOTH9MSGHUB8B.ITServices.sbc.com (waboth9msghub8b.itservices.sbc.com [135.163.35.101]) by dalint03.pst.cso.att.com (RSA Interceptor); Sun, 5 Feb 2012 12:30:24 -0600 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.104]) by WABOTH9MSGHUB8B.ITServices.sbc.com ([135.163.35.101]) with mapi id 14.01.0355.002; Sun, 5 Feb 2012 10:30:23 -0800 From: "DALY, BRIAN K" To: Art Botterell , "atoca@ietf.org" Thread-Topic: [atoca] Alert Gateways. Thread-Index: AQHM5ClwSKNWMupTT0S+RTRKIrh6BZYvIxCA//977eA= Date: Sun, 5 Feb 2012 18:30:23 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F960EE20C3C@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <20120205171300.4FD5421F855D@ietfa.amsl.com> <0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com> In-Reply-To: <0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {6A66E038-0C65-4A8D-8889-A47BC4310D33} x-cr-hashedpuzzle: Cp8i CxYN Ezbt HaAI ITg5 IgCX JoAK J4Pi NsI/ THbR TqwP V0dE WN3S Y56w ZEga ZK/O; 2; YQBjAGIAQABpAG4AYwBpAGQAZQBuAHQALgBjAG8AbQA7AGEAdABvAGMAYQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {6A66E038-0C65-4A8D-8889-A47BC4310D33}; YgBkADIAOQA4ADUAQABhAHQAdAAuAGMAbwBtAA==; Sun, 05 Feb 2012 18:30:18 GMT; UgBFADoAIABbAGEAdABvAGMAYQBdACAAQQBsAGUAcgB0ACAARwBhAHQAZQB3AGEAeQBzAC4A x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [atoca] Alert Gateways. 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, 05 Feb 2012 18:30:42 -0000 To the point " the real issue isn't so much authority as attribution", the = other critical issue is liability protection for distribution of the alert,= such as what is offered to CMSPs under the WARN Act. Attribution is part of it, but also the distributor of the alert has to be = free from all liability for distribution of that alert so long as it was re= ceived from the proper source (Federal Gateway here in the U.S.) and there = are sufficient legal liability protections in place (from Congress under th= e WARN Act). We consider all non-authority alerts - e.g. from day care centers, schools,= etc. - to be information sources unless they are registered alert initiato= rs through FEMA and their information comes from that Federal Aggregator - = and has sufficient liability protections as is offered under the WARTN Act. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of A= rt Botterell Sent: Sunday, February 05, 2012 10:19 AM To: atoca@ietf.org Subject: Re: [atoca] Alert Gateways. Friends - As Mark rightly points out, the notion of "authority" is by no means a simp= le one. Although we tend to equate it to "governmental authority," in prac= tice that equation is complicated by several factors. Among them: 1) Delegation: There are places I know of where at least some of the legal= authority to issue public warnings has been delegated to non-government ac= tors within a policy framework. Thus, although the policy is a function of= government authority, the actual warning message needs to be authenticated= to a non-governmental source. 2) Changing legal contexts: While in our time the power to advocate public= behavior has sometimes been seen as a monopoly of government, there are po= litical philosophies afield in a number of places, including the U.S., that= would change that. Regardless of how we may feel about such movements, vi= ewed against the backdrop of global history the notion of such legal or pol= itical authority can't be considered immutable. 3) Reciprocity across jurisdictions: When a hazard spans multiple political= jurisdictions, as they often do, and especially in an environment where co= mmunications systems like broadcast and the Net also span those boundaries,= the problem of defining authority can exceed the powers of any single agen= cy. At the same time, governmental authority is not always organized in a = strict hierarchy; e.g., in California we have numerous "special districts" = for parks, utilities and so on that span parts of several political subdivi= sions and that have legal powers overlapping those of the political subdivi= sion. 4) Legal vs. audience-assigned authority: Although we tend to use the term = "authority" as shorthand for "legal authority," there's also the factor of = personal or moral authority in the eyes of the affected public. Radio and = television weather forecasters are a salient example of actors who often ar= e viewed as "authorities" by the public. Religious and community leaders so= metimes also act in that capacity. By the same token, it's not unheard of = for the authority/credibility of a government to be low or even negative in= the eyes of some audiences; sometimes wrongly, sometimes not. And all that is why, in my view, the real issue isn't so much authority as = attribution. As long as an alert can be traced reliably to its source, dif= ferent audiences can make their own judgements as to who they trust in thei= r own context and their own time. And without an irrefutable mechanism for= associating a message with its source, any attempt at enforcing policy, ev= en within a governmental framework, is greatly weakened. (Whether there's = ever a legitimate role for anonymous "alerts" is another topic on which sin= cere folks may differ.) =20 Whereas if we set out to enforce certain trust relationships over others we= risk getting bogged down... unnecessarily, I believe... in the eternal vol= atilities of politics. - Art On Feb 5, 2012, at 9:12 AM, wrote: >=20 > Friends, >=20 > There is a big difference in law between 'Information' and 'Alerts'. Anyo= ne > can say "Its raining quite a lot, old chap, really, really a lot", but on= ly > 'Authorities' can say "flooding expected in this area, evacuate now via > highway 13".=20 >=20 > (Art is an expert on this so I hope he can clarify the position).=20 >=20 > I have been doing a lot of research into this matter, so if you don't min= d, > here are my thoughts.=20 >=20 > In many countries, the matter of 'Civil Defence' is a matter of national > security policy and is the remit of the 'Ministry of the Interior' of the > sovereign state in whose territory the disaster is being "Hosted".=20 >=20 > Often, strictly no other authority in the world is lawfully permitted to > give instructions to the public in the territory of that sovereign state, > (regardless of their nationality), other than those who have statuary > instruments from the sovereign government concerned.=20 >=20 > Therefore the matter will be different from Country to Country, and if th= at > country is a Federal State, from State to State.=20 >=20 > The best known present application of CAP is the USA FEMA IPAWS OPEN syst= em, > however CAP is a flexible framework and so other member states may have > their own and different "Modus Operandi" from that of the USA. It's not s= afe > to assume that the way IPAWS OPEN implements CAP in the USA will be the s= ame > as the way than another country does it.=20 >=20 > For example, SAME codes and FIPS codes are not used in the UK, so they wi= ll > definitely be different. But CAP was designed for flexibility. =20 >=20 > Certainly IETF has no right to set standards on this matter. Previous > attempts by very august UN agencies to set standards in this very sensiti= ve > area have failed due to *very vigorous* push-back from the member states = who > on no account will tolerate any interference in their interior affairs in > this regard, well meaning or not.=20 >=20 > Having said that, it's instructive to review the USA system; IPAWS as one > "illustrative exemplary embodiment" but remember the above rant :-)=20 >=20 > At the present time, in the USA, the vision is for FEMA IPAWS OPEN system= to > be a national alert gateway, the IPAWS OPEN gateway. Any alert messages m= ay > be 'pulled' from IPAWS OPEN for subsequent distribution by any participat= ing > network, but IPAWS OPEN is the national federal source of public alert > information.=20 >=20 > Regarding 'Originators', The FEMA IPAWS OPEN website explains the procedu= re, > so that a prospective originator can become a 'Collaborating Operating Gr= oup > (COG) and gain permission to submit proposals to IPAWS OPEN for further > Authentication and Authorisation. There is a list of qualified originator= s, > and Authorisation includes endorsement from the State Government, among > other requirements. >=20 > Here is a link to the procedure; >=20 > http://www.fema.gov/emergency/ipaws/alerting_authorities.shtm >=20 >=20 >=20 > I am absolutely sure that no government in the world will feel any > differently. I have several clients who are looking at this matter, and t= hey > all understand this point well. Likely, the source for each jurisdiction > will be well known and be appointed by the government. Likely there will = be > only one (logically one, but they will be clustered for redundancy). >=20 > So, just subscribe to the well known 'Alert Gateway' for the jurisdiction= of > interest. =20 >=20 > The administrators of the gateway (probably a national or regional > government agency) will guarantee the Authentication and Authorisation of > the senders according to a very complex set of national criteria (which t= hey > may or may not make fully public) and will probably be highly dynamic. Th= ese > may take the form of a 'Trust Protocol' matrix of multilateral MoUs or Mo= As. >=20 >=20 > The distributing network (such as the enterprise) needs to have immunity > from prosecution in case they transmit an alert which turns out to be wro= ng. > The only lawful way for them to do this is to be sure they have a *'Non > Repudiation'* trace back to the jurisdictional "Alert Gateway" for the ar= ea > concerned.=20 >=20 > Of course, the participating 'Distribution Network' may have coverage ove= r > areas which cover more than one Jurisdiction, but then it's an easy matte= r > to get multiple feeds from the Alert Gateways in those jurisdictions as t= hey > will probably be very few. ('Information' may be different). =20 >=20 > Any other solution would be very dangerous IMHO, as the participating > distribution network may find that they are vulnerable to being sued if > their information turns out to be not completely reliable. There are stri= ct > laws about all this.=20 >=20 > But taking it from the "Alert Gateway" means they are covered by the > statutory instruments of the government agency operating the gateway. Thu= s > they have indemnity from legal action provided they have not altered the > contents of the message in any way. >=20 > For example messages in different languages are provided into the gateway > and no network is expected to perform a transformation. =20 >=20 > Information >=20 > Information and even 'Civic Information' is different. However member sta= tes > are beginning to understand the issues now, so it's likely that there wil= l > be multiple 'Civic Information Gateways' also, for matters which don't > qualify as 'Alerts' but still need mass distribution. My best guess is th= at > they will be well advertised and that civic or non civic institutions wil= l > proudly point to them for the benefit of any distribution network wishing= to > participate. >=20 > In some countries, non governmental actors provide valued and trusted > information for the public. In which case, it may be sent to the alert > gateway, or the information gateway at the pleasure of the government. Of > course a distribution network may have its own multilateral arrangement s= uch > as RSS for such less sensitive information feeds. =20 >=20 > CellCast gateways, for example, are designed for either option as each > government will have their own view on this and it will change a lot.=20 >=20 > Warm regards, Mark Wood, DRCF. >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Sun Feb 5 11:32:49 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 3802021F8514 for ; Sun, 5 Feb 2012 11:32:49 -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 7mEmYPjsKmXQ for ; Sun, 5 Feb 2012 11:32:45 -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 8C52921F84D8 for ; Sun, 5 Feb 2012 11:32:45 -0800 (PST) Received: by dakl33 with SMTP id l33so4949338dak.31 for ; Sun, 05 Feb 2012 11:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=daJvvKmplQuKJq/uUzRG72/gDB+ZGWpjYn+XzONkkLk=; b=CmPTMJi1AIvb+3i37QMQid0OBFmX38Q3S3tOs7BPkdOBF7CoY4v5GN2Y0BNWnaTfpf 7o3LMCRmSDiYP63V9eRcUdOQPnrBLefFoGqv8v5OXLB1KPNkpF2rBhBKtQuJGccHb467 bdcK459iKfj3V5HFJRuJR8aUtls9t8AS30S2Y= Received: by 10.68.73.4 with SMTP id h4mr40976077pbv.27.1328470365098; Sun, 05 Feb 2012 11:32:45 -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 o7sm33218646pbq.8.2012.02.05.11.32.43 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 11:32:43 -0800 (PST) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Art Botterell In-Reply-To: <95C5C7A891135E4685CCFAE997351F960EE20C3C@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Sun, 5 Feb 2012 11:32:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <00797A22-C61C-4B2C-9A4D-11DC430BDC78@incident.com> References: <20120205171300.4FD5421F855D@ietfa.amsl.com> <0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com> <95C5C7A891135E4685CCFAE997351F960EE20C3C@WABOTH9MSGUSR8B.ITServices.sbc.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [atoca] Alert Gateways. 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, 05 Feb 2012 19:32:49 -0000 Of course the details of the liability question can vary from country to = country and even from actor to actor. (E.g., I'd be interested in = hearing what Google's policy is, and to see how it evolves over time.) =20= And much of the liability conversation is, necessarily, speculative in = nature. E.g., what, ultimately, is the difference between CMAS and, = say, Twitter? To some extent it's circular: CMAS is different = because... well... because we say it's different (i.e., "official.") = And what does it mean to be "official?" It means that access to it is = limited by political authority. And how is access limited? By being = able to attribute all inputs to sources that can be verified as having = whatever constitutes "official" status. So ultimately, even the liability protection afforded to corporate = carriers in the U.S. in the context of CMAS is based on the ability of = the federal government to verify the provenance of each individual = message. My point is merely that the particular arrangement of corporations = providing alert distribution under the protection of a national = government and by way of a central national gateway is a particular = instance, but probably not an immutable pattern on which global = standards can rest. Other organizations and/or governments might take = different approaches in other places. =20 However, I have difficulty imagining any system of alerting, be it an = open end-to-end architecture, a heavily-regulated intermediary or = something in between, that won't require a credible scheme for message = attribution. - Art On Feb 5, 2012, at 10:30 AM, DALY, BRIAN K wrote: > To the point " the real issue isn't so much authority as attribution", = the other critical issue is liability protection for distribution of the = alert, such as what is offered to CMSPs under the WARN Act. >=20 > Attribution is part of it, but also the distributor of the alert has = to be free from all liability for distribution of that alert so long as = it was received from the proper source (Federal Gateway here in the = U.S.) and there are sufficient legal liability protections in place = (from Congress under the WARN Act). >=20 > We consider all non-authority alerts - e.g. from day care centers, = schools, etc. - to be information sources unless they are registered = alert initiators through FEMA and their information comes from that = Federal Aggregator - and has sufficient liability protections as is = offered under the WARTN Act. >=20 > -------- > Brian K. Daly > Director, Core Network & Govn't/Regulatory Standards > AT&T Services, Inc. > +1.425.580.6873 > brian.k.daly@att.com >=20 > Rethink Possible >=20 >=20 > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf = Of Art Botterell > Sent: Sunday, February 05, 2012 10:19 AM > To: atoca@ietf.org > Subject: Re: [atoca] Alert Gateways. >=20 > Friends - >=20 > As Mark rightly points out, the notion of "authority" is by no means a = simple one. Although we tend to equate it to "governmental authority," = in practice that equation is complicated by several factors. Among = them: >=20 > 1) Delegation: There are places I know of where at least some of the = legal authority to issue public warnings has been delegated to = non-government actors within a policy framework. Thus, although the = policy is a function of government authority, the actual warning message = needs to be authenticated to a non-governmental source. >=20 > 2) Changing legal contexts: While in our time the power to advocate = public behavior has sometimes been seen as a monopoly of government, = there are political philosophies afield in a number of places, including = the U.S., that would change that. Regardless of how we may feel about = such movements, viewed against the backdrop of global history the notion = of such legal or political authority can't be considered immutable. >=20 > 3) Reciprocity across jurisdictions: When a hazard spans multiple = political jurisdictions, as they often do, and especially in an = environment where communications systems like broadcast and the Net also = span those boundaries, the problem of defining authority can exceed the = powers of any single agency. At the same time, governmental authority = is not always organized in a strict hierarchy; e.g., in California we = have numerous "special districts" for parks, utilities and so on that = span parts of several political subdivisions and that have legal powers = overlapping those of the political subdivision. >=20 > 4) Legal vs. audience-assigned authority: Although we tend to use the = term "authority" as shorthand for "legal authority," there's also the = factor of personal or moral authority in the eyes of the affected = public. Radio and television weather forecasters are a salient example = of actors who often are viewed as "authorities" by the public. Religious = and community leaders sometimes also act in that capacity. By the same = token, it's not unheard of for the authority/credibility of a government = to be low or even negative in the eyes of some audiences; sometimes = wrongly, sometimes not. >=20 > And all that is why, in my view, the real issue isn't so much = authority as attribution. As long as an alert can be traced reliably to = its source, different audiences can make their own judgements as to who = they trust in their own context and their own time. And without an = irrefutable mechanism for associating a message with its source, any = attempt at enforcing policy, even within a governmental framework, is = greatly weakened. (Whether there's ever a legitimate role for anonymous = "alerts" is another topic on which sincere folks may differ.) =20 >=20 > Whereas if we set out to enforce certain trust relationships over = others we risk getting bogged down... unnecessarily, I believe... in the = eternal volatilities of politics. >=20 > - Art >=20 >=20 > On Feb 5, 2012, at 9:12 AM, wrote: >=20 >>=20 >> Friends, >>=20 >> There is a big difference in law between 'Information' and 'Alerts'. = Anyone >> can say "Its raining quite a lot, old chap, really, really a lot", = but only >> 'Authorities' can say "flooding expected in this area, evacuate now = via >> highway 13".=20 >>=20 >> (Art is an expert on this so I hope he can clarify the position).=20 >>=20 >> I have been doing a lot of research into this matter, so if you don't = mind, >> here are my thoughts.=20 >>=20 >> In many countries, the matter of 'Civil Defence' is a matter of = national >> security policy and is the remit of the 'Ministry of the Interior' of = the >> sovereign state in whose territory the disaster is being "Hosted".=20 >>=20 >> Often, strictly no other authority in the world is lawfully permitted = to >> give instructions to the public in the territory of that sovereign = state, >> (regardless of their nationality), other than those who have statuary >> instruments from the sovereign government concerned.=20 >>=20 >> Therefore the matter will be different from Country to Country, and = if that >> country is a Federal State, from State to State.=20 >>=20 >> The best known present application of CAP is the USA FEMA IPAWS OPEN = system, >> however CAP is a flexible framework and so other member states may = have >> their own and different "Modus Operandi" from that of the USA. It's = not safe >> to assume that the way IPAWS OPEN implements CAP in the USA will be = the same >> as the way than another country does it.=20 >>=20 >> For example, SAME codes and FIPS codes are not used in the UK, so = they will >> definitely be different. But CAP was designed for flexibility. =20 >>=20 >> Certainly IETF has no right to set standards on this matter. Previous >> attempts by very august UN agencies to set standards in this very = sensitive >> area have failed due to *very vigorous* push-back from the member = states who >> on no account will tolerate any interference in their interior = affairs in >> this regard, well meaning or not.=20 >>=20 >> Having said that, it's instructive to review the USA system; IPAWS as = one >> "illustrative exemplary embodiment" but remember the above rant :-)=20= >>=20 >> At the present time, in the USA, the vision is for FEMA IPAWS OPEN = system to >> be a national alert gateway, the IPAWS OPEN gateway. Any alert = messages may >> be 'pulled' from IPAWS OPEN for subsequent distribution by any = participating >> network, but IPAWS OPEN is the national federal source of public = alert >> information.=20 >>=20 >> Regarding 'Originators', The FEMA IPAWS OPEN website explains the = procedure, >> so that a prospective originator can become a 'Collaborating = Operating Group >> (COG) and gain permission to submit proposals to IPAWS OPEN for = further >> Authentication and Authorisation. There is a list of qualified = originators, >> and Authorisation includes endorsement from the State Government, = among >> other requirements. >>=20 >> Here is a link to the procedure; >>=20 >> http://www.fema.gov/emergency/ipaws/alerting_authorities.shtm >>=20 >>=20 >>=20 >> I am absolutely sure that no government in the world will feel any >> differently. I have several clients who are looking at this matter, = and they >> all understand this point well. Likely, the source for each = jurisdiction >> will be well known and be appointed by the government. Likely there = will be >> only one (logically one, but they will be clustered for redundancy). >>=20 >> So, just subscribe to the well known 'Alert Gateway' for the = jurisdiction of >> interest. =20 >>=20 >> The administrators of the gateway (probably a national or regional >> government agency) will guarantee the Authentication and = Authorisation of >> the senders according to a very complex set of national criteria = (which they >> may or may not make fully public) and will probably be highly = dynamic. These >> may take the form of a 'Trust Protocol' matrix of multilateral MoUs = or MoAs. >>=20 >>=20 >> The distributing network (such as the enterprise) needs to have = immunity >> from prosecution in case they transmit an alert which turns out to be = wrong. >> The only lawful way for them to do this is to be sure they have a = *'Non >> Repudiation'* trace back to the jurisdictional "Alert Gateway" for = the area >> concerned.=20 >>=20 >> Of course, the participating 'Distribution Network' may have coverage = over >> areas which cover more than one Jurisdiction, but then it's an easy = matter >> to get multiple feeds from the Alert Gateways in those jurisdictions = as they >> will probably be very few. ('Information' may be different). =20 >>=20 >> Any other solution would be very dangerous IMHO, as the participating >> distribution network may find that they are vulnerable to being sued = if >> their information turns out to be not completely reliable. There are = strict >> laws about all this.=20 >>=20 >> But taking it from the "Alert Gateway" means they are covered by the >> statutory instruments of the government agency operating the gateway. = Thus >> they have indemnity from legal action provided they have not altered = the >> contents of the message in any way. >>=20 >> For example messages in different languages are provided into the = gateway >> and no network is expected to perform a transformation. =20 >>=20 >> Information >>=20 >> Information and even 'Civic Information' is different. However member = states >> are beginning to understand the issues now, so it's likely that there = will >> be multiple 'Civic Information Gateways' also, for matters which = don't >> qualify as 'Alerts' but still need mass distribution. My best guess = is that >> they will be well advertised and that civic or non civic institutions = will >> proudly point to them for the benefit of any distribution network = wishing to >> participate. >>=20 >> In some countries, non governmental actors provide valued and trusted >> information for the public. In which case, it may be sent to the = alert >> gateway, or the information gateway at the pleasure of the = government. Of >> course a distribution network may have its own multilateral = arrangement such >> as RSS for such less sensitive information feeds. =20 >>=20 >> CellCast gateways, for example, are designed for either option as = each >> government will have their own view on this and it will change a lot.=20= >>=20 >> Warm regards, Mark Wood, DRCF. >>=20 >>=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 creed@opengeospatial.org Sun Feb 5 14:13:18 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 C169E21F84FD for ; Sun, 5 Feb 2012 14:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=1.172, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001] 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 Di2Clgep6NfV for ; Sun, 5 Feb 2012 14:13:17 -0800 (PST) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 37BB121F84A2 for ; Sun, 5 Feb 2012 14:13:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 0CE965A613; Sun, 5 Feb 2012 17:13:16 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQYLB9t8WNWm; Sun, 5 Feb 2012 17:13:15 -0500 (EST) Received: from OfficeHP (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id BEF3E5A60E; Sun, 5 Feb 2012 17:13:14 -0500 (EST) Message-ID: From: "Carl Reed" To: "Art Botterell" , References: <20120205171300.4FD5421F855D@ietfa.amsl.com><0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com><95C5C7A891135E4685CCFAE997351F960EE20C3C@WABOTH9MSGUSR8B.ITServices.sbc.com> <00797A22-C61C-4B2C-9A4D-11DC430BDC78@incident.com> In-Reply-To: <00797A22-C61C-4B2C-9A4D-11DC430BDC78@incident.com> Date: Sun, 5 Feb 2012 15:12:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Subject: Re: [atoca] Alert Gateways. 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, 05 Feb 2012 22:13:18 -0000 Interesting how provenance is a key aspect of alerts/warnings. I am somewhat involved in the W3C Provenance working group. They are defining a conceptual model and language for communicating provenance. I provided them a number of geo centric provenance use cases. This discussion provides another (critical) use case. Anyone have any thoughts on how best to "insert" the message attribution (provenance) requirements into the W3C?? The reason I ask is that the majority of the provenance WG members are not alerting or geo literate. Cheers Carl -----Original Message----- From: Art Botterell Sent: Sunday, February 05, 2012 12:32 PM To: atoca@ietf.org Subject: Re: [atoca] Alert Gateways. Of course the details of the liability question can vary from country to country and even from actor to actor. (E.g., I'd be interested in hearing what Google's policy is, and to see how it evolves over time.) And much of the liability conversation is, necessarily, speculative in nature. E.g., what, ultimately, is the difference between CMAS and, say, Twitter? To some extent it's circular: CMAS is different because... well... because we say it's different (i.e., "official.") And what does it mean to be "official?" It means that access to it is limited by political authority. And how is access limited? By being able to attribute all inputs to sources that can be verified as having whatever constitutes "official" status. So ultimately, even the liability protection afforded to corporate carriers in the U.S. in the context of CMAS is based on the ability of the federal government to verify the provenance of each individual message. My point is merely that the particular arrangement of corporations providing alert distribution under the protection of a national government and by way of a central national gateway is a particular instance, but probably not an immutable pattern on which global standards can rest. Other organizations and/or governments might take different approaches in other places. However, I have difficulty imagining any system of alerting, be it an open end-to-end architecture, a heavily-regulated intermediary or something in between, that won't require a credible scheme for message attribution. - Art On Feb 5, 2012, at 10:30 AM, DALY, BRIAN K wrote: > To the point " the real issue isn't so much authority as attribution", the > other critical issue is liability protection for distribution of the > alert, such as what is offered to CMSPs under the WARN Act. > > Attribution is part of it, but also the distributor of the alert has to be > free from all liability for distribution of that alert so long as it was > received from the proper source (Federal Gateway here in the U.S.) and > there are sufficient legal liability protections in place (from Congress > under the WARN Act). > > We consider all non-authority alerts - e.g. from day care centers, > schools, etc. - to be information sources unless they are registered alert > initiators through FEMA and their information comes from that Federal > Aggregator - and has sufficient liability protections as is offered under > the WARTN Act. > > -------- > Brian K. Daly > Director, Core Network & Govn't/Regulatory Standards > AT&T Services, Inc. > +1.425.580.6873 > brian.k.daly@att.com > > Rethink Possible > > > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Art Botterell > Sent: Sunday, February 05, 2012 10:19 AM > To: atoca@ietf.org > Subject: Re: [atoca] Alert Gateways. > > Friends - > > As Mark rightly points out, the notion of "authority" is by no means a > simple one. Although we tend to equate it to "governmental authority," in > practice that equation is complicated by several factors. Among them: > > 1) Delegation: There are places I know of where at least some of the > legal authority to issue public warnings has been delegated to > non-government actors within a policy framework. Thus, although the > policy is a function of government authority, the actual warning message > needs to be authenticated to a non-governmental source. > > 2) Changing legal contexts: While in our time the power to advocate > public behavior has sometimes been seen as a monopoly of government, there > are political philosophies afield in a number of places, including the > U.S., that would change that. Regardless of how we may feel about such > movements, viewed against the backdrop of global history the notion of > such legal or political authority can't be considered immutable. > > 3) Reciprocity across jurisdictions: When a hazard spans multiple > political jurisdictions, as they often do, and especially in an > environment where communications systems like broadcast and the Net also > span those boundaries, the problem of defining authority can exceed the > powers of any single agency. At the same time, governmental authority is > not always organized in a strict hierarchy; e.g., in California we have > numerous "special districts" for parks, utilities and so on that span > parts of several political subdivisions and that have legal powers > overlapping those of the political subdivision. > > 4) Legal vs. audience-assigned authority: Although we tend to use the term > "authority" as shorthand for "legal authority," there's also the factor of > personal or moral authority in the eyes of the affected public. Radio and > television weather forecasters are a salient example of actors who often > are viewed as "authorities" by the public. Religious and community leaders > sometimes also act in that capacity. By the same token, it's not unheard > of for the authority/credibility of a government to be low or even > negative in the eyes of some audiences; sometimes wrongly, sometimes not. > > And all that is why, in my view, the real issue isn't so much authority as > attribution. As long as an alert can be traced reliably to its source, > different audiences can make their own judgements as to who they trust in > their own context and their own time. And without an irrefutable > mechanism for associating a message with its source, any attempt at > enforcing policy, even within a governmental framework, is greatly > weakened. (Whether there's ever a legitimate role for anonymous "alerts" > is another topic on which sincere folks may differ.) > > Whereas if we set out to enforce certain trust relationships over others > we risk getting bogged down... unnecessarily, I believe... in the eternal > volatilities of politics. > > - Art > > > On Feb 5, 2012, at 9:12 AM, wrote: > >> >> Friends, >> >> There is a big difference in law between 'Information' and 'Alerts'. >> Anyone >> can say "Its raining quite a lot, old chap, really, really a lot", but >> only >> 'Authorities' can say "flooding expected in this area, evacuate now via >> highway 13". >> >> (Art is an expert on this so I hope he can clarify the position). >> >> I have been doing a lot of research into this matter, so if you don't >> mind, >> here are my thoughts. >> >> In many countries, the matter of 'Civil Defence' is a matter of national >> security policy and is the remit of the 'Ministry of the Interior' of the >> sovereign state in whose territory the disaster is being "Hosted". >> >> Often, strictly no other authority in the world is lawfully permitted to >> give instructions to the public in the territory of that sovereign state, >> (regardless of their nationality), other than those who have statuary >> instruments from the sovereign government concerned. >> >> Therefore the matter will be different from Country to Country, and if >> that >> country is a Federal State, from State to State. >> >> The best known present application of CAP is the USA FEMA IPAWS OPEN >> system, >> however CAP is a flexible framework and so other member states may have >> their own and different "Modus Operandi" from that of the USA. It's not >> safe >> to assume that the way IPAWS OPEN implements CAP in the USA will be the >> same >> as the way than another country does it. >> >> For example, SAME codes and FIPS codes are not used in the UK, so they >> will >> definitely be different. But CAP was designed for flexibility. >> >> Certainly IETF has no right to set standards on this matter. Previous >> attempts by very august UN agencies to set standards in this very >> sensitive >> area have failed due to *very vigorous* push-back from the member states >> who >> on no account will tolerate any interference in their interior affairs in >> this regard, well meaning or not. >> >> Having said that, it's instructive to review the USA system; IPAWS as one >> "illustrative exemplary embodiment" but remember the above rant :-) >> >> At the present time, in the USA, the vision is for FEMA IPAWS OPEN system >> to >> be a national alert gateway, the IPAWS OPEN gateway. Any alert messages >> may >> be 'pulled' from IPAWS OPEN for subsequent distribution by any >> participating >> network, but IPAWS OPEN is the national federal source of public alert >> information. >> >> Regarding 'Originators', The FEMA IPAWS OPEN website explains the >> procedure, >> so that a prospective originator can become a 'Collaborating Operating >> Group >> (COG) and gain permission to submit proposals to IPAWS OPEN for further >> Authentication and Authorisation. There is a list of qualified >> originators, >> and Authorisation includes endorsement from the State Government, among >> other requirements. >> >> Here is a link to the procedure; >> >> http://www.fema.gov/emergency/ipaws/alerting_authorities.shtm >> >> >> >> I am absolutely sure that no government in the world will feel any >> differently. I have several clients who are looking at this matter, and >> they >> all understand this point well. Likely, the source for each jurisdiction >> will be well known and be appointed by the government. Likely there will >> be >> only one (logically one, but they will be clustered for redundancy). >> >> So, just subscribe to the well known 'Alert Gateway' for the jurisdiction >> of >> interest. >> >> The administrators of the gateway (probably a national or regional >> government agency) will guarantee the Authentication and Authorisation of >> the senders according to a very complex set of national criteria (which >> they >> may or may not make fully public) and will probably be highly dynamic. >> These >> may take the form of a 'Trust Protocol' matrix of multilateral MoUs or >> MoAs. >> >> >> The distributing network (such as the enterprise) needs to have immunity >> from prosecution in case they transmit an alert which turns out to be >> wrong. >> The only lawful way for them to do this is to be sure they have a *'Non >> Repudiation'* trace back to the jurisdictional "Alert Gateway" for the >> area >> concerned. >> >> Of course, the participating 'Distribution Network' may have coverage >> over >> areas which cover more than one Jurisdiction, but then it's an easy >> matter >> to get multiple feeds from the Alert Gateways in those jurisdictions as >> they >> will probably be very few. ('Information' may be different). >> >> Any other solution would be very dangerous IMHO, as the participating >> distribution network may find that they are vulnerable to being sued if >> their information turns out to be not completely reliable. There are >> strict >> laws about all this. >> >> But taking it from the "Alert Gateway" means they are covered by the >> statutory instruments of the government agency operating the gateway. >> Thus >> they have indemnity from legal action provided they have not altered the >> contents of the message in any way. >> >> For example messages in different languages are provided into the gateway >> and no network is expected to perform a transformation. >> >> Information >> >> Information and even 'Civic Information' is different. However member >> states >> are beginning to understand the issues now, so it's likely that there >> will >> be multiple 'Civic Information Gateways' also, for matters which don't >> qualify as 'Alerts' but still need mass distribution. My best guess is >> that >> they will be well advertised and that civic or non civic institutions >> will >> proudly point to them for the benefit of any distribution network wishing >> to >> participate. >> >> In some countries, non governmental actors provide valued and trusted >> information for the public. In which case, it may be sent to the alert >> gateway, or the information gateway at the pleasure of the government. Of >> course a distribution network may have its own multilateral arrangement >> such >> as RSS for such less sensitive information feeds. >> >> CellCast gateways, for example, are designed for either option as each >> government will have their own view on this and it will change a lot. >> >> Warm regards, Mark Wood, DRCF. >> >> >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Sun Feb 5 14:45:27 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 EA4B721F8589 for ; Sun, 5 Feb 2012 14:45:27 -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 Q8odl8Yn7XxD for ; Sun, 5 Feb 2012 14:45:26 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7BF21F847C for ; Sun, 5 Feb 2012 14:45:26 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1542446pbc.31 for ; Sun, 05 Feb 2012 14:45:26 -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:x-priority :in-reply-to:date:content-transfer-encoding:message-id:references:to :x-mailer; bh=xHrkAe7OZL8s9EkJZiOMjgBEbfUpEbrE099bXQWfpbc=; b=svjAgVAvELyuDStG6EdPQYAZ3EOgbLhKpaWXAoAVNpMV+/cHUlCY8ahHTM6iiLBmcP U5xnZzpREmZvJw6smYUp6OPT3I/4t5JtoBW7h4irjov6l2/RtTPhhJQU9dFtZCCMHxC9 1NqNysL5S0BPnDNJtAnq0a0W89IGHNHZcHXoc= Received: by 10.68.222.169 with SMTP id qn9mr14032957pbc.30.1328481924910; Sun, 05 Feb 2012 14:45:24 -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 p9sm34486430pbb.9.2012.02.05.14.45.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 14:45:23 -0800 (PST) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Art Botterell X-Priority: 3 In-Reply-To: Date: Sun, 5 Feb 2012 14:45:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <16278387-4EC0-4EF7-BBDE-458BF8230C3F@incident.com> References: <20120205171300.4FD5421F855D@ietfa.amsl.com><0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com><95C5C7A891135E4685CCFAE997351F960EE20C3C@WABOTH9MSGUSR8B.ITServices.sbc.com> <00797A22-C61C-4B2C-9A4D-11DC430BDC78@incident.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [atoca] Alert Gateways. 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, 05 Feb 2012 22:45:28 -0000 Hi Carl - Not sure how the W3C is using the term exactly, but the use of the word = "provenance" seems frequently to imply a transitive-trust approach to = ensuring data quality. The provenance, to use the noun form, is a = description of the "chain of custody" of some particular datum or = collection of data. That's a familiar approach, but like any chain it's = subject to breakage at any point. Whereas "attribution" (at least in the sense I learned in back in = journalism school) refers only to the original source and is agnostic as = to the subsequent path of the information; it's the sort of scheme we = sometimes implement using digital signatures. Ultimately both approaches are only as good as the confidence we can = have in our identification of the various actors. For several reasons, = liability included, I personally prefer end-to-end arrangements over = those that give multiple actors a chance to color the content = undetected. However, there are plenty of datasets, not least geospatial = datasets, that weren't signed originally, and in those cases some sort = of provenance is probably the best that can be done. At some point this turns into another one of those "end-to-end versus = money-in-the-middle" debates. Probably the best we can hope for is to = minimize the extent to which provenance and authentication become = conflated. They're related but not necessarily the same. - Art On Feb 5, 2012, at 2:12 PM, Carl Reed wrote: > Interesting how provenance is a key aspect of alerts/warnings. I am = somewhat involved in the W3C Provenance working group. They are defining = a conceptual model and language for communicating provenance. I provided = them a number of geo centric provenance use cases. This discussion = provides another (critical) use case. >=20 > Anyone have any thoughts on how best to "insert" the message = attribution (provenance) requirements into the W3C?? >=20 > The reason I ask is that the majority of the provenance WG members are = not alerting or geo literate. >=20 > Cheers >=20 > Carl >=20 >=20 > -----Original Message----- From: Art Botterell > Sent: Sunday, February 05, 2012 12:32 PM > To: atoca@ietf.org > Subject: Re: [atoca] Alert Gateways. >=20 > Of course the details of the liability question can vary from country = to country and even from actor to actor. (E.g., I'd be interested in = hearing what Google's policy is, and to see how it evolves over time.) >=20 > And much of the liability conversation is, necessarily, speculative = in nature. E.g., what, ultimately, is the difference between CMAS and, = say, Twitter? To some extent it's circular: CMAS is different = because... well... because we say it's different (i.e., "official.") = And what does it mean to be "official?" It means that access to it is = limited by political authority. And how is access limited? By being = able to attribute all inputs to sources that can be verified as having = whatever constitutes "official" status. >=20 > So ultimately, even the liability protection afforded to corporate = carriers in the U.S. in the context of CMAS is based on the ability of = the federal government to verify the provenance of each individual = message. >=20 > My point is merely that the particular arrangement of corporations = providing alert distribution under the protection of a national = government and by way of a central national gateway is a particular = instance, but probably not an immutable pattern on which global = standards can rest. Other organizations and/or governments might take = different approaches in other places. >=20 > However, I have difficulty imagining any system of alerting, be it an = open end-to-end architecture, a heavily-regulated intermediary or = something in between, that won't require a credible scheme for message = attribution. >=20 > - Art >=20 >=20 > On Feb 5, 2012, at 10:30 AM, DALY, BRIAN K wrote: >=20 >> To the point " the real issue isn't so much authority as = attribution", the other critical issue is liability protection for = distribution of the alert, such as what is offered to CMSPs under the = WARN Act. >>=20 >> Attribution is part of it, but also the distributor of the alert has = to be free from all liability for distribution of that alert so long as = it was received from the proper source (Federal Gateway here in the = U.S.) and there are sufficient legal liability protections in place = (from Congress under the WARN Act). >>=20 >> We consider all non-authority alerts - e.g. from day care centers, = schools, etc. - to be information sources unless they are registered = alert initiators through FEMA and their information comes from that = Federal Aggregator - and has sufficient liability protections as is = offered under the WARTN Act. >>=20 >> -------- >> Brian K. Daly >> Director, Core Network & Govn't/Regulatory Standards >> AT&T Services, Inc. >> +1.425.580.6873 >> brian.k.daly@att.com >>=20 >> Rethink Possible >>=20 >>=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of Art Botterell >> Sent: Sunday, February 05, 2012 10:19 AM >> To: atoca@ietf.org >> Subject: Re: [atoca] Alert Gateways. >>=20 >> Friends - >>=20 >> As Mark rightly points out, the notion of "authority" is by no means = a simple one. Although we tend to equate it to "governmental = authority," in practice that equation is complicated by several factors. = Among them: >>=20 >> 1) Delegation: There are places I know of where at least some of the = legal authority to issue public warnings has been delegated to = non-government actors within a policy framework. Thus, although the = policy is a function of government authority, the actual warning message = needs to be authenticated to a non-governmental source. >>=20 >> 2) Changing legal contexts: While in our time the power to advocate = public behavior has sometimes been seen as a monopoly of government, = there are political philosophies afield in a number of places, including = the U.S., that would change that. Regardless of how we may feel about = such movements, viewed against the backdrop of global history the notion = of such legal or political authority can't be considered immutable. >>=20 >> 3) Reciprocity across jurisdictions: When a hazard spans multiple = political jurisdictions, as they often do, and especially in an = environment where communications systems like broadcast and the Net also = span those boundaries, the problem of defining authority can exceed the = powers of any single agency. At the same time, governmental authority = is not always organized in a strict hierarchy; e.g., in California we = have numerous "special districts" for parks, utilities and so on that = span parts of several political subdivisions and that have legal powers = overlapping those of the political subdivision. >>=20 >> 4) Legal vs. audience-assigned authority: Although we tend to use the = term "authority" as shorthand for "legal authority," there's also the = factor of personal or moral authority in the eyes of the affected = public. Radio and television weather forecasters are a salient example = of actors who often are viewed as "authorities" by the public. Religious = and community leaders sometimes also act in that capacity. By the same = token, it's not unheard of for the authority/credibility of a government = to be low or even negative in the eyes of some audiences; sometimes = wrongly, sometimes not. >>=20 >> And all that is why, in my view, the real issue isn't so much = authority as attribution. As long as an alert can be traced reliably to = its source, different audiences can make their own judgements as to who = they trust in their own context and their own time. And without an = irrefutable mechanism for associating a message with its source, any = attempt at enforcing policy, even within a governmental framework, is = greatly weakened. (Whether there's ever a legitimate role for anonymous = "alerts" is another topic on which sincere folks may differ.) >>=20 >> Whereas if we set out to enforce certain trust relationships over = others we risk getting bogged down... unnecessarily, I believe... in the = eternal volatilities of politics. >>=20 >> - Art >>=20 >>=20 >> On Feb 5, 2012, at 9:12 AM, wrote: >>=20 >>>=20 >>> Friends, >>>=20 >>> There is a big difference in law between 'Information' and 'Alerts'. = Anyone >>> can say "Its raining quite a lot, old chap, really, really a lot", = but only >>> 'Authorities' can say "flooding expected in this area, evacuate now = via >>> highway 13". >>>=20 >>> (Art is an expert on this so I hope he can clarify the position). >>>=20 >>> I have been doing a lot of research into this matter, so if you = don't mind, >>> here are my thoughts. >>>=20 >>> In many countries, the matter of 'Civil Defence' is a matter of = national >>> security policy and is the remit of the 'Ministry of the Interior' = of the >>> sovereign state in whose territory the disaster is being "Hosted". >>>=20 >>> Often, strictly no other authority in the world is lawfully = permitted to >>> give instructions to the public in the territory of that sovereign = state, >>> (regardless of their nationality), other than those who have = statuary >>> instruments from the sovereign government concerned. >>>=20 >>> Therefore the matter will be different from Country to Country, and = if that >>> country is a Federal State, from State to State. >>>=20 >>> The best known present application of CAP is the USA FEMA IPAWS OPEN = system, >>> however CAP is a flexible framework and so other member states may = have >>> their own and different "Modus Operandi" from that of the USA. It's = not safe >>> to assume that the way IPAWS OPEN implements CAP in the USA will be = the same >>> as the way than another country does it. >>>=20 >>> For example, SAME codes and FIPS codes are not used in the UK, so = they will >>> definitely be different. But CAP was designed for flexibility. >>>=20 >>> Certainly IETF has no right to set standards on this matter. = Previous >>> attempts by very august UN agencies to set standards in this very = sensitive >>> area have failed due to *very vigorous* push-back from the member = states who >>> on no account will tolerate any interference in their interior = affairs in >>> this regard, well meaning or not. >>>=20 >>> Having said that, it's instructive to review the USA system; IPAWS = as one >>> "illustrative exemplary embodiment" but remember the above rant :-) >>>=20 >>> At the present time, in the USA, the vision is for FEMA IPAWS OPEN = system to >>> be a national alert gateway, the IPAWS OPEN gateway. Any alert = messages may >>> be 'pulled' from IPAWS OPEN for subsequent distribution by any = participating >>> network, but IPAWS OPEN is the national federal source of public = alert >>> information. >>>=20 >>> Regarding 'Originators', The FEMA IPAWS OPEN website explains the = procedure, >>> so that a prospective originator can become a 'Collaborating = Operating Group >>> (COG) and gain permission to submit proposals to IPAWS OPEN for = further >>> Authentication and Authorisation. There is a list of qualified = originators, >>> and Authorisation includes endorsement from the State Government, = among >>> other requirements. >>>=20 >>> Here is a link to the procedure; >>>=20 >>> http://www.fema.gov/emergency/ipaws/alerting_authorities.shtm >>>=20 >>>=20 >>>=20 >>> I am absolutely sure that no government in the world will feel any >>> differently. I have several clients who are looking at this matter, = and they >>> all understand this point well. Likely, the source for each = jurisdiction >>> will be well known and be appointed by the government. Likely there = will be >>> only one (logically one, but they will be clustered for redundancy). >>>=20 >>> So, just subscribe to the well known 'Alert Gateway' for the = jurisdiction of >>> interest. >>>=20 >>> The administrators of the gateway (probably a national or regional >>> government agency) will guarantee the Authentication and = Authorisation of >>> the senders according to a very complex set of national criteria = (which they >>> may or may not make fully public) and will probably be highly = dynamic. These >>> may take the form of a 'Trust Protocol' matrix of multilateral MoUs = or MoAs. >>>=20 >>>=20 >>> The distributing network (such as the enterprise) needs to have = immunity >>> from prosecution in case they transmit an alert which turns out to = be wrong. >>> The only lawful way for them to do this is to be sure they have a = *'Non >>> Repudiation'* trace back to the jurisdictional "Alert Gateway" for = the area >>> concerned. >>>=20 >>> Of course, the participating 'Distribution Network' may have = coverage over >>> areas which cover more than one Jurisdiction, but then it's an easy = matter >>> to get multiple feeds from the Alert Gateways in those jurisdictions = as they >>> will probably be very few. ('Information' may be different). >>>=20 >>> Any other solution would be very dangerous IMHO, as the = participating >>> distribution network may find that they are vulnerable to being sued = if >>> their information turns out to be not completely reliable. There are = strict >>> laws about all this. >>>=20 >>> But taking it from the "Alert Gateway" means they are covered by the >>> statutory instruments of the government agency operating the = gateway. Thus >>> they have indemnity from legal action provided they have not altered = the >>> contents of the message in any way. >>>=20 >>> For example messages in different languages are provided into the = gateway >>> and no network is expected to perform a transformation. >>>=20 >>> Information >>>=20 >>> Information and even 'Civic Information' is different. However = member states >>> are beginning to understand the issues now, so it's likely that = there will >>> be multiple 'Civic Information Gateways' also, for matters which = don't >>> qualify as 'Alerts' but still need mass distribution. My best guess = is that >>> they will be well advertised and that civic or non civic = institutions will >>> proudly point to them for the benefit of any distribution network = wishing to >>> participate. >>>=20 >>> In some countries, non governmental actors provide valued and = trusted >>> information for the public. In which case, it may be sent to the = alert >>> gateway, or the information gateway at the pleasure of the = government. Of >>> course a distribution network may have its own multilateral = arrangement such >>> as RSS for such less sensitive information feeds. >>>=20 >>> CellCast gateways, for example, are designed for either option as = each >>> government will have their own view on this and it will change a = lot. >>>=20 >>> Warm regards, Mark Wood, DRCF. >>>=20 >>>=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=20 From martin.thomson@gmail.com Mon Feb 6 16:34:08 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 AEE1F11E8085 for ; Mon, 6 Feb 2012 16:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.512 X-Spam-Level: X-Spam-Status: No, score=-4.512 tagged_above=-999 required=5 tests=[AWL=-0.913, 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 LLEqkOvLGZRA for ; Mon, 6 Feb 2012 16:34:07 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9176E11E80CB for ; Mon, 6 Feb 2012 16:34:07 -0800 (PST) Received: by bkbzt4 with SMTP id zt4so5772083bkb.31 for ; Mon, 06 Feb 2012 16:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z/E9jcwAJKXlAKMQvvk9DNbwVcNpOVU6LVrnDuZB8wc=; b=JUQXQleLT4BVmEYYtW2wsTDi7pi50WQLnYj30YbmRlZ1sC0YLdjXycYrqVQB7+xatW E9Dtr/9f+c39YLYjYF4vcV7e9f2VXOyVJAlMMANvj0K1Y5G6aYNRhDSIo1w2PT21m8o3 oOywr3ySq0rckqRdVwFb0DsGp7Yh8KQcPbgUU= MIME-Version: 1.0 Received: by 10.204.152.216 with SMTP id h24mr9637345bkw.15.1328574846676; Mon, 06 Feb 2012 16:34:06 -0800 (PST) Received: by 10.204.241.81 with HTTP; Mon, 6 Feb 2012 16:34:06 -0800 (PST) In-Reply-To: <16278387-4EC0-4EF7-BBDE-458BF8230C3F@incident.com> References: <20120205171300.4FD5421F855D@ietfa.amsl.com> <0D018B7D-CAC0-4F25-86B4-A68DF454FBDB@incident.com> <95C5C7A891135E4685CCFAE997351F960EE20C3C@WABOTH9MSGUSR8B.ITServices.sbc.com> <00797A22-C61C-4B2C-9A4D-11DC430BDC78@incident.com> <16278387-4EC0-4EF7-BBDE-458BF8230C3F@incident.com> Date: Mon, 6 Feb 2012 16:34:06 -0800 Message-ID: From: Martin Thomson To: Art Botterell Content-Type: text/plain; charset=UTF-8 Cc: atoca@ietf.org Subject: Re: [atoca] Alert Gateways. 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: Tue, 07 Feb 2012 00:34:08 -0000 This thread really boils down to one thing from my perspective. The set of entities that are trusted to provide alerts vary based on a number of factors: the alert recipient the subject, or the entity affected by the alert, which in many cases is the same as the alert recipient the location of the subject, which might have an influence on the next... the originator of the alert, which may have something to say about on the next... the nature and content of the alert And the entity that delivers the packet is not on this list. Hence the point on "provenance", which is quite relevant. To the largest extent possible, avoiding making judgements on these is our responsibility. Any technical mechanism needs to ensure that information is made available so that informed decisions are possible. There may well be cases where a service provider (for instance) provides a recipient with some information that informs their decisions about trust, but we can be very careful about how we structure these things. And I think that we have to be. If (for example) we provide a means for a network operator to provide their users with a set of certificates for users as a way to aid users in filtering out spam alerts, then the semantics can't be something like "here are your trust anchors". Something more appropriate would be: "these entities are trusted by our network", or weaker still: "these alert sources are legal in this jurisdiction". And I'm not even sure that is exactly the right phrasing/semantic either. --Martin From martin.thomson@gmail.com Fri Feb 24 08:53:28 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 8BCC021F87D2 for ; Fri, 24 Feb 2012 08:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=-1.056, 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 GGATEF0Y5PdT for ; Fri, 24 Feb 2012 08:53:25 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 691A421F87D7 for ; Fri, 24 Feb 2012 08:53:18 -0800 (PST) Received: by bkwj4 with SMTP id j4so726164bkw.31 for ; Fri, 24 Feb 2012 08:53:17 -0800 (PST) Received-SPF: pass (google.com: domain of martin.thomson@gmail.com designates 10.204.132.84 as permitted sender) client-ip=10.204.132.84; Authentication-Results: mr.google.com; spf=pass (google.com: domain of martin.thomson@gmail.com designates 10.204.132.84 as permitted sender) smtp.mail=martin.thomson@gmail.com; dkim=pass header.i=martin.thomson@gmail.com Received: from mr.google.com ([10.204.132.84]) by 10.204.132.84 with SMTP id a20mr1579711bkt.21.1330102397448 (num_hops = 1); Fri, 24 Feb 2012 08:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=zT3pKoZUbje05p4l2grM0w7KLgbLqS+OtbTTXwtx038=; b=OmRh3VlX/vabBZSXbJyi9AgPWXL5Ub3taxcXAy3ybSfGS4WgGWL4VO4Bud7qD1R/jt +P/myYsqntwTb+PggenkiJ6xPCC6+g4HHqPNuXbvihxd8Hec9H1+HdSYezJb1SuQlMpN uXc/lSOAzH/t7ee+6JXda+1zUHPZg99kTPA2M= MIME-Version: 1.0 Received: by 10.204.132.84 with SMTP id a20mr1302719bkt.21.1330102397379; Fri, 24 Feb 2012 08:53:17 -0800 (PST) Received: by 10.204.241.81 with HTTP; Fri, 24 Feb 2012 08:53:17 -0800 (PST) Date: Fri, 24 Feb 2012 08:53:17 -0800 Message-ID: From: Martin Thomson To: atoca@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [atoca] Draft Agenda 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, 24 Feb 2012 16:53:28 -0000 The following agenda for the Paris meeting has been uploaded. If you have a suggestion about alternatives, there is still time. Administrivia and Status (Chairs) 5m Update on requirements (Hannes) 30m - Goals and non-goals - Scaling issues - Security analysis Alert Source Discovery (Richard/Brian) 10m