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

Hannes Tschofenig <Hannes.Tschofenig@gmx.net> Tue, 20 July 2010 18:33 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 69D5A3A6B47 for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 11:33:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 JRiQZFMD2Yaj for <earlywarning@core3.amsl.com>; Tue, 20 Jul 2010 11:32:26 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 68D943A68BE for <earlywarning@ietf.org>; Tue, 20 Jul 2010 11:32:25 -0700 (PDT)
Received: (qmail invoked by alias); 20 Jul 2010 18:32:39 -0000
Received: from unknown (EHLO [172.31.172.50]) [213.162.68.166] by mail.gmx.net (mp068) with SMTP; 20 Jul 2010 20:32:39 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/ENWkokv/EjZK+i/p4dP/Fr3EwdmauGk63JDdpTL DRJviAHQjweJ3A
Message-ID: <4C45EBEE.9030509@gmx.net>
Date: Tue, 20 Jul 2010 20:33:18 +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: trutkowski@netmagic.com
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3B0@SISPE7MB1.commscope.com> <4C403CFE.4020208@netmagic.com>
In-Reply-To: <4C403CFE.4020208@netmagic.com>
Content-Type: multipart/alternative; boundary="------------050703080507000605010309"
X-Y-GMX-Trusted: 0
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 18:33:21 -0000

Hi Tony,

thanks for pointing to the CAP Implementer's workshop and in particular 
the "Draft Implementors Note on Harmonizing Certain Identifiers in CAP 
Implementations" 
http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DraftNote.doc. 


My understanding of that document (and my participation at an earlier 
workshop) is there is room for improvement in the CAP specification from 
an interoperability point of view.

Since the work in this group only focuses on the transport of alerts 
rather than the actual content of the alerts we should not be impacted.

Ciao
Hannes

On 16.07.2010 13:05, Tony Rutkowski wrote:
>  Hi Martin,
>
> You might also consider the concepts on architecture
> and identity constructs that emerged from last year's
> global gathering of emergency messaging authorities
> convened at the World Meteorological Organization.
> http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2009/DocPlan.html 
>
>
> See especially the Draft Implementors Note.
>
> best,
> tony
>
>> 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.
>>
>
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning