Re: [atoca] My use cases

Hannes Tschofenig <hannes.tschofenig@gmx.net> Sat, 14 January 2012 09:38 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: atoca@ietfa.amsl.com
Delivered-To: atoca@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01B521F85E7 for <atoca@ietfa.amsl.com>; Sat, 14 Jan 2012 01:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level:
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlxmezOtL+VI for <atoca@ietfa.amsl.com>; Sat, 14 Jan 2012 01:38:13 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1DAA221F85D4 for <atoca@ietf.org>; Sat, 14 Jan 2012 01:38:12 -0800 (PST)
Received: (qmail invoked by alias); 14 Jan 2012 09:38:10 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp063) with SMTP; 14 Jan 2012 10:38:10 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/HLAYWSRLH3D39x8/JiGbWNOc3qPR6m1QV+U1IWN aZR9KW9M4Afq96
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
In-Reply-To: <2A85B59A-913B-4340-8C26-F938C3152F62@neustar.biz>
Date: Sat, 14 Jan 2012 11:38:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1867C285-B927-4318-87F5-9851F4DEC06D@gmx.net>
References: <6E44DEC6-5B9A-4214-9A44-D7C45FDB4449@neustar.biz><201111180536.pAI5aa7P007978@mtv-core-4.cisco.com><8C9312A2-CF99-46D3-B174-5959A3D11C18@neustar.biz><p06240602caeba4787561@dhcp-44e5.meeting.ietf.org> <FBD11BDD-22DA-40DB-BF67-CFCD762B5DA7@neustar.biz> <1B6A274DF90F4579BB875EBD53F8311B@OfficeHP> <2A85B59A-913B-4340-8C26-F938C3152F62@neustar.biz>
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: "atoca@ietf.org" <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." <atoca.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/atoca>, <mailto:atoca-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/atoca>
List-Post: <mailto:atoca@ietf.org>
List-Help: <mailto:atoca-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/atoca>, <mailto:atoca-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Jan 2012 09:38:14 -0000

Hi Brian, Carl, Marc, Richard, Randy James,  

if someone of you wants to collect text about the various different detailed use cases that's fine with me. I do, however, not see the need in our case. 

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

I don't see what the impact for an alert transport when a national authority vs. local authority approves the distribution of the warnings. 

I also do not see how the opt-in matters in many cases either, unless it has an impact for the protocols. So far we have a few requirements listed in Section 4.2 "Requirements for Alert Subscription" that IMHO covers the relevant aspects. 

What the uses cases, however, show is that there are two types of communication protocol classes, namely one that uses unicast delivery and a second one that relies on broadcast delivery. This is, btw, also supported by Richard's protocol strawman proposal. It seems to design a new protocol from scratch for (a) and (b). 
This is also what the current document talks about.

Ciao
Hannes


On Nov 20, 2011, at 5:10 PM, Rosen, Brian wrote:

> The use cases we are looking for now define our scope.
> 
> I have no problem with gleaning what we can from other's work.
> 
> I do think we have tried to include use cases beyond what is traditionally defined as authority to citizen alerting.
> 
> Right at the moment, we're mostly checking to see that we agree on scope.
> 
> Brian
> 
> On Nov 18, 2011, at 11:16 AM, Carl Reed wrote:
> 
>> For argument sake, should this group be defining alert use cases or should we be seeking well known, established and documented use cases? I suspect that many nations and jurisdictions have already defined use cases based on knowledge and requirements from the EM community.
>> 
>> Many are described in the ISCRAM proceedings:
>> For example: http://www.iscram.org/ISCRAM2009/papers/Contributions/167_CAP-ONES%20An%20Emergency%20Notification%20System_Malizia2009.pdf
>> 
>> And of course the US Government:
>> http://www.fema.gov/library/viewRecord.do?id=3999
>> http://clarus.meridian-enviro.com/nwpassage/files/NWPassage_ClarusUseCaseScenarios.pdf
>> 
>> And I know, based on discussions with the alerting community in Canada as part of ongoing CAP work, that are some excellent use cases defined by the Canadian alerting community.
>> 
>> And of course a variety of international activities such as those in GEO, WMO, and INSPIRE:
>> 
>> For example: http://www.wmo.int/pages/mediacentre/factsheet/Earlywarning_en.html
>> 
>> Cheers
>> 
>> Carl
>> 
>> 
>> -----Original Message----- From: Rosen, Brian
>> Sent: Thursday, November 17, 2011 11:20 PM
>> To: Randall Gellens
>> Cc: atoca@ietf.org
>> Subject: Re: [atoca] My use cases
>> 
>> I think that the ISPs know who the local/regional/state/national authorities are, and can provide their credentials to endpoints.  I think "discovery" of an enterprise alert server is probably more conventional domain based and the act of subscribing establishes the credential exchange. While you don't really need object security for that case, I think we have it anyway for the broadcast case.
>> 
>> It's not a bad idea to have object security.  I'm not sure we really want to use some form of transport security if we have a good object security model.
>> 
>> So you get the credentials of the notifiers from the distribution point, and the objects are secured with those credentials.
>> 
>> Brian
>> 
>> On Nov 18, 2011, at 1:01 AM, Randall Gellens wrote:
>> 
>>> 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.
>>> 
>>> So, the authorization for an alert in the case of government is up to
>>> the ISPs in an area within the jurisdiction?  And for
>>> enterprise/organizational alerts, presumably the alert servers are
>>> federated and have local authorization?
>>> 
>>> -- 
>>> Randall Gellens
>>> Opinions are personal;    facts are suspect;    I speak for myself only
>>> -------------- Randomly selected tag: ---------------
>>> I'm prepared for all emergencies but totally unprepared for
>>> everyday life.
>> 
>> _______________________________________________
>> 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