Re: [atoca] draft-ietf-atoca-requirements-02.txt, etc.

[Randall Gellens <[e-mail]>]

At 11:18 AM +0200 1/14/12, Hannes Tschofenig wrote:
>  Hi all,
>
>  I have just looked at the meeting minutes from the Taipei meeting 
> and noticed that Randy was the action item to review the 
> requirements/framework document.
>
>  Randy, when do you think can you take a look at it or do you want 
> to do that during a WGLC?

That was sent on November 17, immediately following the meeting (I 
figured it was best to send it out right away and avoid it getting 
buried under other work).


At 11:26 AM +0200 1/14/12, Hannes Tschofenig wrote:

>  Hi Randy,
>
>  I just found this mail. This may be your promised review. Is it?

Hi Hannes, yes, that's it.


>
>  On Nov 18, 2011, at 7:32 AM, Randall Gellens wrote:
>
>   > I've read though the draft, and I think it needs to clearly 
> identify the problems to be solved.  I'd suggest a new sub-section 
> ...
>  ...snip...
>>... and a new section before Terminology to define the problems to 
>> be solved, ideally with a small number of example use cases.
>
>  Do the use cases Brian sent to the list address your feedback?

They are a step towards it, but I think more work is needed.  I've 
sent some additional emails to the group.

>   > Also, the document should be higher-layer and not dive into CAP 
> and other lower-level details.
>
>  CAP is only mentioned twice in the document and that does not seem 
> to be too far fetched given that the charter says we are using it.

There are a number of reasons to use CAP (including the fact that 
CMAS uses it).  But, it's a fairly low level detail that needs to be 
built up to and justified based on the use cases and the requirements 
we need to meet the use cases.

>  However, I could soften the language a bit, such as
>
>  FROM:
>
>     Alert Delivery:
>
>        In this step the alert message is distributed to one or multiple
>        Receivers.  The Receiver as a software module that presents the
>        alert message to the Receipient.  The alert encoding is
>        accomplished via the Common Alerting Protocol (CAP) and such an
>        alert message contains useful information needed for dealing with
>        the imminent danger.
>
>  TO:
>
>     Alert Delivery:
>
>        In this step the alert message is distributed to one or multiple
>        Receivers.  The Receiver as a software module that presents the
>        alert message to the Receipient.  The alert encoding may be   
>        accomplished using Common Alerting Protocol (CAP). An
>        alert message contains useful information needed for dealing with
>        the imminent danger.
>
>
>  FROM:
>
>  With the usage of CAP these
>     alert message content requirements are delegated to the authors and
>     originators of alerts.
>
>  TO:
>
>     The requirements for the alert content are with the authors and the
>     originators of that alert rather than with the distribution system itself.

That's an improvement, but there still seems to be a lot missing, 
specifically, what are the problems we need to solve, and what 
requirements do we have in order to solve the problems?  Then, we can 
get into lower-level details, including the format of an alert.  We 
might justify CAP by a desire to interoperate with CMAS, for example, 
but if so we should be clear as to why we have it, and where it is 
needed (e.g., is it needed for all governmental levels or just 
national?)

>  Also, during the meeting someone said that I should replace LoST 
> with discovery.
>  That's fine in some sense but I don't want to be super abstract so 
> that nobody
>  understands the intentions anymore.
>
>   > Finally, I strongly recommend NOT using the term Message 
> Handling System (MHS) as this has specific meaning already.
>
>  What terminology do you suggest?

What about Alert Handling System?  The problem with MHS and Message 
Handling System is the long history of use with other, quite 
different systems.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Antonym: The opposite of the word you're trying to think of.