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

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>, "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