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

For me, the GLIDE number was of interest, particularly in the design of the service URN space.  It might be worth looking into a comparison of the two taxonomies.

From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
Sent: Wednesday, 21 July 2010 4:33 AM
To: trutkowski@netmagic.com
Cc: Thomson, Martin; Tschofenig, Hannes (NSN - FI/Espoo); earlywarning@ietf.org
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

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<mailto:earlywarning@ietf.org>
https://www.ietf.org/mailman/listinfo/earlywarning