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

"Thomson, Martin" <Martin.Thomson@andrew.com> Wed, 21 July 2010 00:23 UTC

Return-Path: <Martin.Thomson@andrew.com>
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 1F4ED3A6987 for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 17:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.057
X-Spam-Level:
X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=-0.458, 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 Op9CAO+lE6Nr for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 17:23:11 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 38A383A680B for <earlywarning@ietf.org>; Tue, 20 Jul 2010 17:23:11 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:56948 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S340569Ab0GUAX0 (ORCPT <rfc822; earlywarning@ietf.org>); Tue, 20 Jul 2010 19:23:26 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 19:23:26 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 21 Jul 2010 08:23:22 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Date: Wed, 21 Jul 2010 08:25:31 +0800
Thread-Topic: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00
Thread-Index: AcsoDWysGmths4EKTqOu849Vc/kKbQAW1G3A
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77315C@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com> <4C45A133.3090200@gmx.net>
In-Reply-To: <4C45A133.3090200@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>, "earlywarning@ietf.org" <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 00:23:12 -0000

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.

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-’


> 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.

..
--Martin