[earlywarning] Regarding your comments about requirements

[Hannes Tschofenig <[e-mail]>]

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.


    Req-G3:

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


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?


    Req-G5:

       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.


    Req-S2:

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

    Req-S3:

       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.

Ciao
Hannes