Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Wed, 21 July 2010 09:22 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3BDE3A6B94 for <earlywarning@core3.amsl.com>; Wed, 21 Jul 2010 02:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsiBvBFfl9pi for <earlywarning@core3.amsl.com>; Wed, 21 Jul 2010 02:22:37 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id F1B0A3A6B85 for <earlywarning@ietf.org>; Wed, 21 Jul 2010 02:22:36 -0700 (PDT)
Received: (qmail 30102 invoked by uid 0); 21 Jul 2010 09:22:52 -0000
Received: from 212.67.227.34 by www055.gmx.net with HTTP; Wed, 21 Jul 2010 11:22:49 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Date: Wed, 21 Jul 2010 11:22:49 +0200
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB77315C@SISPE7MB1.commscope.com>
Message-ID: <20100721092249.160040@gmx.net>
MIME-Version: 1.0
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com> <4C45A133.3090200@gmx.net> <8B0A9FCBB9832F43971E38010638454F03EB77315C@SISPE7MB1.commscope.com>
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX1+posobHHqpBidtDDLrMXkpgo2Rngi+bi1/uU56qP ZQ07RH/tbpwL/+RPpigu06CT1v2dfHSFx4SA==
Content-Transfer-Encoding: 8bit
X-GMX-UID: DdUjDepKfW47Tsk5tWRoanNudmllckXr
X-FuHaFi: 0.53000000000000003
Cc: hannes.tschofenig@nsn.com, earlywarning@ietf.org
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00
X-BeenThere: earlywarning@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/earlywarning>
List-Post: <mailto:earlywarning@ietf.org>
List-Help: <mailto:earlywarning-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/earlywarning>, <mailto:earlywarning-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Jul 2010 09:22:39 -0000

Hi Martin, 

a quick reply to your comment below. 

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 08:25:31 +0800
> Von: "Thomson, Martin" <Martin.Thomson@andrew.com>
> An: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" <hannes.tschofenig@nsn.com>om>, "earlywarning@ietf.org" <earlywarning@ietf.org>
> Betreff: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

> Hi Hannes,
> 
> Good terminology and a consistently applied architectural model help
> greatly.  My concern is that the email architecture has been appropriated a
> little too liberally.
> 
> For an end-to-end model, such as you have selected, then a simpler
> introduction might make it easier to understand.  This application has far less
> baggage than email, and far less accumulated knowledge.


I like the step-wise refinement approach you are suggesting. 

> 
> Highest layer: Basic goal:
> 
>    Author --> Recipient
> 
> Next layer: Actors use devices:
> 
>  Author --> Originator ==> Receiver --> Recipient
> 
> Next layer: Recognize deployment constraints:
> 
>   Author --> Originator ==> Relay(s) ==> Receiver --> Recipient 
> 
> and
> 
>   Author --> Originator ==> Relay(s) ==> Gateway [--> Recipient]
> 
> > The only entity I was not quite sure about is the "return handler".
> 
> The mediator role also seems redundant in this architecture, so unless you
> have a strong use case, I'd advocate for its removal:
> 
>   Author --> Recipient == Author --> Recipient
>                 \            /
>                  `-Mediator-’
> 


The mediator is essentially another name for an aggregator. I believe that the role of an aggregator is going to be very common in these types of alert distribution services (from a security point of view in particular). 

While I see lots of "end-to-end" mechanisms being used for weather alert I have my doubt that the same type of approach is used for other, more governmental focuses alerts. 

I initially used the term "aggregator" but with the email terminology I did not want to step away from what has been suggested there.

One example for an aggregator is the work Google is doing with their Kipendo, see http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2008/Google.ppt. 


(I am fine with dropping the return handler.)

> 
> > A few more notes inline:
> > 
> > Currently, we have the following models in the draft that try to
> > classify the technological mechanisms being used:
> > 
> >     1.  Alerts may be addressed to all individuals within a certain
> >         geographic area.  Today, this is often realized with the help
> > of
> >         dedicated functionality provided by link layer technology
> > (e.g.,
> >         multicast, broadcast).
> > 
> > 
> > The work in other SDOs has focused on this topic. In fact many of the
> > alerts are rather sent to a specific network topology (such as specific
> > set of base stations) than with a specific location focus. The
> > assumption obviously is that a specific BS covers a specific location.
> > 
> > 2.  Alerts need to be delivered to dedicated end points via unicast
> >         messaging.
> > 
> > 
> > This is still push communication but clearly different from #1. It is
> > different from #3 since there is an implicit subscription.
> 
> The prior existence (or not) of mechanisms seems like poor justification
> for the sorts of classification you are describing.  The implicit
> subscription concept seems like a more compelling categorization.
> 
> However, it's not clear to me that a subscription is not possible in at
> least some of these cases.  We probably need more input on that aspect.
> 
I am looking forward to hear other classifications. 
When looking at the charter text and the deliverables I believe the current classification makes some sense. 

Item #3 refers to the event package, item #2 refers to conveyance of CAP, and item #1 refers to the interworking and lower layer considerations. 


Ciao
Hannes

> ..
> --Martin
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning