[earlywarning] Regarding your comments about requirements

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Tue, 20 July 2010 13:56 UTC

Return-Path: <Hannes.Tschofenig@gmx.net>
X-Original-To: earlywarning@core3.amsl.com
Delivered-To: earlywarning@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 3E2FF3A694A for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 06:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id o16QX7yhCBcK for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 06:56:55 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net []) by core3.amsl.com (Postfix) with SMTP id D53D43A681C for <earlywarning@ietf.org>; Tue, 20 Jul 2010 06:56:54 -0700 (PDT)
Received: (qmail invoked by alias); 20 Jul 2010 13:57:08 -0000
Received: from unknown (EHLO []) [] by mail.gmx.net (mp044) with SMTP; 20 Jul 2010 15:57:08 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19kUrEgo2NkVrLSylsNsMDszsw2w48rr5zPp5DKqa s/k0UBywQNckt+
Message-ID: <4C45AB5D.40707@gmx.net>
Date: Tue, 20 Jul 2010 15:57:49 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
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: "earlywarning@ietf.org" <earlywarning@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: [earlywarning] Regarding your comments about requirements
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:56:56 -0000

Hi Martin,

I copied your comments regarding the requirements into a separate mail:

Section 4:  Some of the requirements are a little hard to assess.  The model is quite abstract and the requirements are quite disjoint from it.  Try to be more specific, and so will I ;)

Req-G3:  This is too broad a requirement.  What security aspects are we concerned with?  It's possible that we are concerned with a large number of things: integrity, authentication of the source of a message, authorization of sources.


       The protocol solution MUST offer the typical communication
       security mechanisms.  Additional security mechanisms applied to
       the alert message itself are outside the scope of the
       communication protocol and therefore outside the scope of this

I agree with your statement about the security requirement. The security consideration section already covers the aspects you worry about.

Req-G5:  This is a difficult requirement for me to assess.  If the purpose of the system is to deliver messages, what does the author (?) gain by having the recipient (?) acknowledge receipt?


       The protocol solution MAY provide an option to return a receipt on
       reading message.

I don't recall where this requirement came from anymore. I would suggest to delete it and wait till somone screams.

For something that is required to scale in the fashion that we have imagined, forms of feedback might be vastly different from what we imagine from email return receipts.

[hannes] This requirement did not come from the email world.

  For instance, if an alert to evacuate a city is sent, the author doesn't want to hear from each of the million recipients that they got the message.  Some form of aggregated data is probably going to be most useful.  I'm not sure about the smaller scale, maybe a fully closed-loop feedback system is needed for some use cases.

Req-S2 and Req-S3: These don't indicate the direction that this information flows in: i.e., location flows from recipient to the subscription service.


       The protocol solution MUST allow an indication about the
       geographical area the potential Recipient is interested in.


       The protocol solution MUST allow an indication about the type of
       alert the potential Recipient is interested in.

The subscriber indicates this preference when it sends a subscribe message. You are right that this should be indicated.