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

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 16 Jul 2010 12:38:22 +0800

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.

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.

Section 3.2: The description here talks about "exchanges" that might be protracted.  The two reasons for this that I can imagine would be a) bidirectional interactions (implied by the word "exchanges", but that might just be a malapropism, "transfers" seems more apropos here), or b) delays in mediation functions.  I don't see that the logical architecture needs this sort of complexity, see above.

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.  

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?

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.  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.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 16 Jul 2010 07:05:34 -0400

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Jul 2010 15:14:27 +0200

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 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…

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 conclusio…

No, it is not necessary I believe.

~snip~

Ciao
Hannes

> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Jul 2010 09:22:25 -0400

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:

> 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.
> 
> 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:
> 
> 
> Currently, we have the following models in the draft that try to classify the technological mechanisms being used:
> 
> 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.
> 
> This is still push communication but clearly different from #1. It is different from #3 since there is an implicit subscription.
> 
> 3. Subscription Model
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 20 Jul 2010 20:33:18 +0200

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:
>> 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.
>>
>> 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.
>>
>

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 20 Jul 2010 14:41:06 -0400

On 7/20/2010 2:33 PM, Hannes Tschofenig wrote:
>
> 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.

Dear Hannes,

Probably...except note that the conceptualization of
the early warning OID namespace includes tagging for
all objects, including messages as well as organization
entities.  There is also an ongoing discussion about
the desirability of binding the identifiers to EVcerts.
So components of this work could affect transport
layers/protocols.

--tony

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 20 Jul 2010 21:21:45 +0200

Hi Tony, 

When I look at the available sites that offer CAP alerts then I see email alike identifiers (rather than OIDs). 

I wonder whether using OID was a deployment friendly choice. 

Anyway, someone will have to figure out how these OIDs in the CAP alerts relate to signatures protecting CAP alerts. 

Still, this has nothing to do with the transport since the identity in the cert, the content of the sender element of the CAP alert, and the identity in the SIP messages (From field) are less like to all match...

Ciao
Hannes

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 20 Jul 2010 14:33:05 -0600

Correct -

CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0 will incorporate a GML profile that will include the same geometry types (plus additional ones) as the LO GML Geoshape Application Schema.  The only issue is that the OASIS GML "where" profile will use GML 3.2.1 to be consistent with the ISO version of GML and the LO Geoshape schema uses GML 3.1.1.

Cheers

Carl
an OASIS CAP contributor
  ----- Original Message ----- 
  From: Hannes Tschofenig 
  To: [email-masked] 
  Cc: [email-masked] ; Tschofenig,Hannes (NSN - FI/Espoo) 
  Sent: Tuesday, July 20, 2010 12:33 PM
  Subject: Re: [earlywarning] Commentson 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

    best, 
    tony 

      General Comments: 

------------------------------------------------------------------------------

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 20 Jul 2010 22:38:18 +0200

Good to hear that CAP 2.0 will include a GML profile. 
What location shapes are going to be supported? We ran into this issue in ECRIT. 

-------- Original-Nachricht --------
> Datum: Tue, 20 Jul 2010 14:33:05 -0600
> Von: "Carl Reed" <[email-masked]>
> An: "Hannes Tschofenig" <[email-masked]>, [email-masked]
> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" <[email-masked]>, [email-masked]
> Betreff: Re: [earlywarning]	Commentson	draft-schulzrinne-atoca-requirements-00

> Correct -
> 
> CAP is a payload and is (theoretically) transport agnostic. FYI, CAP 2.0
> will incorporate a GML profile that will include the same geometry types
> (plus additional ones) as the LO GML Geoshape Application Schema.  The only
> issue is that the OASIS GML "where" profile will use GML 3.2.1 to be
> consistent with the ISO version of GML and the LO Geoshape schema uses GML 3.1.1.
> 
> Cheers
> 
> Carl
> an OASIS CAP contributor
> workshop) is there is room for improvement in the CAP specification from an
> interoperability point of view.
> 
>       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: 
> 
> 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. 
> 
> 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. 
> 
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Jul 2010 07:22:21 +0800

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:[email-masked]]
Sent: Wednesday, 21 July 2010 4:33 AM
To: [email-masked]
Cc: Thomson, Martin; Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]
Subject: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

Hi Tony,

Ciao
Hannes

best,
tony

General Comments:

_______________________________________________
earlywarning mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/earlywarning

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 21 Jul 2010 08:25:31 +0800

Hi Hannes,

Good terminology and a consistently applied architectural model help greatly.  My concern is that the email architecture has been appropriated a little too liberally.

For an end-to-end model, such as you have selected, then a simpler introduction might make it easier to understand.  This application has far less baggage than email, and far less accumulated knowledge.

