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

Brian Rosen <br@brianrosen.net> Tue, 20 July 2010 13:22 UTC

Return-Path: <br@brianrosen.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 6333B3A6BE6 for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 06:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.967
X-Spam-Level:
X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.632, 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 3xmuYoveq6SE for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 06:22:24 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 1AE043A6889 for <earlywarning@ietf.org>; Tue, 20 Jul 2010 06:22:24 -0700 (PDT)
Received: from [209.173.57.233] (helo=[192.168.130.13]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1ObCmA-0006Cs-0b; Tue, 20 Jul 2010 08:22:31 -0500
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <4C45A133.3090200@gmx.net>
Date: Tue, 20 Jul 2010 09:22:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2F8FD1A-691F-4E7B-A7AD-83C24605F6C6@brianrosen.net>
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com> <4C45A133.3090200@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
Cc: "earlywarning@ietf.org" <earlywarning@ietf.org>, "Tschofenig, Hannes \(NSN - FI/Espoo\)" <hannes.tschofenig@nsn.com>
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: Tue, 20 Jul 2010 13:22:25 -0000

One note on return handlers.  The sender doesn't need an acknowledgement of receipt from each recipient.  The recipient however needs  very high reliability in getting the alert, which may involve some kind of handshake in some mechanisms.

Brian
On Jul 20, 2010, at 9:14 AM, Hannes Tschofenig wrote:

> Hi Martin,
> 
> a little bit of background on this document as well.
> 
> Initially the document started out as a requirements document (see http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-00) 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:
> http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-02
> 
> 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: http://tools.ietf.org/html/draft-norreys-ecrit-authority2individuals-requirements-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
>       messaging.
> 
> 
> 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.
> 
> 
> ~snip~
> 
> 
> Ciao
> Hannes
> 
>> _______________________________________________
>> earlywarning mailing list
>> earlywarning@ietf.org
>> https://www.ietf.org/mailman/listinfo/earlywarning
>>   
> 
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning