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

["Thomson, Martin" <[e-mail]>]

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.