Highest layer: Basic goal:

   Author --> Recipient

Next layer: Actors use devices:

 Author --> Originator ==> Receiver --> Recipient

Next layer: Recognize deployment constraints:

  Author --> Originator ==> Relay(s) ==> Receiver --> Recipient 

and

  Author --> Originator ==> Relay(s) ==> Gateway [--> Recipient]

> The only entity I was not quite sure about is the "return handler".

The mediator role also seems redundant in this architecture, so unless you have a strong use case, I'd advocate for its removal:

  Author --> Recipient == Author --> Recipient
                \            /
                 `-Mediator-’

> different from #3 since there is an implicit subscription.

The prior existence (or not) of mechanisms seems like poor justification for the sorts of classification you are describing.  The implicit subscription concept seems like a more compelling categorization.

However, it's not clear to me that a subscription is not possible in at least some of these cases.  We probably need more input on that aspect.

..
--Martin

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Jul 2010 11:22:49 +0200

Hi Martin, 

a quick reply to your comment below. 

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 08:25:31 +0800
> Von: "Thomson, Martin" <[email-masked]>
> An: Hannes Tschofenig <[email-masked]>
> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" <[email-masked]>, "[email-masked]" <[email-masked]>
> Betreff: Re: [earlywarning] Comments on draft-schulzrinne-atoca-requirements-00

> Hi Hannes,
> 
> Good terminology and a consistently applied architectural model help
> greatly.  My concern is that the email architecture has been appropriated a
> little too liberally.
> 
> For an end-to-end model, such as you have selected, then a simpler
> introduction might make it easier to understand.  This application has far less
> baggage than email, and far less accumulated knowledge.

I like the step-wise refinement approach you are suggesting. 

> The mediator role also seems redundant in this architecture, so unless you
> have a strong use case, I'd advocate for its removal:
> 

The mediator is essentially another name for an aggregator. I believe that the role of an aggregator is going to be very common in these types of alert distribution services (from a security point of view in particular). 

While I see lots of "end-to-end" mechanisms being used for weather alert I have my doubt that the same type of approach is used for other, more governmental focuses alerts. 

I initially used the term "aggregator" but with the email terminology I did not want to step away from what has been suggested there.

One example for an aggregator is the work Google is doing with their Kipendo, see http://www.wmo.int/pages/prog/www/ISS/Meetings/WIS-CAP_Geneva2008/Google.ppt. 

(I am fine with dropping the return handler.)

> The prior existence (or not) of mechanisms seems like poor justification
> for the sorts of classification you are describing.  The implicit
> subscription concept seems like a more compelling categorization.
> 
> However, it's not clear to me that a subscription is not possible in at
> least some of these cases.  We probably need more input on that aspect.
> 
I am looking forward to hear other classifications. 
When looking at the charter text and the deliverables I believe the current classification makes some sense. 

Item #3 refers to the event package, item #2 refers to conveyance of CAP, and item #1 refers to the interworking and lower layer considerations. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Jul 2010 11:30:08 +0200

Hi Martin, 

I searched around a bit and found this document:
http://www.adrc.asia/publications/TDRM2003Dec/19_MR.%20SATORU%20NISHIKAWA.pdf

That document introduced another classification, which I believe is different from what can be found in the CAP document. 

I wonder how the two relate to each other. 

I suspect that there will never be an agreement on the categories and the only way to go with this is to
* just define a top level service 
* pick a few sub-level services
* provide extension points. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Wed, 21 Jul 2010 07:22:21 +0800
> An: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, "Tschofenig, 	Hannes \\(NSN - FI/Espoo\\)" <[email-masked]>

> 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.
> 
> 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.
> 
> 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.
>

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 21 Jul 2010 15:23:55 -0600

The requirements document is attached.

Regards

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "Carl Reed" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 20, 2010 2:38 PM
Subject: Re: [earlywarning] Commentson 
draft-schulzrinne-atoca-requirements-00

>> CC: "Tschofenig, Hannes \\(NSN - FI/Espoo\\)" 
>> <[email-masked]>, [email-masked]
>> Nothing

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 22 Jul 2010 08:40:47 +0800

> * provide extension points.

I'm starting to think that avoiding taxonomies should be a goal.  Let's see if we can't avoid it first.

---

From: Brian Rosen <[email-masked]>
Date: Thu, 22 Jul 2010 08:59:01 -0400

My problem with this is that it shifts the burden to the endpoints, and that is how you get incompatibilities.

I understand it is hard to get a decent taxonomy.

Having none means endpoints either miss alerts they wanted, or get alerts they don't, because there is no standard for alert taxonomy.

Brian