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

Hannes Tschofenig <> Tue, 20 July 2010 13:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF35E3A684A for <>; Tue, 20 Jul 2010 06:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.635
X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cpWK4t2Vptft for <>; Tue, 20 Jul 2010 06:13:45 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id BEFB63A6B05 for <>; Tue, 20 Jul 2010 06:13:44 -0700 (PDT)
Received: (qmail invoked by alias); 20 Jul 2010 13:13:50 -0000
Received: from unknown (EHLO []) [] by (mp009) with SMTP; 20 Jul 2010 15:13:50 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19bpsh4xU5bWng4ixx45Jey3PShvTKIf8YJqOgjjn pSljy1ty3aIqkv
Message-ID: <>
Date: Tue, 20 Jul 2010 15:14:27 +0200
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: "Thomson, Martin" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <>, "" <>
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Jul 2010 13:13:47 -0000

Hi Martin,

a little bit of background on this document as well.

Initially the document started out as a requirements document (see 
and also looked quite a bit to the work done at other SDOs in that area. 
Other SDOs do, however, not really focus on the Internet landscape and 
hence the requirements were very specific to their access network 
technology, focused on user interface issues, the alert content, or were 
rather obvious.

We tried to restructure the requirements but it became clear that the 
absence of an architectural description makes it really difficult to 
produce anything meaningful.

Finally, the lack of uniform terminology was noticed.

Version -02 of the draft then had some architectural pieces in there:

However, at that time we were still looking for terminology and we 
couldn't find anything useful. Then, the email architecture document was 
flying around and the terminology and architecture description seemed to 
be a good match. We were also able to abstract the problem space a bit. 
We then re-used the email terminology in version -03:

Now, with the latest version the document focuses on the terminology, 
and the architectural description. It does not really  include a problem 
statement. The number of requirements are considerably smaller than in 
the -00 version but there are still too many of the obvious onces. There 
is at least the separation into the different models (subscription model 
vs. push communication).

I agree that the model is quite sophisticated but we are clearly 
building on top of an existing infrastructure and hence I believe it 
makes sense. Let's have a look at it:

        ++==========++                        ++===========++
        ||  Author  ||                        || Recipient ||
        ++====++====++   +--------+           ++===========++
              ||         | Return |                  /\
              ||         +-+------+                  ||
              \/           .    ^                    ||
         +----------+      .    .                +---++----+
         |          |      .    .                |         |
       | |          |      .    .      MHS       |         |   |
       | |Originator+<...........................+Receiver |   |
       | |          |           ^                |         |   |
       | +---++-----+           .                +---------+   |
       |     ||                 .                    /\        |
       |     ||  ...............+..................  ||        |
       |     \/  .              .                 .  ||        |
       | +-------+-+         +--+------+        +-+--++---+    |
       | |  Relay  +======-=>|  Relay  +=======>|  Relay  |    |
       | +---------+         +----++---+        +---------+    |
       |                          ||                           |
       |                          ||                           |
       |                          \/                           |
       |                     +---------+                       |
       |                     | Gateway +-->...                 |
       |                     +---------+                       |

I believe it is important to source and the sink from the rest. Here the Author and the Recipient are sources and sinks, respectively.
In many cases the Author is a human who has to write alerts and prepare them for distribution.

Then, the actual message handling service consists of a few very reasonable entities, namely the originator, relay, gateway, and receiver.
We have these entities in the SIP, and the XMPP context.

The only entity I was not quite sure about is the "return handler".

I am not saying that there is no room for improving the description but I saw a lot of value in re-using an existing description than coming
up with something entirely new.

A few more notes inline:

On 16.07.2010 06:38, Thomson, Martin wrote:
> I'm currently unsure about the value of this document.  The different components of the document are somewhat disjointed: problem statement, architectural model, and requirements don't support each other particularly well.
> General Comments:
> This model presented in this document is highly abstract.  Without a more concrete relationship with the requirements, it's hard to understand the value of the model.  Section 3 looks too much like a copy-and-paste from the email architecture.
> A simpler model might be a better starting point:
>    author [1..*] ->  [1] aggregator [1] ->  [1..*] recipient
> Such a model can be evolved to involve relays or mediators by overlapping and chaining roles, just as we do for the GEOPRIV model.  Nothing wrong with giving these entities names and descriptions, but they can form part of a second architectural layer.
> Specific Comments:
> Section 1: Can we not simplify the three modes?
>    1. Broadcast to devices based on their physical location.
>    2. Broadcast to devices based on some defining characteristic (they might be a siren or ventilation control system, they might be owned by an emergency medicine practitioner or fireman, and so on).
>    3. Broadcast to devices based on some criteria that has been arranged prior to the event (i.e., subscription).
> When characterized in this fashion, it's not obvious to me that the location case is special enough to warrant a separate category.  After all, I can imagine that warning criteria might be a union of two.  For example, deliver this alert to all emergency medicine practitioners in a this area.
> On the topic of legacy devices, can we not abstract them out by having a conversion device act as a proxy for those.  Legacy interactions probably needs more analysis, separate to this preliminary section.  This includes legacy devices as well as existing warning systems, like cell broadcast.

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

This is still push communication but clearly different from #1. It is 
different from #3 since there is an implicit subscription.

3. Subscription Model

> Section 3.1.3:  Is a return handler really a necessary part of the architecture?  Examining the sorts of feedback that the system is likely to generate might lead to an entirely different conclusion.

No, it is not necessary I believe.



> _______________________________________________
> earlywarning mailing list