Re: [earlywarning] Regarding your comments about requirements

Thanks Hannes,

That all makes sense.

> -----Original Message-----
> From: earlywarning-bounces@ietf.org [mailto:earlywarning-
> bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, 20 July 2010 11:58 PM
> To: earlywarning@ietf.org
> Subject: [earlywarning] Regarding your comments about requirements
> 
> 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
> 
> 
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning