Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00
Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Tue, 20 July 2010 13:13 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 EF35E3A684A for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 06:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.635
X-Spam-Level:
X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.964, 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 cpWK4t2Vptft for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 06:13:45 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id BEFB63A6B05 for <earlywarning@ietf.org>; 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 [172.30.172.109]) [213.162.68.136] by mail.gmx.net (mp009) with SMTP; 20 Jul 2010 15:13:50 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19bpsh4xU5bWng4ixx45Jey3PShvTKIf8YJqOgjjn pSljy1ty3aIqkv
Message-ID: <4C45A133.3090200@gmx.net>
Date: Tue, 20 Jul 2010 15:14:27 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: "Thomson, Martin" <Martin.Thomson@andrew.com>
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com>
In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com>
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)" <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: 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 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] Comments on draft-schulzrinne-atoc… Thomson, Martin
- Re: [earlywarning] Comments on draft-schulzrinne-… Tony Rutkowski
- Re: [earlywarning] Comments on draft-schulzrinne-… Hannes Tschofenig
- Re: [earlywarning] Comments on draft-schulzrinne-… Brian Rosen
- Re: [earlywarning] Comments on draft-schulzrinne-… Hannes Tschofenig
- Re: [earlywarning] Comments on draft-schulzrinne-… Tony Rutkowski
- Re: [earlywarning] Comments on draft-schulzrinne-… Hannes Tschofenig
- Re: [earlywarning] Commentson draft-schulzrinne-a… Carl Reed
- Re: [earlywarning] Commentson draft-schulzrinne-a… Hannes Tschofenig
- Re: [earlywarning] Comments on draft-schulzrinne-… Thomson, Martin
- Re: [earlywarning] Comments on draft-schulzrinne-… Thomson, Martin
- Re: [earlywarning] Comments on draft-schulzrinne-… Hannes Tschofenig
- Re: [earlywarning] Comments on draft-schulzrinne-… Hannes Tschofenig
- Re: [earlywarning] Commentson draft-schulzrinne-a… Carl Reed
- Re: [earlywarning] Comments on draft-schulzrinne-… Thomson, Martin
- Re: [earlywarning] Comments on draft-schulzrinne-… Brian Rosen