Subject: Re: [Atoca] Language and Media Type
From: Likepeng <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 21 Jan 2011 01:54:16 +0000
List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." <earlywarning.ietf.org>

> ...
> Keeping Li (if the meeting minutes reflect his name correctly) noticed that we had a language requirement 
> in the requirements draft  but provided no corresponding solution in the SIP-CAP document.

It should be Kepeng Li.  ^_^

In my opinion, the indication of language preference is quite useful, especially for some areas with different languages.

Kind Regards
Kepeng Li

Date: Tue, 18 Jan 2011 16:55:21 -0600
To: Hannes Tschofenig <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt

At 11:48 AM 1/18/2011, Hannes Tschofenig wrote:
>Hey Keith,
>
>thanks for your comments! Please find my comments below:
>
>On 1/17/2011 7:50 PM, DRAGE, Keith (Keith) wrote:
>>I was scanning the charter to see if we had requirements for all 
>>items mentioned in the charter.
>>
>>For the following text:
>>
>>"Which devices should get alerts is primarily driven by location.
>>The first set of recipients that must be catered for are those
>>within the area identified by the alert originator to be affected
>>by the emergency event. "
>>
>>I could see the requiremnet for recipient control of this:
>>
>>     Req-S2:
>>
>>        The protocol solution MUST allow a potential Recipient to express
>>        the geographical area it wants to receive alerts about.
>>
>>But I could see no corresponding require for the sender to be able 
>>to indicate which geographic locations it wants its alerts to go to.
>
>Good catch.
>
>A question I have in return is whether this isn't implicitly covered 
>by the fact that the alert message itself may contain location 
>information about the relevant area.

I agree with Hannes here, as this may be a case of slight oversight 
of those of us a little too familiar with what CAP provides to not 
articular each requirement that we may have seen as implicit within CAP itself.

James

>For example, take a look at the following alert message:
>
>---------------------
>
>
>    <?xml version="1.0" encoding="UTF-8"?>
>
>    <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
>        <identifier>KSTO1055887203</identifier>
>        <sender>[email-masked]</sender>
>        <sent>2003-06-17T14:57:00-07:00</sent>
>        <status>Actual</status>
>        <msgType>Alert</msgType>
>        <scope>Public</scope>
>        <info>
>            <category>Met</category>
>            <event>SEVERE THUNDERSTORM</event>
>            <urgency>Severe</urgency>
>            <certainty>Likely</certainty>
>            <senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
>            <headline>SEVERE THUNDERSTORM WARNING</headline>
>            <description> AT 254 PM PDT...
>                NATIONAL WEATHER SERVICE
>                DOPPLER RADAR INDICATED A SEVERE
>                THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...
>                OR ABOUT 18 MILES SOUTHEAST OF
>                KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...
>                INTENSE RAIN AND STRONG DAMAGING WINDS
>                ARE LIKELY WITH THIS STORM </description>
>            <instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
>                UNTIL THE STORM PASSES </instruction>
>            <contact>BARUFFALDI/JUSKIE</contact>
>            <area>
>                <areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY
>                    IN CALIFORNIA, EXTREME NORTHEASTERN
>                    CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN
>                    ALPINE COUNTY IN CALIFORNIA </areaDesc>
>                <polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74
>                    38.62,-119.89 38.47,-120.14 </polygon>
>            </area>
>        </info>
>    </alert>
>
>-----------
>
>So, are you asking to have it stated explicitly that this 
>information has to be there or do you want to have the area 
>description additionally available in SIP itself.
>
>Both requests would be useful. The latter one is also relevant given 
>the discussions we had in ECRIT on the data-only emergency calls.
>
>>
>>I also looked at the following charter text:
>>
>>"The ATOCA effort is differentiated from and is not intended to
>>replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
>>recipients of ATOCA alerts are the wide range of devices connected to
>>the Internet and various private IP networks, which humans may have
>>"at hand" to get such events, as well as automatons who may take
>>action based on the alerts. This implies that the content of the
>>alert contains some information, which is intended to be consumed
>>by humans, and some which is intended to be consumed by automatons.
>>"
>>
>>I could see nothing in the i-d that even mentioned this, let alone 
>>discussed it.
>
>I think that is an important point we need to capture. We added text 
>to the architectural description but we have not captured this in 
>the requirements section and I believe it makes a bit difference 
>from an interoperability and security point of view whether there is 
>a human there that has to interpret the message or not.
>
>What about the following text in the requirements document:
>
>"
>       Req-D6:
>
>       The protocol solution MUST consider cases where alerts are 
> processed by Recipients (who are human) as well as cases where 
> there is no human present (i.e. the Recipient role coincides with 
> the Receiver role). An implication of the latter case is that the 
> Receiver, a software component, needs to make a decision about the 
> validity of the message (for example about the alert message 
> Author). Cases where no human is present can, for example, be found 
> with remote controlled vents, sirens or other warning systems in 
> commercial buildings.
>"
>
>
>
>  Rather the text:
>>
>>     "This problem has been illustrated by the London underground bombing
>>     on July 7, 2006, as described in a government report [July2005].  The
>>     UK authorities could only use broadcast media and could not, for
>>     example, easily announce to the "walking wounded" where to assemble."
>>
>>Could be be taken to imply that they intend to do exactly that, as 
>>I understand the UK initiative as a result of that was directed to 
>>mobile phone solutions, as identified above.
>Maybe Mark or Steve could comment on what the UK is currently 
>planning to do in this area.
>
>Ciao
>Hannes
>
>>
>>regards
>>
>>
>>Keith
>>
>>>-----Original Message-----
>>>From: [email-masked]
>>>[mailto:[email-masked]] On Behalf Of
>>>[email-masked]
>>>Sent: Saturday, January 15, 2011 7:00 PM
>>>To: [email-masked]
>>>Cc: [email-masked]
>>>Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt
>>>
>>>A New Internet-Draft is available from the on-line
>>>Internet-Drafts directories.
>>>This draft is a work item of the Authority-to-Citizen Alert
>>>Working Group of the IETF.
>>>
>>>
>>>         Title           : Requirements, Terminology and
>>>Framework for Exigent Communications
>>>         Author(s)       : H. Schulzrinne, et al.
>>>         Filename        : draft-ietf-atoca-requirements-01.txt
>>>         Pages           : 14
>>>         Date            : 2011-01-15
>>>
>>>Before, during and after emergency situations various
>>>agencies need to provide information to a group of persons or
>>>to the public within a geographical area.  While many aspects
>>>of such systems are specific to national or local
>>>jurisdictions, emergencies span such boundaries and
>>>notifications need to reach visitors from other jurisdictions.
>>>
>>>This document provides terminology, requirements and an
>>>architectural description for protocols exchanging alerts
>>>between IP-based end points.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme
>>>nts-01.txt
>>>
>>>Internet-Drafts are also available by anonymous FTP at:
>>>ftp://ftp.ietf.org/internet-drafts/
>>>
>>>Below is the data which will enable a MIME compliant mail
>>>reader implementation to automatically retrieve the ASCII
>>>version of the Internet-Draft.
>>_______________________________________________
>>earlywarning mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Tue, 18 Jan 2011 16:51:01 -0600
To: Brian Rosen <[email-masked]>, "<[email-masked]>" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Brian

Are you taking into account the difference in the packet size of the 
NOTIFY vs. the 200 OK? I believe any burst is the worry of the 
downstream capacity, and not the 200 OKs in the upstream.

That said, what events are we taking about accounting for?

- Local tornado/flooding alert? (affecting a creek or the eastern 
half of Australia?)
- metro amber alert? (backwoods sheriff's department or US Tri-state area?)
- hurricane alert? (Canary Islands or Katrina sized?)
- earthquake alert? (California dessert or Japan?)
- limited scale tsunami alert? (only Sumatra or the Indian Ocean?)
- ocean scale tsunami alert?

I think scoping - with examples - could serve some use in these 
discussions, and not just refer to them in the abstract.

Much of these will have vastly different scaling issues and design 
considerations - or will they?

We could go down the path of scaling regardless of the type of event 
that caused the alert. In other words, for a

    #1 - alerting <500 end-systems, do X

    #2 - alerting <10,000 end-systems, do Y

    #3 - alerting <500,000 end-systems, do Z

...all the way up to at least the ~140M that are in Japan because 
they have had events that would have alerted that many within the 
last 30 years.

Obviously, as the number of end-systems subscribe for a certain 
notification, the scale of the delivery system becomes more 
distributed to handle the load of the alerts and confirmations.  Our 
documents really ought to recommend ways to aggregate large scale 
confirmations too.

just a couple of thoughts

James

At 08:02 AM 1/18/2011, Brian Rosen wrote:
>I understand your concern.  As I stated, in really, really large 
>events, it may not be practical to get confirmation.  On the other 
>hand, when you have burst events that cause overload, we have 
>developed techniques for dealing with them.  This specific problem 
>is probably best addressed by a random backoff delay.  The devices, 
>upon receiving a broadcast wait a random time before attempting a 
>reply, and if they encounter busy conditions, increase the range of 
>the delay and delay another random time.
>
>Brian
>
>On Jan 18, 2011, at 6:49 AM, <[email-masked]> 
><[email-masked]> wrote:
>
> >
> > Thanks Brian,
> >
> > Brian's point is well made and correct, thanks Brian, but there are some
> > special issues that need to be borne in mind with some bearers.
> >
> > I first came into this project with the brief from the UN  to "protect the
> > (Mobile) mobile networks from catastrophic overload situations during
> > disasters".
> > When I "did the numbers" I discovered that the real problem is 
> not what many
> > think. The bottleneck is in the mobility management system
> > (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles
> > Kiriazakos  for the Greek government after the Athens earthquake and
> > subsequent crash of the Greek networks, confirmed this.  This is what lead
> > me to work on cell broadcast (which does not use the mobility management
> > system at all).
> >
> > I agree that it is reasonable to allow that the acknowledgments may indeed
> > take much longer to 'traffic' than the outbound multicast 
> message. Obviously
> > the scale is the same both ways, but while the latency is critical going
> > forward, the reverse path is not in the least bit time critical, so
> > relatively slower 'best effort'  bearers would be fine. The server which is
> > wishing to know its subscribers got a message may send the message both by
> > unicast and multicast (as mine do), but inevitably the acknowledgement will
> > have to be unicast. There is no specific problem in allowing the
> > acknowledgement of a multicast message by unicast means as long as we
> > understand that the latency is indeterminate. (However since it's not clear
> > when the ack may come, I send the message by both means simultaneously
> > without waiting for acks.)
> >
> > My concern is really for the Mobile Network, at layer 2.
> > For example if a large number of terminals all receive a multicast at the
> > same time, then they will all want to acknowledge at the same time. This
> > will result is a tsunami wave of random access bursts to the cells uplink
> > timeslot, MSC call set up load, 'channel allocation algorithm' threads and
> > SDCCH allocation attempts. Then there will be huge load on the 
> SMS gateways.
> > Mobiles that don't get an access grant message will obviously try again but
> > for a while the whole mobility management system will be significantly
> > loaded. This affects circuit switched voice just as much because the
> > mobility management system is common for voice and SMS, (but maybe not
> > GPRS?). Recall that in cellular network design, erlang 
> calculations are done
> > such that it's the assumption that only a small fraction of terminals will
> > make random access burst attempts at any one time, so the mobility
> > management system is designed for this load only.
> >
> > In other words, consider that a public warning message (such as a USA  CMAS
> > presidential message) will reach 100% of terminals simultaneously, rather
> > than the small percentage that the signaling system can cope with. This is
> > why both the CMAS and ETSI standards intentionally disallow 
> embedded numbers
> > or URLs for large scale (Public) warnings.
> >
> > So in fact the "scale" of the problem may not be as significant as the
> > impact on the local infrastructure (such as a cell). Maybe 
> "scale" is a less
> > important factor than, let's say, penetration?
> >
> > On the other hand a smaller scale (of penetration)  message would not have
> > such a profound impact. So in some cases it may be reasonable to expect
> > acknowledgements in 'best effort'  time. Norway, for example,  likes this
> > approach.
> >
> > I am unclear as to if IP systems have such problems because there is not a
> > 'stateful'  mobility management system in the core and though acks are on a
> > large scale, they represent very small packets of less than 1K each. Maybe
> > the problem will go away in the future? Any comments on that?
> >
> > Warm regards Mark Wood DRCF.
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Brian Rosen [mailto:[email-masked]]
> > Sent: Monday, January 17, 2011 2:44 PM
> > To: <[email-masked]>
> > Cc: [email-masked]
> > Subject: Re: [Atoca] Requirement D2: "Large Audience"
> >
> > It may be, but I'd like to explore this a bit anyway.
> >
> > Millions of messages (acknowledgements) is a scale we can deal with today.
> > Hundreds of millions is probably beyond what we can deal with in a response
> > to a very large alert.
> >
> > Most systems consist of several smaller subsystems.  The purpose of an
> > acknowledgement is to make sure everyone got the message.  If the subsystem
> > can determine that every one of its clients got it, it can report that up
> > the line.  It can save missed acks for later analysis, or if there are few
> > enough of them, report them up.
> >
> > This means messages national scale which have small effectivity times can't
> > reasonably ask for message acknowledgement.  Anything smaller than that
> > probably can.
> >
> > Since most alerts really don't involve hundreds of millions of
> > notifications, most alerts probably can ask for them.
> >
> > If your delivery mechanism is multicast, the multicast mechanism itself
> > doesn't track who gets the alert in any way we can use.  That implies
> > something else is tracking who gets the alert, a complication that could
> > loom large.  Some systems do know who gets the alert (sometimes because it
> > knows who it is connected to, and all of them get the alert).  Certainly,
> > anything with a subscription has the characteristic that the sender knows
> > who all the recipients are.
> >
> > It's VERY valuable to know that every entity that should get the alert got
> > it.  The only other mechanism we have is some repeating of the sending in
> > the hopes that everyone got it.  In some cases you may have more than one
> > "path" to the same recipient.  That might be multiple devices, multiple
> > services, or multiple logical or physical connections.  You may try one
> > first, and if that doesn't get an ack, try another.  Although we 
> often think
> > of this mechanism as needing no more than seconds to deploy, in fact many
> > alerts would be fine with a few minutes, and trying some things 
> sequentially
> > may make sense.
> >
> > So, yes, probably a Tsunami alert to all of East Asia can't ask for
> > acknowledgements.  An "Amber Alert" (possible abducted child) to a county
> > might very well.  Certainly, a snow emergency closing to the parents of an
> > elementary school could.
> >
> > Brian
> >
> >
> > _______________________________________________
> > earlywarning mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Tue, 18 Jan 2011 16:33:26 -0600
To: "Peter Sanders" <[email-masked]>, "'Brian Rosen'" <[email-masked]>, "[email-masked]@engineer.com'"@core3.amsl.com
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

At 10:04 AM 1/17/2011, Peter Sanders wrote:
>Hi Brian and Mark,
>
>Brian, you state in your email the following:
>"It's VERY valuable to know that every entity that should get the alert got
>it"
>
>The authorities may not know who in particular needs to receive the alert
>message. They wish that everyone in a specific area receives it. However,
>the authorities may have no idea who is in the target area at that moment,
>so they can't ask for confirmation; they can, but they don't know if they
>miss a few acks.

Peter

I believe that is true in push based alerting, but not in 
subscription based alerting. If SIP is used, and each end-system that 
wants to receive a certain alert SUBSCRIBEs to the alerting service, 
then the alerting service will NOTIFY the end-system that wanted to 
receive the alert, with a 200 OK as the return acknowledgement that 
the NOTIFY with the CAP message/container (or whatever is ultimately 
chosen to tell the receiver what's happening) would be the confirmation.

This is all predicated on the use of SIP for this discussion.

As Brian effectively points out, if there are many alerting servers 
alerting a subset of the subscribed end-systems, this scales far 
better, and I bet it doesn't need to be coalesced in real time for 
any reports. Further, the 200 OKs are far smaller in size than the 
alert message itself, so the traffic is far less in the upstream direction.

James

>Finding out who is in a specific area is technically possible, but may
>generate far more network traffic than the acks you expect from a few
>million people, and it takes time too.
>
>I just wanted to add these remarks to the discussion.
>
>Best regards,
>Peter
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Brian Rosen
>Sent: maandag 17 januari 2011 15:44
>To: [email-masked]@engineer.com
>Cc: [email-masked]
>Subject: Re: [Atoca] Requirement D2: "Large Audience"
>
>It may be, but I'd like to explore this a bit anyway.
>
>Millions of messages (acknowledgements) is a scale we can deal with today.
>Hundreds of millions is probably beyond what we can deal with in a response
>to a very large alert.
>
>Most systems consist of several smaller subsystems.  The purpose of an
>acknowledgement is to make sure everyone got the message.  If the subsystem
>can determine that every one of its clients got it, it can report that up
>the line.  It can save missed acks for later analysis, or if there are few
>enough of them, report them up.
>
>This means messages national scale which have small effectivity times can't
>reasonably ask for message acknowledgement.  Anything smaller than that
>probably can.
>
>Since most alerts really don't involve hundreds of millions of
>notifications, most alerts probably can ask for them.
>
>If your delivery mechanism is multicast, the multicast mechanism itself
>doesn't track who gets the alert in any way we can use.  That implies
>something else is tracking who gets the alert, a complication that could
>loom large.  Some systems do know who gets the alert (sometimes because it
>knows who it is connected to, and all of them get the alert).  Certainly,
>anything with a subscription has the characteristic that the sender knows
>who all the recipients are.
>
>It's VERY valuable to know that every entity that should get the alert got
>it.  The only other mechanism we have is some repeating of the sending in
>the hopes that everyone got it.  In some cases you may have more than one
>"path" to the same recipient.  That might be multiple devices, multiple
>services, or multiple logical or physical connections.  You may try one
>first, and if that doesn't get an ack, try another.  Although we often think
>of this mechanism as needing no more than seconds to deploy, in fact many
>alerts would be fine with a few minutes, and trying some things sequentially
>may make sense.
>
>So, yes, probably a Tsunami alert to all of East Asia can't ask for
>acknowledgements.  An "Amber Alert" (possible abducted child) to a county
>might very well.  Certainly, a snow emergency closing to the parents of an
>elementary school could.
>
>Brian
>
>
>On Jan 17, 2011, at 6:03 AM, <[email-masked]>
><[email-masked]> wrote:
>
> > Hello chaps,
> >
> > Yes, it's only possible to have any kind of delivery reports regarding
> > specific terminals on a one-to-one kind of unicast delivery. The
>Australians
> > were not considering Cell Broadcast or any other kind of multicast
> > technology as they have selected a SMS based delivery system, so this is
> > probably what they had in mind. I noticed that atoca language about this
>is
> > reserved mostly for the 'subscription push' kind of distribution.  We need
> > to take care not to make it look like a mandated requirement for
> > broadcast/multicast bearers.
> >
> > IMHO, the other special problems with multicast,  mean that it needs
> > different and special requirements and cannot be generalized with other
> > 'push' or 'pull'  technologies quite so easily, tempting though that is. I
> > think this problem happens because most IT professionals are familiar with
> > TCP and UDP but rarely use multicast so are unfamiliar with its very
> > different attributes.
> >
> > Many vendors offer systems which do have a positive indication of who got
> > what,  and this is a good thing for applications of up to about 10,000
> > receivers. Netherlands studies showed that by the time you scale up to
> > millions,  the mass scale of all this becomes a problem, so large scale
> > systems will have to reluctantly abandon the notion of  individual
> > confirmation.
> >
> > Besides, the police authority of a large city don't have the time, during
>an
> > emergency, to check out millions of replies nor take any action if someone
> > does not reply (they are too busy). On the other hand a smaller community
> > may value such a facility, so it seems that they authority will need to
> > choose whatever is appropriate for the circumstances at their discretion.
> > There is no 'one size fits all' solution so we will have to blend many
> > bearers in any real situation.  For example the Norwegians take the
>opposite
> > view.
> >
> > However, it is possible to confirm that the multicast was transmitted, as
>a
> > network of feedback receivers is envisaged in conjunction with an outer
>loop
> > reporter system, which would report of the message was transmitted on air.
> > If it did not, then an alarm would be generated by the originating
> > aggregator for the log file. So the positive indication of the fact of the
> > transmission over the air is satisfied even though individual delivery is
> > not.
> >
> > In summary, IMHO,  Broadcast/multicast bearers will need special treatment
> > as they don't neatly conform to the classic notions of 'push' or 'pull'.
> >
> > Warm regards, Mark  Wood.
> >
> >
> >
> >
> > _______________________________________________
> > earlywarning mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning
>
>_______________________________________________
>earlywarning mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/earlywarning

Date: Tue, 18 Jan 2011 19:48:30 +0200
From: Hannes Tschofenig <[email-masked]>
To: "DRAGE, Keith (Keith)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt

Hey Keith,

thanks for your comments! Please find my comments below:

On 1/17/2011 7:50 PM, DRAGE, Keith (Keith) wrote:
> I was scanning the charter to see if we had requirements for all items mentioned in the charter.
>
> For the following text:
>
> "Which devices should get alerts is primarily driven by location.
> The first set of recipients that must be catered for are those
> within the area identified by the alert originator to be affected
> by the emergency event. "
>
> I could see the requiremnet for recipient control of this:
>
>     Req-S2:
>
>        The protocol solution MUST allow a potential Recipient to express
>        the geographical area it wants to receive alerts about.
>
> But I could see no corresponding require for the sender to be able to indicate which geographic locations it wants its alerts to go to.

Good catch.

A question I have in return is whether this isn't implicitly covered by 
the fact that the alert message itself may contain location information 
about the relevant area.

For example, take a look at the following alert message:

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

    <?xml version="1.0" encoding="UTF-8"?>

    <alert xmlns="urn:oasis:names:tc:emergency:cap:1.1">
        <identifier>KSTO1055887203</identifier>
        <sender>[email-masked]</sender>
        <sent>2003-06-17T14:57:00-07:00</sent>
        <status>Actual</status>
        <msgType>Alert</msgType>
        <scope>Public</scope>
        <info>
            <category>Met</category>
            <event>SEVERE THUNDERSTORM</event>
            <urgency>Severe</urgency>
            <certainty>Likely</certainty>
            <senderName>NATIONAL WEATHER SERVICE SACRAMENTO</senderName>
            <headline>SEVERE THUNDERSTORM WARNING</headline>
            <description> AT 254 PM PDT...
                NATIONAL WEATHER SERVICE
                DOPPLER RADAR INDICATED A SEVERE
                THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY...
                OR ABOUT 18 MILES SOUTHEAST OF
                KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL...
                INTENSE RAIN AND STRONG DAMAGING WINDS
                ARE LIKELY WITH THIS STORM </description>
            <instruction> TAKE COVER IN A SUBSTANTIAL SHELTER
                UNTIL THE STORM PASSES </instruction>
            <contact>BARUFFALDI/JUSKIE</contact>
            <area>
                <areaDesc> EXTREME NORTH CENTRAL TUOLUMNE COUNTY
                    IN CALIFORNIA, EXTREME NORTHEASTERN
                    CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN
                    ALPINE COUNTY IN CALIFORNIA </areaDesc>
                <polygon> 38.47,-120.14 38.34,-119.95 38.52,-119.74
                    38.62,-119.89 38.47,-120.14 </polygon>
            </area>
        </info>
    </alert>

-----------

So, are you asking to have it stated explicitly that this information 
has to be there or do you want to have the area description additionally 
available in SIP itself.

Both requests would be useful. The latter one is also relevant given the 
discussions we had in ECRIT on the data-only emergency calls.

>
> I also looked at the following charter text:
>
> "The ATOCA effort is differentiated from and is not intended to
> replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
> recipients of ATOCA alerts are the wide range of devices connected to
> the Internet and various private IP networks, which humans may have
> "at hand" to get such events, as well as automatons who may take
> action based on the alerts. This implies that the content of the
> alert contains some information, which is intended to be consumed
> by humans, and some which is intended to be consumed by automatons.
> "
>
> I could see nothing in the i-d that even mentioned this, let alone discussed it.

I think that is an important point we need to capture. We added text to 
the architectural description but we have not captured this in the 
requirements section and I believe it makes a bit difference from an 
interoperability and security point of view whether there is a human 
there that has to interpret the message or not.

What about the following text in the requirements document:

"
       Req-D6:

       The protocol solution MUST consider cases where alerts are 
processed by Recipients (who are human) as well as cases where there is 
no human present (i.e. the Recipient role coincides with the Receiver 
role). An implication of the latter case is that the Receiver, a 
software component, needs to make a decision about the validity of the 
message (for example about the alert message Author). Cases where no 
human is present can, for example, be found with remote controlled 
vents, sirens or other warning systems in commercial buildings.
"

  Rather the text:
>
>     "This problem has been illustrated by the London underground bombing
>     on July 7, 2006, as described in a government report [July2005].  The
>     UK authorities could only use broadcast media and could not, for
>     example, easily announce to the "walking wounded" where to assemble."
>
> Could be be taken to imply that they intend to do exactly that, as I understand the UK initiative as a result of that was directed to mobile phone solutions, as identified above.
>
Maybe Mark or Steve could comment on what the UK is currently planning 
to do in this area.

Ciao
Hannes

>
> regards
>
>
> Keith
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Saturday, January 15, 2011 7:00 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Authority-to-Citizen Alert
>> Working Group of the IETF.
>>
>>
>> 	Title           : Requirements, Terminology and
>> Framework for Exigent Communications
>> 	Author(s)       : H. Schulzrinne, et al.
>> 	Filename        : draft-ietf-atoca-requirements-01.txt
>> 	Pages           : 14
>> 	Date            : 2011-01-15
>>
>> Before, during and after emergency situations various
>> agencies need to provide information to a group of persons or
>> to the public within a geographical area.  While many aspects
>> of such systems are specific to national or local
>> jurisdictions, emergencies span such boundaries and
>> notifications need to reach visitors from other jurisdictions.
>>
>> This document provides terminology, requirements and an
>> architectural description for protocols exchanging alerts
>> between IP-based end points.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme
>> nts-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail
>> reader implementation to automatically retrieve the ASCII
>> version of the Internet-Draft.
>>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>

From: Brian Rosen <[email-masked]>
Date: Tue, 18 Jan 2011 11:00:08 -0500
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

I certainly agree that ATOCA would not make use of SMS in any form of =
acknowledgement.   Similarly, I don't think we would use mobility =
management systems.

We would specify IP based mechanisms - exchanges of packets on the IP =
network.

Brian

On Jan 18, 2011, at 10:45 AM, DALY, BRIAN K (ATTCINW) wrote:

> Mark - you have described the logic behind the development of CMAS and =
what that is the alerting mechanism that will be used in the US on CMRS =
networks as defined under FCC rules. I was the Chair of the =
Communication Technology Group under the FCCs CMSAAC which developed =
CMASM Globally this is the Public Warning System as defined in 3GPP =
standards.
>=20
> SMS for any type of acknowledgment in a mass notification network will =
not work and will do more harm than good. This is wehy the FCC rules do =
not require acknowledgments.=20
> Brian K. Daly
>   Sent to you by AT&T...=20
>   America's Fastest Mobile Broadband
>       Network.  Rethink Possible.
>   +1.425.580.6873
> -------
> Sent from my Blackberry
>=20
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: [email-masked] <[email-masked]>
> Sent: Tue Jan 18 03:49:39 2011
> Subject: Re: [Atoca] Requirement D2: "Large Audience"
>=20
>=20
> Thanks Brian,
>=20
> Brian's point is well made and correct, thanks Brian, but there are =
some
> special issues that need to be borne in mind with some bearers.
>=20
> I first came into this project with the brief from the UN  to "protect =
the
> (Mobile) mobile networks from catastrophic overload situations during
> disasters".=20
> When I "did the numbers" I discovered that the real problem is not =
what many
> think. The bottleneck is in the mobility management system
> (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles
> Kiriazakos  for the Greek government after the Athens earthquake and
> subsequent crash of the Greek networks, confirmed this.  This is what =
lead
> me to work on cell broadcast (which does not use the mobility =
management
> system at all).
>=20
> I agree that it is reasonable to allow that the acknowledgments may =
indeed
> take much longer to 'traffic' than the outbound multicast message. =
Obviously
> the scale is the same both ways, but while the latency is critical =
going
> forward, the reverse path is not in the least bit time critical, so
> relatively slower 'best effort'  bearers would be fine. The server =
which is
> wishing to know its subscribers got a message may send the message =
both by
> unicast and multicast (as mine do), but inevitably the acknowledgement =
will
> have to be unicast. There is no specific problem in allowing the
> acknowledgement of a multicast message by unicast means as long as we
> understand that the latency is indeterminate. (However since it's not =
clear
> when the ack may come, I send the message by both means simultaneously
> without waiting for acks.)=20
>=20
> My concern is really for the Mobile Network, at layer 2.=20
> For example if a large number of terminals all receive a multicast at =
the
> same time, then they will all want to acknowledge at the same time. =
This
> will result is a tsunami wave of random access bursts to the cells =
uplink
> timeslot, MSC call set up load, 'channel allocation algorithm' threads =
and
> SDCCH allocation attempts. Then there will be huge load on the SMS =
gateways.
> Mobiles that don't get an access grant message will obviously try =
again but
> for a while the whole mobility management system will be significantly
> loaded. This affects circuit switched voice just as much because the
> mobility management system is common for voice and SMS, (but maybe not
> GPRS?). Recall that in cellular network design, erlang calculations =
are done
> such that it's the assumption that only a small fraction of terminals =
will
> make random access burst attempts at any one time, so the mobility
> management system is designed for this load only.
>=20
> In other words, consider that a public warning message (such as a USA  =
CMAS
> presidential message) will reach 100% of terminals simultaneously, =
rather
> than the small percentage that the signaling system can cope with. =
This is
> why both the CMAS and ETSI standards intentionally disallow embedded =
numbers
> or URLs for large scale (Public) warnings.
>=20
> So in fact the "scale" of the problem may not be as significant as the
> impact on the local infrastructure (such as a cell). Maybe "scale" is =
a less
> important factor than, let's say, penetration? =20
>=20
> On the other hand a smaller scale (of penetration)  message would not =
have
> such a profound impact. So in some cases it may be reasonable to =
expect
> acknowledgements in 'best effort'  time. Norway, for example,  likes =
this
> approach.
>=20
> I am unclear as to if IP systems have such problems because there is =
not a
> 'stateful'  mobility management system in the core and though acks are =
on a
> large scale, they represent very small packets of less than 1K each. =
Maybe
> the problem will go away in the future? Any comments on that?
>=20
> Warm regards Mark Wood DRCF.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]=20
> Sent: Monday, January 17, 2011 2:44 PM
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Atoca] Requirement D2: "Large Audience"
>=20
> It may be, but I'd like to explore this a bit anyway.
>=20
> Millions of messages (acknowledgements) is a scale we can deal with =
today.
> Hundreds of millions is probably beyond what we can deal with in a =
response
> to a very large alert.
>=20
> Most systems consist of several smaller subsystems.  The purpose of an
> acknowledgement is to make sure everyone got the message.  If the =
subsystem
> can determine that every one of its clients got it, it can report that =
up
> the line.  It can save missed acks for later analysis, or if there are =
few
> enough of them, report them up.
>=20
> This means messages national scale which have small effectivity times =
can't
> reasonably ask for message acknowledgement.  Anything smaller than =
that
> probably can.
>=20
> Since most alerts really don't involve hundreds of millions of
> notifications, most alerts probably can ask for them.
>=20
> If your delivery mechanism is multicast, the multicast mechanism =
itself
> doesn't track who gets the alert in any way we can use.  That implies
> something else is tracking who gets the alert, a complication that =
could
> loom large.  Some systems do know who gets the alert (sometimes =
because it
> knows who it is connected to, and all of them get the alert).  =
Certainly,
> anything with a subscription has the characteristic that the sender =
knows
> who all the recipients are. =20
>=20
> It's VERY valuable to know that every entity that should get the alert =
got
> it.  The only other mechanism we have is some repeating of the sending =
in
> the hopes that everyone got it.  In some cases you may have more than =
one
> "path" to the same recipient.  That might be multiple devices, =
multiple
> services, or multiple logical or physical connections.  You may try =
one
> first, and if that doesn't get an ack, try another.  Although we often =
think
> of this mechanism as needing no more than seconds to deploy, in fact =
many
> alerts would be fine with a few minutes, and trying some things =
sequentially
> may make sense.
>=20
> So, yes, probably a Tsunami alert to all of East Asia can't ask for
> acknowledgements.  An "Amber Alert" (possible abducted child) to a =
county
> might very well.  Certainly, a snow emergency closing to the parents =
of an
> elementary school could.
>=20
> Brian
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Tue, 18 Jan 2011 07:45:09 -0800
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

From: Brian Rosen <[email-masked]>
Date: Tue, 18 Jan 2011 09:02:45 -0500
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

I understand your concern.  As I stated, in really, really large events, =
it may not be practical to get confirmation.  On the other hand, when =
you have burst events that cause overload, we have developed techniques =
for dealing with them.  This specific problem is probably best addressed =
by a random backoff delay.  The devices, upon receiving a broadcast wait =
a random time before attempting a reply, and if they encounter busy =
conditions, increase the range of the delay and delay another random =
time.

Brian

On Jan 18, 2011, at 6:49 AM, <[email-masked]> =
<[email-masked]> wrote:

>=20
> Thanks Brian,
>=20
> Brian's point is well made and correct, thanks Brian, but there are =
some
> special issues that need to be borne in mind with some bearers.
>=20
> I first came into this project with the brief from the UN  to "protect =
the
> (Mobile) mobile networks from catastrophic overload situations during
> disasters".=20
> When I "did the numbers" I discovered that the real problem is not =
what many
> think. The bottleneck is in the mobility management system
> (HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles
> Kiriazakos  for the Greek government after the Athens earthquake and
> subsequent crash of the Greek networks, confirmed this.  This is what =
lead
> me to work on cell broadcast (which does not use the mobility =
management
> system at all).
>=20
> I agree that it is reasonable to allow that the acknowledgments may =
indeed
> take much longer to 'traffic' than the outbound multicast message. =
Obviously
> the scale is the same both ways, but while the latency is critical =
going
> forward, the reverse path is not in the least bit time critical, so
> relatively slower 'best effort'  bearers would be fine. The server =
which is
> wishing to know its subscribers got a message may send the message =
both by
> unicast and multicast (as mine do), but inevitably the acknowledgement =
will
> have to be unicast. There is no specific problem in allowing the
> acknowledgement of a multicast message by unicast means as long as we
> understand that the latency is indeterminate. (However since it's not =
clear
> when the ack may come, I send the message by both means simultaneously
> without waiting for acks.)=20
>=20
> My concern is really for the Mobile Network, at layer 2.=20
> For example if a large number of terminals all receive a multicast at =
the
> same time, then they will all want to acknowledge at the same time. =
This
> will result is a tsunami wave of random access bursts to the cells =
uplink
> timeslot, MSC call set up load, 'channel allocation algorithm' threads =
and
> SDCCH allocation attempts. Then there will be huge load on the SMS =
gateways.
> Mobiles that don't get an access grant message will obviously try =
again but
> for a while the whole mobility management system will be significantly
> loaded. This affects circuit switched voice just as much because the
> mobility management system is common for voice and SMS, (but maybe not
> GPRS?). Recall that in cellular network design, erlang calculations =
are done
> such that it's the assumption that only a small fraction of terminals =
will
> make random access burst attempts at any one time, so the mobility
> management system is designed for this load only.
>=20
> In other words, consider that a public warning message (such as a USA  =
CMAS
> presidential message) will reach 100% of terminals simultaneously, =
rather
> than the small percentage that the signaling system can cope with. =
This is
> why both the CMAS and ETSI standards intentionally disallow embedded =
numbers
> or URLs for large scale (Public) warnings.
>=20
> So in fact the "scale" of the problem may not be as significant as the
> impact on the local infrastructure (such as a cell). Maybe "scale" is =
a less
> important factor than, let's say, penetration? =20
>=20
> On the other hand a smaller scale (of penetration)  message would not =
have
> such a profound impact. So in some cases it may be reasonable to =
expect
> acknowledgements in 'best effort'  time. Norway, for example,  likes =
this
> approach.
>=20
> I am unclear as to if IP systems have such problems because there is =
not a
> 'stateful'  mobility management system in the core and though acks are =
on a
> large scale, they represent very small packets of less than 1K each. =
Maybe
> the problem will go away in the future? Any comments on that?
>=20
> Warm regards Mark Wood DRCF.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]=20
> Sent: Monday, January 17, 2011 2:44 PM
> To: <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Atoca] Requirement D2: "Large Audience"
>=20
> It may be, but I'd like to explore this a bit anyway.
>=20
> Millions of messages (acknowledgements) is a scale we can deal with =
today.
> Hundreds of millions is probably beyond what we can deal with in a =
response
> to a very large alert.
>=20
> Most systems consist of several smaller subsystems.  The purpose of an
> acknowledgement is to make sure everyone got the message.  If the =
subsystem
> can determine that every one of its clients got it, it can report that =
up
> the line.  It can save missed acks for later analysis, or if there are =
few
> enough of them, report them up.
>=20
> This means messages national scale which have small effectivity times =
can't
> reasonably ask for message acknowledgement.  Anything smaller than =
that
> probably can.
>=20
> Since most alerts really don't involve hundreds of millions of
> notifications, most alerts probably can ask for them.
>=20
> If your delivery mechanism is multicast, the multicast mechanism =
itself
> doesn't track who gets the alert in any way we can use.  That implies
> something else is tracking who gets the alert, a complication that =
could
> loom large.  Some systems do know who gets the alert (sometimes =
because it
> knows who it is connected to, and all of them get the alert).  =
Certainly,
> anything with a subscription has the characteristic that the sender =
knows
> who all the recipients are. =20
>=20
> It's VERY valuable to know that every entity that should get the alert =
got
> it.  The only other mechanism we have is some repeating of the sending =
in
> the hopes that everyone got it.  In some cases you may have more than =
one
> "path" to the same recipient.  That might be multiple devices, =
multiple
> services, or multiple logical or physical connections.  You may try =
one
> first, and if that doesn't get an ack, try another.  Although we often =
think
> of this mechanism as needing no more than seconds to deploy, in fact =
many
> alerts would be fine with a few minutes, and trying some things =
sequentially
> may make sense.
>=20
> So, yes, probably a Tsunami alert to all of East Asia can't ask for
> acknowledgements.  An "Amber Alert" (possible abducted child) to a =
county
> might very well.  Certainly, a snow emergency closing to the parents =
of an
> elementary school could.
>=20
> Brian
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 18 Jan 2011 13:52:42 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Surely if you supress the responses then it is no longer SIP, but some othe=
r entirely new protocol.

regards

Keith=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Sent: Sunday, January 16, 2011 11:15 PM
> To: Hannes Tschofenig; Art Botterell
> Cc: Faynberg, Igor (Igor); [email-masked]
> Subject: Re: [Atoca] Requirement D2: "Large Audience"
>=20
> On Jan 15, 2011, at 11:58 PM, Art Botterell wrote:
> > One difference in "broadcast" delivery is that it's frequntly=20
> > impractical and/or undesirable to try to track individual=20
> deliveries=20
> > or process individual responses.
>=20
> If SIP is our delivery mechanism, can anything be done to=20
> suppress 200 responses to NOTIFY requests?  Is there any=20
> point if we're using acknowledged transport like TCP?  Is=20
> there a concern that unacknowledged packets (UDP) will get dropped?
>=20
> The potential to create congestion worries me.
>=20
> --Martin
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> =

From: <[email-masked]>
Sender: "mark.wood" <[email-masked]>
To: <[email-masked]>
Date: Tue, 18 Jan 2011 11:49:39 -0000
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Thanks Brian,

Brian's point is well made and correct, thanks Brian, but there are some
special issues that need to be borne in mind with some bearers.

I first came into this project with the brief from the UN  to "protect the
(Mobile) mobile networks from catastrophic overload situations during
disasters". 
When I "did the numbers" I discovered that the real problem is not what many
think. The bottleneck is in the mobility management system
(HLR/VLR/Paging/Access grant). EU sponsored Studies by Prof Sophocles
Kiriazakos  for the Greek government after the Athens earthquake and
subsequent crash of the Greek networks, confirmed this.  This is what lead
me to work on cell broadcast (which does not use the mobility management
system at all).

I agree that it is reasonable to allow that the acknowledgments may indeed
take much longer to 'traffic' than the outbound multicast message. Obviously
the scale is the same both ways, but while the latency is critical going
forward, the reverse path is not in the least bit time critical, so
relatively slower 'best effort'  bearers would be fine. The server which is
wishing to know its subscribers got a message may send the message both by
unicast and multicast (as mine do), but inevitably the acknowledgement will
have to be unicast. There is no specific problem in allowing the
acknowledgement of a multicast message by unicast means as long as we
understand that the latency is indeterminate. (However since it's not clear
when the ack may come, I send the message by both means simultaneously
without waiting for acks.) 

My concern is really for the Mobile Network, at layer 2. 
For example if a large number of terminals all receive a multicast at the
same time, then they will all want to acknowledge at the same time. This
will result is a tsunami wave of random access bursts to the cells uplink
timeslot, MSC call set up load, 'channel allocation algorithm' threads and
SDCCH allocation attempts. Then there will be huge load on the SMS gateways.
Mobiles that don't get an access grant message will obviously try again but
for a while the whole mobility management system will be significantly
loaded. This affects circuit switched voice just as much because the
mobility management system is common for voice and SMS, (but maybe not
GPRS?). Recall that in cellular network design, erlang calculations are done
such that it's the assumption that only a small fraction of terminals will
make random access burst attempts at any one time, so the mobility
management system is designed for this load only.

In other words, consider that a public warning message (such as a USA  CMAS
presidential message) will reach 100% of terminals simultaneously, rather
than the small percentage that the signaling system can cope with. This is
why both the CMAS and ETSI standards intentionally disallow embedded numbers
or URLs for large scale (Public) warnings.

So in fact the "scale" of the problem may not be as significant as the
impact on the local infrastructure (such as a cell). Maybe "scale" is a less
important factor than, let's say, penetration?  

On the other hand a smaller scale (of penetration)  message would not have
such a profound impact. So in some cases it may be reasonable to expect
acknowledgements in 'best effort'  time. Norway, for example,  likes this
approach.

I am unclear as to if IP systems have such problems because there is not a
'stateful'  mobility management system in the core and though acks are on a
large scale, they represent very small packets of less than 1K each. Maybe
the problem will go away in the future? Any comments on that?

Warm regards Mark Wood DRCF.

 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 2:44 PM
To: <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

It may be, but I'd like to explore this a bit anyway.

Millions of messages (acknowledgements) is a scale we can deal with today.
Hundreds of millions is probably beyond what we can deal with in a response
to a very large alert.

Most systems consist of several smaller subsystems.  The purpose of an
acknowledgement is to make sure everyone got the message.  If the subsystem
can determine that every one of its clients got it, it can report that up
the line.  It can save missed acks for later analysis, or if there are few
enough of them, report them up.

This means messages national scale which have small effectivity times can't
reasonably ask for message acknowledgement.  Anything smaller than that
probably can.

Since most alerts really don't involve hundreds of millions of
notifications, most alerts probably can ask for them.

If your delivery mechanism is multicast, the multicast mechanism itself
doesn't track who gets the alert in any way we can use.  That implies
something else is tracking who gets the alert, a complication that could
loom large.  Some systems do know who gets the alert (sometimes because it
knows who it is connected to, and all of them get the alert).  Certainly,
anything with a subscription has the characteristic that the sender knows
who all the recipients are.  

It's VERY valuable to know that every entity that should get the alert got
it.  The only other mechanism we have is some repeating of the sending in
the hopes that everyone got it.  In some cases you may have more than one
"path" to the same recipient.  That might be multiple devices, multiple
services, or multiple logical or physical connections.  You may try one
first, and if that doesn't get an ack, try another.  Although we often think
of this mechanism as needing no more than seconds to deploy, in fact many
alerts would be fine with a few minutes, and trying some things sequentially
may make sense.

So, yes, probably a Tsunami alert to all of East Asia can't ask for
acknowledgements.  An "Amber Alert" (possible abducted child) to a county
might very well.  Certainly, a snow emergency closing to the parents of an
elementary school could.

Brian

Date: Mon, 17 Jan 2011 20:09:05 -0500
From: Igor Faynberg <[email-masked]>
Organization: Alcatel-Lucent
To: [email-masked]
Subject: [Atoca] On broadcasting and authentication/authorization (was Re: Requirement D2: "Large Audience")
Reply-To: [email-masked]

With many thanks to Hannes for a thorough follow-up on my humble 
questions, I just wanted to clarify that my question about "large 
audience" arose only because I was trained to test, and the word "large" 
is not something that any test can verify. Since the requirements has a 
MUST in it, it ought to be verifiable. (And I remember Scott echoed this 
by pointing to the word "simultaneously" as potentially problematic, too.

To this end, I am happy with the proposal to  use the term "broadcast."  
How about re-writing Req-D2 as follows:  

>
>       The protocol solution MUST allow broadcast delivery of messages
>        to the targeted audience.
>
>   
In this case, we avoid specification of the size of the audience as well 
as the issues of verifying simultaneity (broadcast takes care of  it).

On the issue of authentication/authorization, I actually meant exactly 
what Brian had said a while ago: The broadcaster has to be authenticated 
(lest a rogue entity creates panic or disrupts the network or both), and 
the network will deal with the authorization.  Indeed, TLS with client 
authentication (preferably, PKI-based) is a solution that I think perfect.

Igor

From: "Thomson, Martin" <[email-masked]>
To: Brian Rosen <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 18 Jan 2011 07:38:21 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2011 18:50:20 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt

I was scanning the charter to see if we had requirements for all items ment=
ioned in the charter.

For the following text:

"Which devices should get alerts is primarily driven by location.
The first set of recipients that must be catered for are those
within the area identified by the alert originator to be affected
by the emergency event. "=20

I could see the requiremnet for recipient control of this:

   Req-S2:

      The protocol solution MUST allow a potential Recipient to express
      the geographical area it wants to receive alerts about.

But I could see no corresponding require for the sender to be able to indic=
ate which geographic locations it wants its alerts to go to.

I also looked at the following charter text:

"The ATOCA effort is differentiated from and is not intended to
replace other alerting mechanisms (e.g., PWS, CMAS, ETWS), as the
recipients of ATOCA alerts are the wide range of devices connected to
the Internet and various private IP networks, which humans may have
"at hand" to get such events, as well as automatons who may take
action based on the alerts. This implies that the content of the
alert contains some information, which is intended to be consumed
by humans, and some which is intended to be consumed by automatons.
"

I could see nothing in the i-d that even mentioned this, let alone discusse=
d it. Rather the text:

   "This problem has been illustrated by the London underground bombing
   on July 7, 2006, as described in a government report [July2005].  The
   UK authorities could only use broadcast media and could not, for
   example, easily announce to the "walking wounded" where to assemble."

Could be be taken to imply that they intend to do exactly that, as I unders=
tand the UK initiative as a result of that was directed to mobile phone sol=
utions, as identified above.

regards

Keith

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Saturday, January 15, 2011 7:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt
>=20
> A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> This draft is a work item of the Authority-to-Citizen Alert=20
> Working Group of the IETF.
>=20
>=20
> 	Title           : Requirements, Terminology and=20
> Framework for Exigent Communications
> 	Author(s)       : H. Schulzrinne, et al.
> 	Filename        : draft-ietf-atoca-requirements-01.txt
> 	Pages           : 14
> 	Date            : 2011-01-15
>=20
> Before, during and after emergency situations various=20
> agencies need to provide information to a group of persons or=20
> to the public within a geographical area.  While many aspects=20
> of such systems are specific to national or local=20
> jurisdictions, emergencies span such boundaries and=20
> notifications need to reach visitors from other jurisdictions.
>=20
> This document provides terminology, requirements and an=20
> architectural description for protocols exchanging alerts=20
> between IP-based end points.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-atoca-requireme
> nts-01.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail=20
> reader implementation to automatically retrieve the ASCII=20
> version of the Internet-Draft.
> =

From: <[email-masked]>
Sender: "mark.wood" <[email-masked]>
To: <[email-masked]>
Date: Mon, 17 Jan 2011 17:30:25 -0000
Subject: [Atoca] FW:  Requirement D2: "Large Audience"

Yes, I stand corrected, Thanks Richard.

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]]
Sent: Monday, January 17, 2011 3:41 PM
To: Brian Rosen
Cc: <[email-masked]>; [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Just one brief comment: Mark's statement that "it's only possible to have
any kind of delivery reports regarding specific terminals on a one-to-one
kind of unicast delivery" is not necessarily true.  The availability of
delivery reports depends entirely on the capabilities of the terminals, and
not the intervening access network.  In particular, terminals can send back
delivery reports regardless of whether they are sending or receiving over
broadcast or unicast.   

This pattern could actually be quite efficient in certain layer-2 networks
that have broadcast downstream, unicast upstream (e.g., PON, DSL, maybe
Cable IIRC).  A notification to an entire subnet takes one message, and all
acknowledgements can be received in parallel.

--Richard

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 17 Jan 2011 11:21:18 -0500
To: Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement for Originator Authentication?

Note that you don't necessarily need S/MIME implementation in the SIP =
stack.  You can do it at the application layer -- pull the bits out of =
the SIP body and do your thing.  At that level, there are lots of S/MIME =
libraries, all the typical ones: OpenSSL, BouncyCastle, MS CAPI/CNG.

No doubt that hop-by-hop works, but it doesn't provide the guarantees =
that end-to-end or end-to-middle does.  There's room for both.

--Richard

On Jan 17, 2011, at 10:33 AM, Brian Rosen wrote:

> Interesting.
>=20
> Our experience is that it's hard to get S/MIME implementations, but =
maybe we could do it for this one.
>=20
> In nearly every case, we don't want encryption.  We want =
authentication and probably integrity protection.  So implementing =
S/MIME gets you that, but you can ignore it if you want to.  Might work.
>=20
> I do think hop by hop works also.
>=20
> Brian
>=20
> On Jan 17, 2011, at 10:25 AM, Richard L. Barnes wrote:
>=20
>> To say this differently: The authentication and authorization applied =
in a given deployed system is decided by the entities operating that =
deployment.  The ATOCA framework should allow for strong authentication =
and authorization, and provide appropriate mechanisms, but not require =
any particular mechanism to be used.
>>=20
>> With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop =
authentication/authorization is critical -- especially on the first hop, =
where the message is introduced.  But it's also trivial: Just use TLS =
with client authentication. =20
>>=20
>> End-to-end is nice to have, but much harder in any sort of global =
context because of the problems with establishing trust anchors.  (Does =
my phone have to have a TA for every emergency authority in the world?)  =
In this case, I think the optimal solution might be more of an =
"end-to-middle" solution.  The originators and relays are part of a =
semi-closed system, at least to the degree that you could expect them to =
coordinate on trust anchors.  So you could enable every entity down to =
the last gateway to validate the authorization for a message, even if =
the client can't.
>>=20
>> That said, I think the required technology is probably the same as =
for true end-to-end.  The obvious answer, IMO, is simply to pass CAP in =
S/MIME.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>> On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote:
>>=20
>>> Authorization to initiate alerts  should be provided by the entity =
that is initiating the alerts and not ATOCA. ATOCA should authenticate =
the receipt of the alerts is from a trusted source.
>>> Brian K. Daly
>>> Sent to you by AT&T...=20
>>> America's Fastest Mobile Broadband
>>>     Network.  Rethink Possible.
>>> +1.425.580.6873
>>> -------
>>> Sent from my Blackberry
>>>=20
>>> ----- Original Message -----
>>> From: [email-masked] <[email-masked]>
>>> To: Hannes Tschofenig <[email-masked]>; =
[email-masked] <[email-masked]>; Igor Faynberg =
<[email-masked]>
>>> Sent: Sun Jan 16 15:32:09 2011
>>> Subject: Re: [Atoca] Requirement for Originator Authentication?
>>>=20
>>> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote:
>>>> Igor raised an interesting question during the meeting in context =
of
>>>> the security threats, namely:
>>>>=20
>>>> " Do we have the requirement to authenticate the originator? "
>>>=20
>>> The question that I heard was not so much related to authentication =
as it was to authorization.  There was also a question about whether =
authentication was identity-based or on some other property, like some =
asserted trait.
>>>=20
>>> What statements can we make about how recipients (and relays) =
authorize the receipt (and sending) of alert messages?
>>>=20
>>>> I couldn't provide him an answer during the meeting because I was =
not
>>>> quite sure whether he was asking the question in the style of
>>>>=20
>>>> "Do we need end-to-end security or is a hop-by-hop security =
solution
>>>> good enough?"
>>>=20
>>> In the context of this interpretation, I think that there's a real =
need to delegate alert distribution.  The scale of distribution makes =
intermediaries a valuable addition.  Relying on the integrity of relays =
makes the authorization question more difficult to resolve.
>>>=20
>>> For something concrete, the relay case is probably the simplest.  I =
might trust my signalling peer to a certain extent.  I certainly don't =
trust them enough to generate the massive packet storm requested by an =
alert message.  They might say the alert comes from the government, but =
I might require better proof than their say-so alone.  Distributing an =
alert will cost me money and I want proof.
>>>=20
>>> That's one argument.  The other argument says that peering =
relationships require a degree of trust that would not be broken without =
serious ramifications - enough to discourage its abuse.
>>>=20
>>> The recipient case might have some interesting quirks.  Particularly =
in wholesale/reseller arrangements.  A recipient that relies on =
hop-by-hop might receive an alert from the network operator: an entity =
with whom they have no direct relationship.  For instance, no fewer than =
two different operators are involved in getting packets to my house, =
neither of which I have a business relationship with.  How would someone =
- ignorant of the convoluted business arrangements that underpin their =
Internet service - decide to authorize an alert that is relayed by =
either party?
>>>=20
>>> --Martin
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>=20

From: "mark.wood" <[email-masked]>
To: <[email-masked]>
Date: Mon, 17 Jan 2011 16:13:13 -0000
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Yes, I stand corrected, Thanks Richard.

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Monday, January 17, 2011 3:41 PM
To: Brian Rosen
Cc: <[email-masked]>; [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Just one brief comment: Mark's statement that "it's only possible to have
any kind of delivery reports regarding specific terminals on a one-to-one
kind of unicast delivery" is not necessarily true.  The availability of
delivery reports depends entirely on the capabilities of the terminals, and
not the intervening access network.  In particular, terminals can send back
delivery reports regardless of whether they are sending or receiving over
broadcast or unicast.   

This pattern could actually be quite efficient in certain layer-2 networks
that have broadcast downstream, unicast upstream (e.g., PON, DSL, maybe
Cable IIRC).  A notification to an entire subnet takes one message, and all
acknowledgements can be received in parallel.

--Richard

On Jan 17, 2011, at 9:44 AM, Brian Rosen wrote:

> It may be, but I'd like to explore this a bit anyway.
> 
> Millions of messages (acknowledgements) is a scale we can deal with today.
Hundreds of millions is probably beyond what we can deal with in a response
to a very large alert.
> 
> Most systems consist of several smaller subsystems.  The purpose of an
acknowledgement is to make sure everyone got the message.  If the subsystem
can determine that every one of its clients got it, it can report that up
the line.  It can save missed acks for later analysis, or if there are few
enough of them, report them up.
> 
> This means messages national scale which have small effectivity times
can't reasonably ask for message acknowledgement.  Anything smaller than
that probably can.
> 
> Since most alerts really don't involve hundreds of millions of
notifications, most alerts probably can ask for them.
> 
> If your delivery mechanism is multicast, the multicast mechanism itself
doesn't track who gets the alert in any way we can use.  That implies
something else is tracking who gets the alert, a complication that could
loom large.  Some systems do know who gets the alert (sometimes because it
knows who it is connected to, and all of them get the alert).  Certainly,
anything with a subscription has the characteristic that the sender knows
who all the recipients are.  
> 
> It's VERY valuable to know that every entity that should get the alert got
it.  The only other mechanism we have is some repeating of the sending in
the hopes that everyone got it.  In some cases you may have more than one
"path" to the same recipient.  That might be multiple devices, multiple
services, or multiple logical or physical connections.  You may try one
first, and if that doesn't get an ack, try another.  Although we often think
of this mechanism as needing no more than seconds to deploy, in fact many
alerts would be fine with a few minutes, and trying some things sequentially
may make sense.
> 
> So, yes, probably a Tsunami alert to all of East Asia can't ask for
acknowledgements.  An "Amber Alert" (possible abducted child) to a county
might very well.  Certainly, a snow emergency closing to the parents of an
elementary school could.
> 
> Brian
> 
> 
> On Jan 17, 2011, at 6:03 AM, <[email-masked]>
<[email-masked]> wrote:
> 
>> Hello chaps,
>> 
>> Yes, it's only possible to have any kind of delivery reports 
>> regarding specific terminals on a one-to-one kind of unicast 
>> delivery. The Australians were not considering Cell Broadcast or any 
>> other kind of multicast technology as they have selected a SMS based 
>> delivery system, so this is probably what they had in mind. I noticed 
>> that atoca language about this is reserved mostly for the 
>> 'subscription push' kind of distribution.  We need to take care not 
>> to make it look like a mandated requirement for broadcast/multicast
bearers.
>> 
>> IMHO, the other special problems with multicast,  mean that it needs 
>> different and special requirements and cannot be generalized with 
>> other 'push' or 'pull'  technologies quite so easily, tempting though 
>> that is. I think this problem happens because most IT professionals 
>> are familiar with TCP and UDP but rarely use multicast so are 
>> unfamiliar with its very different attributes.
>> 
>> Many vendors offer systems which do have a positive indication of who 
>> got what,  and this is a good thing for applications of up to about 
>> 10,000 receivers. Netherlands studies showed that by the time you 
>> scale up to millions,  the mass scale of all this becomes a problem, 
>> so large scale systems will have to reluctantly abandon the notion of  
>> individual confirmation.
>> 
>> Besides, the police authority of a large city don't have the time, 
>> during an emergency, to check out millions of replies nor take any 
>> action if someone does not reply (they are too busy). On the other 
>> hand a smaller community may value such a facility, so it seems that 
>> they authority will need to choose whatever is appropriate for the
circumstances at their discretion.
>> There is no 'one size fits all' solution so we will have to blend 
>> many bearers in any real situation.  For example the Norwegians take 
>> the opposite view.
>> 
>> However, it is possible to confirm that the multicast was 
>> transmitted, as a network of feedback receivers is envisaged in 
>> conjunction with an outer loop reporter system, which would report of the
message was transmitted on air.
>> If it did not, then an alarm would be generated by the originating 
>> aggregator for the log file. So the positive indication of the fact 
>> of the transmission over the air is satisfied even though individual 
>> delivery is not.
>> 
>> In summary, IMHO,  Broadcast/multicast bearers will need special 
>> treatment as they don't neatly conform to the classic notions of 'push'
or 'pull'.
>> 
>> Warm regards, Mark  Wood.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Brian Rosen <[email-masked]>
Date: Mon, 17 Jan 2011 10:33:07 -0500
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Atoca] Requirement for Originator Authentication?

Interesting.

Our experience is that it's hard to get S/MIME implementations, but =
maybe we could do it for this one.

In nearly every case, we don't want encryption.  We want authentication =
and probably integrity protection.  So implementing S/MIME gets you =
that, but you can ignore it if you want to.  Might work.

I do think hop by hop works also.

Brian

On Jan 17, 2011, at 10:25 AM, Richard L. Barnes wrote:

> To say this differently: The authentication and authorization applied =
in a given deployed system is decided by the entities operating that =
deployment.  The ATOCA framework should allow for strong authentication =
and authorization, and provide appropriate mechanisms, but not require =
any particular mechanism to be used.
>=20
> With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop =
authentication/authorization is critical -- especially on the first hop, =
where the message is introduced.  But it's also trivial: Just use TLS =
with client authentication. =20
>=20
> End-to-end is nice to have, but much harder in any sort of global =
context because of the problems with establishing trust anchors.  (Does =
my phone have to have a TA for every emergency authority in the world?)  =
In this case, I think the optimal solution might be more of an =
"end-to-middle" solution.  The originators and relays are part of a =
semi-closed system, at least to the degree that you could expect them to =
coordinate on trust anchors.  So you could enable every entity down to =
the last gateway to validate the authorization for a message, even if =
the client can't.
>=20
> That said, I think the required technology is probably the same as for =
true end-to-end.  The obvious answer, IMO, is simply to pass CAP in =
S/MIME.
>=20
> --Richard
>=20
>=20
>=20
> On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote:
>=20
>> Authorization to initiate alerts  should be provided by the entity =
that is initiating the alerts and not ATOCA. ATOCA should authenticate =
the receipt of the alerts is from a trusted source.
>> Brian K. Daly
>>  Sent to you by AT&T...=20
>>  America's Fastest Mobile Broadband
>>      Network.  Rethink Possible.
>>  +1.425.580.6873
>> -------
>> Sent from my Blackberry
>>=20
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: Hannes Tschofenig <[email-masked]>; =
[email-masked] <[email-masked]>; Igor Faynberg =
<[email-masked]>
>> Sent: Sun Jan 16 15:32:09 2011
>> Subject: Re: [Atoca] Requirement for Originator Authentication?
>>=20
>> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote:
>>> Igor raised an interesting question during the meeting in context of
>>> the security threats, namely:
>>>=20
>>> " Do we have the requirement to authenticate the originator? "
>>=20
>> The question that I heard was not so much related to authentication =
as it was to authorization.  There was also a question about whether =
authentication was identity-based or on some other property, like some =
asserted trait.
>>=20
>> What statements can we make about how recipients (and relays) =
authorize the receipt (and sending) of alert messages?
>>=20
>>> I couldn't provide him an answer during the meeting because I was =
not
>>> quite sure whether he was asking the question in the style of
>>>=20
>>> "Do we need end-to-end security or is a hop-by-hop security solution
>>> good enough?"
>>=20
>> In the context of this interpretation, I think that there's a real =
need to delegate alert distribution.  The scale of distribution makes =
intermediaries a valuable addition.  Relying on the integrity of relays =
makes the authorization question more difficult to resolve.
>>=20
>> For something concrete, the relay case is probably the simplest.  I =
might trust my signalling peer to a certain extent.  I certainly don't =
trust them enough to generate the massive packet storm requested by an =
alert message.  They might say the alert comes from the government, but =
I might require better proof than their say-so alone.  Distributing an =
alert will cost me money and I want proof.
>>=20
>> That's one argument.  The other argument says that peering =
relationships require a degree of trust that would not be broken without =
serious ramifications - enough to discourage its abuse.
>>=20
>> The recipient case might have some interesting quirks.  Particularly =
in wholesale/reseller arrangements.  A recipient that relies on =
hop-by-hop might receive an alert from the network operator: an entity =
with whom they have no direct relationship.  For instance, no fewer than =
two different operators are involved in getting packets to my house, =
neither of which I have a business relationship with.  How would someone =
- ignorant of the convoluted business arrangements that underpin their =
Internet service - decide to authorize an alert that is relayed by =
either party?
>>=20
>> --Martin
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Peter Sanders" <[email-masked]>
To: "'Brian Rosen'" <[email-masked]>, "[email-masked]@engineer.com'"@core3.amsl.com
Date: Mon, 17 Jan 2011 17:04:28 +0100
Organization: one2many
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Hi Brian and Mark,

Brian, you state in your email the following:
"It's VERY valuable to know that every entity that should get the alert got
it"

The authorities may not know who in particular needs to receive the alert
message. They wish that everyone in a specific area receives it. However,
the authorities may have no idea who is in the target area at that moment,
so they can't ask for confirmation; they can, but they don't know if they
miss a few acks.

Finding out who is in a specific area is technically possible, but may
generate far more network traffic than the acks you expect from a few
million people, and it takes time too. 

I just wanted to add these remarks to the discussion.

Best regards,
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Brian Rosen
Sent: maandag 17 januari 2011 15:44
To: [email-masked]@engineer.com
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

It may be, but I'd like to explore this a bit anyway.

Millions of messages (acknowledgements) is a scale we can deal with today.
Hundreds of millions is probably beyond what we can deal with in a response
to a very large alert.

Most systems consist of several smaller subsystems.  The purpose of an
acknowledgement is to make sure everyone got the message.  If the subsystem
can determine that every one of its clients got it, it can report that up
the line.  It can save missed acks for later analysis, or if there are few
enough of them, report them up.

This means messages national scale which have small effectivity times can't
reasonably ask for message acknowledgement.  Anything smaller than that
probably can.

Since most alerts really don't involve hundreds of millions of
notifications, most alerts probably can ask for them.

If your delivery mechanism is multicast, the multicast mechanism itself
doesn't track who gets the alert in any way we can use.  That implies
something else is tracking who gets the alert, a complication that could
loom large.  Some systems do know who gets the alert (sometimes because it
knows who it is connected to, and all of them get the alert).  Certainly,
anything with a subscription has the characteristic that the sender knows
who all the recipients are.  

It's VERY valuable to know that every entity that should get the alert got
it.  The only other mechanism we have is some repeating of the sending in
the hopes that everyone got it.  In some cases you may have more than one
"path" to the same recipient.  That might be multiple devices, multiple
services, or multiple logical or physical connections.  You may try one
first, and if that doesn't get an ack, try another.  Although we often think
of this mechanism as needing no more than seconds to deploy, in fact many
alerts would be fine with a few minutes, and trying some things sequentially
may make sense.

So, yes, probably a Tsunami alert to all of East Asia can't ask for
acknowledgements.  An "Amber Alert" (possible abducted child) to a county
might very well.  Certainly, a snow emergency closing to the parents of an
elementary school could.

Brian

On Jan 17, 2011, at 6:03 AM, <[email-masked]>
<[email-masked]> wrote:

> Hello chaps,
> 
> Yes, it's only possible to have any kind of delivery reports regarding
> specific terminals on a one-to-one kind of unicast delivery. The
Australians
> were not considering Cell Broadcast or any other kind of multicast
> technology as they have selected a SMS based delivery system, so this is
> probably what they had in mind. I noticed that atoca language about this
is
> reserved mostly for the 'subscription push' kind of distribution.  We need
> to take care not to make it look like a mandated requirement for
> broadcast/multicast bearers. 
> 
> IMHO, the other special problems with multicast,  mean that it needs
> different and special requirements and cannot be generalized with other
> 'push' or 'pull'  technologies quite so easily, tempting though that is. I
> think this problem happens because most IT professionals are familiar with
> TCP and UDP but rarely use multicast so are unfamiliar with its very
> different attributes.
> 
> Many vendors offer systems which do have a positive indication of who got
> what,  and this is a good thing for applications of up to about 10,000
> receivers. Netherlands studies showed that by the time you scale up to
> millions,  the mass scale of all this becomes a problem, so large scale
> systems will have to reluctantly abandon the notion of  individual
> confirmation.
> 
> Besides, the police authority of a large city don't have the time, during
an
> emergency, to check out millions of replies nor take any action if someone
> does not reply (they are too busy). On the other hand a smaller community
> may value such a facility, so it seems that they authority will need to
> choose whatever is appropriate for the circumstances at their discretion.
> There is no 'one size fits all' solution so we will have to blend many
> bearers in any real situation.  For example the Norwegians take the
opposite
> view.
> 
> However, it is possible to confirm that the multicast was transmitted, as
a
> network of feedback receivers is envisaged in conjunction with an outer
loop
> reporter system, which would report of the message was transmitted on air.
> If it did not, then an alarm would be generated by the originating
> aggregator for the log file. So the positive indication of the fact of the
> transmission over the air is satisfied even though individual delivery is
> not. 
> 
> In summary, IMHO,  Broadcast/multicast bearers will need special treatment
> as they don't neatly conform to the classic notions of 'push' or 'pull'. 
> 
> Warm regards, Mark  Wood.
> 
> 
> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

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

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 17 Jan 2011 10:41:25 -0500
To: Brian Rosen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Just one brief comment: Mark's statement that "it's only possible to =
have any kind of delivery reports regarding specific terminals on a =
one-to-one kind of unicast delivery" is not necessarily true.  The =
availability of delivery reports depends entirely on the capabilities of =
the terminals, and not the intervening access network.  In particular, =
terminals can send back delivery reports regardless of whether they are =
sending or receiving over broadcast or unicast.  =20

This pattern could actually be quite efficient in certain layer-2 =
networks that have broadcast downstream, unicast upstream (e.g., PON, =
DSL, maybe Cable IIRC).  A notification to an entire subnet takes one =
message, and all acknowledgements can be received in parallel.

--Richard

On Jan 17, 2011, at 9:44 AM, Brian Rosen wrote:

> It may be, but I'd like to explore this a bit anyway.
>=20
> Millions of messages (acknowledgements) is a scale we can deal with =
today.  Hundreds of millions is probably beyond what we can deal with in =
a response to a very large alert.
>=20
> Most systems consist of several smaller subsystems.  The purpose of an =
acknowledgement is to make sure everyone got the message.  If the =
subsystem can determine that every one of its clients got it, it can =
report that up the line.  It can save missed acks for later analysis, or =
if there are few enough of them, report them up.
>=20
> This means messages national scale which have small effectivity times =
can't reasonably ask for message acknowledgement.  Anything smaller than =
that probably can.
>=20
> Since most alerts really don't involve hundreds of millions of =
notifications, most alerts probably can ask for them.
>=20
> If your delivery mechanism is multicast, the multicast mechanism =
itself doesn't track who gets the alert in any way we can use.  That =
implies something else is tracking who gets the alert, a complication =
that could loom large.  Some systems do know who gets the alert =
(sometimes because it knows who it is connected to, and all of them get =
the alert).  Certainly, anything with a subscription has the =
characteristic that the sender knows who all the recipients are. =20
>=20
> It's VERY valuable to know that every entity that should get the alert =
got it.  The only other mechanism we have is some repeating of the =
sending in the hopes that everyone got it.  In some cases you may have =
more than one "path" to the same recipient.  That might be multiple =
devices, multiple services, or multiple logical or physical connections. =
 You may try one first, and if that doesn't get an ack, try another.  =
Although we often think of this mechanism as needing no more than =
seconds to deploy, in fact many alerts would be fine with a few minutes, =
and trying some things sequentially may make sense.
>=20
> So, yes, probably a Tsunami alert to all of East Asia can't ask for =
acknowledgements.  An "Amber Alert" (possible abducted child) to a =
county might very well.  Certainly, a snow emergency closing to the =
parents of an elementary school could.
>=20
> Brian
>=20
>=20
> On Jan 17, 2011, at 6:03 AM, <[email-masked]> =
<[email-masked]> wrote:
>=20
>> Hello chaps,
>>=20
>> Yes, it's only possible to have any kind of delivery reports =
regarding
>> specific terminals on a one-to-one kind of unicast delivery. The =
Australians
>> were not considering Cell Broadcast or any other kind of multicast
>> technology as they have selected a SMS based delivery system, so this =
is
>> probably what they had in mind. I noticed that atoca language about =
this is
>> reserved mostly for the 'subscription push' kind of distribution.  We =
need
>> to take care not to make it look like a mandated requirement for
>> broadcast/multicast bearers.=20
>>=20
>> IMHO, the other special problems with multicast,  mean that it needs
>> different and special requirements and cannot be generalized with =
other
>> 'push' or 'pull'  technologies quite so easily, tempting though that =
is. I
>> think this problem happens because most IT professionals are familiar =
with
>> TCP and UDP but rarely use multicast so are unfamiliar with its very
>> different attributes.
>>=20
>> Many vendors offer systems which do have a positive indication of who =
got
>> what,  and this is a good thing for applications of up to about =
10,000
>> receivers. Netherlands studies showed that by the time you scale up =
to
>> millions,  the mass scale of all this becomes a problem, so large =
scale
>> systems will have to reluctantly abandon the notion of  individual
>> confirmation.
>>=20
>> Besides, the police authority of a large city don't have the time, =
during an
>> emergency, to check out millions of replies nor take any action if =
someone
>> does not reply (they are too busy). On the other hand a smaller =
community
>> may value such a facility, so it seems that they authority will need =
to
>> choose whatever is appropriate for the circumstances at their =
discretion.
>> There is no 'one size fits all' solution so we will have to blend =
many
>> bearers in any real situation.  For example the Norwegians take the =
opposite
>> view.
>>=20
>> However, it is possible to confirm that the multicast was =
transmitted, as a
>> network of feedback receivers is envisaged in conjunction with an =
outer loop
>> reporter system, which would report of the message was transmitted on =
air.
>> If it did not, then an alarm would be generated by the originating
>> aggregator for the log file. So the positive indication of the fact =
of the
>> transmission over the air is satisfied even though individual =
delivery is
>> not.=20
>>=20
>> In summary, IMHO,  Broadcast/multicast bearers will need special =
treatment
>> as they don't neatly conform to the classic notions of 'push' or =
'pull'.=20
>>=20
>> Warm regards, Mark  Wood.
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Brian Rosen <[email-masked]>
Date: Mon, 17 Jan 2011 09:44:02 -0500
To: <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

It may be, but I'd like to explore this a bit anyway.

Millions of messages (acknowledgements) is a scale we can deal with =
today.  Hundreds of millions is probably beyond what we can deal with in =
a response to a very large alert.

Most systems consist of several smaller subsystems.  The purpose of an =
acknowledgement is to make sure everyone got the message.  If the =
subsystem can determine that every one of its clients got it, it can =
report that up the line.  It can save missed acks for later analysis, or =
if there are few enough of them, report them up.

This means messages national scale which have small effectivity times =
can't reasonably ask for message acknowledgement.  Anything smaller than =
that probably can.

Since most alerts really don't involve hundreds of millions of =
notifications, most alerts probably can ask for them.

If your delivery mechanism is multicast, the multicast mechanism itself =
doesn't track who gets the alert in any way we can use.  That implies =
something else is tracking who gets the alert, a complication that could =
loom large.  Some systems do know who gets the alert (sometimes because =
it knows who it is connected to, and all of them get the alert).  =
Certainly, anything with a subscription has the characteristic that the =
sender knows who all the recipients are. =20

It's VERY valuable to know that every entity that should get the alert =
got it.  The only other mechanism we have is some repeating of the =
sending in the hopes that everyone got it.  In some cases you may have =
more than one "path" to the same recipient.  That might be multiple =
devices, multiple services, or multiple logical or physical connections. =
 You may try one first, and if that doesn't get an ack, try another.  =
Although we often think of this mechanism as needing no more than =
seconds to deploy, in fact many alerts would be fine with a few minutes, =
and trying some things sequentially may make sense.

So, yes, probably a Tsunami alert to all of East Asia can't ask for =
acknowledgements.  An "Amber Alert" (possible abducted child) to a =
county might very well.  Certainly, a snow emergency closing to the =
parents of an elementary school could.

Brian

On Jan 17, 2011, at 6:03 AM, <[email-masked]> =
<[email-masked]> wrote:

> Hello chaps,
>=20
> Yes, it's only possible to have any kind of delivery reports regarding
> specific terminals on a one-to-one kind of unicast delivery. The =
Australians
> were not considering Cell Broadcast or any other kind of multicast
> technology as they have selected a SMS based delivery system, so this =
is
> probably what they had in mind. I noticed that atoca language about =
this is
> reserved mostly for the 'subscription push' kind of distribution.  We =
need
> to take care not to make it look like a mandated requirement for
> broadcast/multicast bearers.=20
>=20
> IMHO, the other special problems with multicast,  mean that it needs
> different and special requirements and cannot be generalized with =
other
> 'push' or 'pull'  technologies quite so easily, tempting though that =
is. I
> think this problem happens because most IT professionals are familiar =
with
> TCP and UDP but rarely use multicast so are unfamiliar with its very
> different attributes.
>=20
> Many vendors offer systems which do have a positive indication of who =
got
> what,  and this is a good thing for applications of up to about 10,000
> receivers. Netherlands studies showed that by the time you scale up to
> millions,  the mass scale of all this becomes a problem, so large =
scale
> systems will have to reluctantly abandon the notion of  individual
> confirmation.
>=20
> Besides, the police authority of a large city don't have the time, =
during an
> emergency, to check out millions of replies nor take any action if =
someone
> does not reply (they are too busy). On the other hand a smaller =
community
> may value such a facility, so it seems that they authority will need =
to
> choose whatever is appropriate for the circumstances at their =
discretion.
> There is no 'one size fits all' solution so we will have to blend many
> bearers in any real situation.  For example the Norwegians take the =
opposite
> view.
>=20
> However, it is possible to confirm that the multicast was transmitted, =
as a
> network of feedback receivers is envisaged in conjunction with an =
outer loop
> reporter system, which would report of the message was transmitted on =
air.
> If it did not, then an alarm would be generated by the originating
> aggregator for the log file. So the positive indication of the fact of =
the
> transmission over the air is satisfied even though individual delivery =
is
> not.=20
>=20
> In summary, IMHO,  Broadcast/multicast bearers will need special =
treatment
> as they don't neatly conform to the classic notions of 'push' or =
'pull'.=20
>=20
> Warm regards, Mark  Wood.
>=20
>=20
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 17 Jan 2011 10:25:24 -0500
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Atoca] Requirement for Originator Authentication?

To say this differently: The authentication and authorization applied in =
a given deployed system is decided by the entities operating that =
deployment.  The ATOCA framework should allow for strong authentication =
and authorization, and provide appropriate mechanisms, but not require =
any particular mechanism to be used.

With regard to "end-to-end" vs. "hop-by-hop": Clearly hop-by-hop =
authentication/authorization is critical -- especially on the first hop, =
where the message is introduced.  But it's also trivial: Just use TLS =
with client authentication. =20

End-to-end is nice to have, but much harder in any sort of global =
context because of the problems with establishing trust anchors.  (Does =
my phone have to have a TA for every emergency authority in the world?)  =
In this case, I think the optimal solution might be more of an =
"end-to-middle" solution.  The originators and relays are part of a =
semi-closed system, at least to the degree that you could expect them to =
coordinate on trust anchors.  So you could enable every entity down to =
the last gateway to validate the authorization for a message, even if =
the client can't.

That said, I think the required technology is probably the same as for =
true end-to-end.  The obvious answer, IMO, is simply to pass CAP in =
S/MIME.

--Richard

On Jan 17, 2011, at 1:34 AM, DALY, BRIAN K (ATTCINW) wrote:

> Authorization to initiate alerts  should be provided by the entity =
that is initiating the alerts and not ATOCA. ATOCA should authenticate =
the receipt of the alerts is from a trusted source.
> Brian K. Daly
>   Sent to you by AT&T...=20
>   America's Fastest Mobile Broadband
>       Network.  Rethink Possible.
>   +1.425.580.6873
> -------
> Sent from my Blackberry
>=20
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Hannes Tschofenig <[email-masked]>; =
[email-masked] <[email-masked]>; Igor Faynberg =
<[email-masked]>
> Sent: Sun Jan 16 15:32:09 2011
> Subject: Re: [Atoca] Requirement for Originator Authentication?
>=20
> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote:
>> Igor raised an interesting question during the meeting in context of
>> the security threats, namely:
>>=20
>> " Do we have the requirement to authenticate the originator? "
>=20
> The question that I heard was not so much related to authentication as =
it was to authorization.  There was also a question about whether =
authentication was identity-based or on some other property, like some =
asserted trait.
>=20
> What statements can we make about how recipients (and relays) =
authorize the receipt (and sending) of alert messages?
>=20
>> I couldn't provide him an answer during the meeting because I was not
>> quite sure whether he was asking the question in the style of
>>=20
>> "Do we need end-to-end security or is a hop-by-hop security solution
>> good enough?"
>=20
> In the context of this interpretation, I think that there's a real =
need to delegate alert distribution.  The scale of distribution makes =
intermediaries a valuable addition.  Relying on the integrity of relays =
makes the authorization question more difficult to resolve.
>=20
> For something concrete, the relay case is probably the simplest.  I =
might trust my signalling peer to a certain extent.  I certainly don't =
trust them enough to generate the massive packet storm requested by an =
alert message.  They might say the alert comes from the government, but =
I might require better proof than their say-so alone.  Distributing an =
alert will cost me money and I want proof.
>=20
> That's one argument.  The other argument says that peering =
relationships require a degree of trust that would not be broken without =
serious ramifications - enough to discourage its abuse.
>=20
> The recipient case might have some interesting quirks.  Particularly =
in wholesale/reseller arrangements.  A recipient that relies on =
hop-by-hop might receive an alert from the network operator: an entity =
with whom they have no direct relationship.  For instance, no fewer than =
two different operators are involved in getting packets to my house, =
neither of which I have a business relationship with.  How would someone =
- ignorant of the convoluted business arrangements that underpin their =
Internet service - decide to authorize an alert that is relayed by =
either party?
>=20
> --Martin
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 17 Jan 2011 10:15:37 -0500
To: Art Botterell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Language and Media Type

Not really; they serve separate functions.  The CAP language element =
says what language the message uses.  The Accept-Language header says =
what languages the client can support.

Putting on my wild-speculation hat for a moment, to add a little more =
color to Martin's comment: If notifications were based on clients =
registering over HTTP or SIP, clients could include an Accept-Language =
header in their registration.  This would allow the alert server to (1) =
tell authorities what languages clients speak (useful forensically, if =
not in real time), and (2) deliver a language-appropriate message to =
each client.  In pictures:
                                        -(en)-[American tourist]
              (en)                     /
[CH ingress]--(fr)--[Geneva gateway]--+--(fr)-[Geneva native]
              (de)                     \
                                        -(de)-[German tourist]

Suggested text:
-- Clients SHOULD include an Accept-Language header in their SUBSCRIBE =
request to indicate which languages they support. =20
-- Clients SHOULD be able to process and render CAP responses containing =
arbitrary UTF-8 data (subject to the limitations of user interface), =
without regard to the CAP <language> element or SIP Content-Language =
header.  Clients MUST NOT discard a CAP message because its <language> =
tag or Content-Language header contain illegal or unsupported values.
-- Servers MUST indicate the language of a CAP message by setting the =
CAP <language> element and SIP Content-Language header to equivalent =
values.
-- Servers SHOULD send clients CAP messages only in the languages =
specified in the Accept-Language header in the client's SUBSCRIBE =
request, which an alert in this language is available. =20

On Jan 16, 2011, at 10:51 PM, Art Botterell wrote:

> Would this be duplicative of the CAP language element?
>=20
> Thanks!
>=20
> - Art
>=20
> On Jan 16, 2011, at 7:08 PM, "Thomson, Martin" =
<[email-masked]> wrote:
>=20
>> On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote:
>>> Keeping Li (if the meeting minutes reflect his name correctly) =
noticed
>>> that we had a language requirement in the requirements draft but
>>> provided no corresponding solution in the SIP-CAP document.
>>=20
>> A solution does seem desirable.  Though I suspect that many alerting =
systems will be deployed with one language or with all of the small =
number of "official" or "supported" languages present in the message.  =
This is probably going to be necessary for all "implicit" subscriptions =
anyhow.
>>=20
>> In HTTP-land, the Accept-Language header is used for that sort of =
thing.  The header is present in SIP, but it's use seems limited - and =
what evidence I have supports the notion that most servers ignore it.
>>=20
>> We could define a use for Accept-Language and see how that flies.
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 17 Jan 2011 09:59:35 -0500
To: Hannes Tschofenig <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, [email-masked]
Subject: Re: [Atoca] What information is used for authorization?

At a high level, the question of what *information* is used for =
authorization is not one for this group to consider.  That's a policy =
question, not an engineering question.  Our focus should be specifying =
*containers* for such information; at most, we specify what *can* be =
used for authorization, not what *will* be.

At a technological level, I would suggest that we take this in steps. =20=

Identity-based access control is clearly low-hanging fruit: There are =
long-standing mechanisms in several protocols (HTTP, SIP, XMPP, etc.) =
for authenticating users either with shared secrets or with PKIX =
certificates. =20

PKIX-based authentication in particular can also support some forms of =
attribute-based authorization, e.g., based on CA identity, CP OID, or =
extensions like the Clearance attribute [1].  This approach has the =
benefit that several organizations already have the necessary =
authentication/authorization infrastructure -- there's not necessarily a =
need for any new credentials or processes.

Once we have something basic in place based on these technologies, then =
we can certainly look at ways of adding additional attributes, say using =
SAML or attribute certificates.

--Richard

[1] <http://tools.ietf.org/html/rfc5913>

On Jan 15, 2011, at 2:31 PM, Hannes Tschofenig wrote:

> Hi all,=20
>=20
> it was Igor again who raised a question regarding authorization at the =
IETF#79 ATOCA meeting. He was wondering whether we would only consider =
the identity of the originator for authorization or some other =
information as well.
>=20
> Are we considering trait-based authorization, see =
http://www.rfc-editor.org/rfc/rfc4484.txt,  to be utilized in this =
context?=20
>=20
> So, what model do we envision?=20
> What other information is useful in the context of an authorization =
decision?=20
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: <[email-masked]>
Sender: "mark.wood" <[email-masked]>
To: <[email-masked]>
Date: Mon, 17 Jan 2011 11:03:21 -0000
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Hello chaps,

Yes, it's only possible to have any kind of delivery reports regarding
specific terminals on a one-to-one kind of unicast delivery. The Australians
were not considering Cell Broadcast or any other kind of multicast
technology as they have selected a SMS based delivery system, so this is
probably what they had in mind. I noticed that atoca language about this is
reserved mostly for the 'subscription push' kind of distribution.  We need
to take care not to make it look like a mandated requirement for
broadcast/multicast bearers. 

IMHO, the other special problems with multicast,  mean that it needs
different and special requirements and cannot be generalized with other
'push' or 'pull'  technologies quite so easily, tempting though that is. I
think this problem happens because most IT professionals are familiar with
TCP and UDP but rarely use multicast so are unfamiliar with its very
different attributes.

Many vendors offer systems which do have a positive indication of who got
what,  and this is a good thing for applications of up to about 10,000
receivers. Netherlands studies showed that by the time you scale up to
millions,  the mass scale of all this becomes a problem, so large scale
systems will have to reluctantly abandon the notion of  individual
confirmation.

Besides, the police authority of a large city don't have the time, during an
emergency, to check out millions of replies nor take any action if someone
does not reply (they are too busy). On the other hand a smaller community
may value such a facility, so it seems that they authority will need to
choose whatever is appropriate for the circumstances at their discretion.
There is no 'one size fits all' solution so we will have to blend many
bearers in any real situation.  For example the Norwegians take the opposite
view.

However, it is possible to confirm that the multicast was transmitted, as a
network of feedback receivers is envisaged in conjunction with an outer loop
reporter system, which would report of the message was transmitted on air.
If it did not, then an alarm would be generated by the originating
aggregator for the log file. So the positive indication of the fact of the
transmission over the air is satisfied even though individual delivery is
not. 

In summary, IMHO,  Broadcast/multicast bearers will need special treatment
as they don't neatly conform to the classic notions of 'push' or 'pull'. 

Warm regards, Mark  Wood.

Content-class: urn:content-classes:message
Date: Sun, 16 Jan 2011 22:35:51 -0800
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Content-class: urn:content-classes:message
Date: Sun, 16 Jan 2011 22:34:18 -0800
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [Atoca] Requirement for Originator Authentication?

Content-class: urn:content-classes:message
Date: Sun, 16 Jan 2011 22:31:38 -0800
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Content-class: urn:content-classes:message
Date: Sun, 16 Jan 2011 22:24:46 -0800
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: [Atoca] Language and Media Type

From: "Thomson, Martin" <[email-masked]>
To: Art Botterell <[email-masked]>, Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Jan 2011 13:12:05 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

From: Art Botterell <[email-masked]>
Date: Sun, 16 Jan 2011 23:51:23 -0400
To: "Thomson, Martin" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Language and Media Type

Would this be duplicative of the CAP language element?

Thanks!

- Art

On Jan 16, 2011, at 7:08 PM, "Thomson, Martin" <[email-masked]> w=
rote:

> On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote:
>> Keeping Li (if the meeting minutes reflect his name correctly) noticed
>> that we had a language requirement in the requirements draft but
>> provided no corresponding solution in the SIP-CAP document.
>=20
> A solution does seem desirable.  Though I suspect that many alerting syste=
ms will be deployed with one language or with all of the small number of "of=
ficial" or "supported" languages present in the message.  This is probably g=
oing to be necessary for all "implicit" subscriptions anyhow.
>=20
> In HTTP-land, the Accept-Language header is used for that sort of thing.  T=
he header is present in SIP, but it's use seems limited - and what evidence I=
 have supports the notion that most servers ignore it.
>=20
> We could define a use for Accept-Language and see how that flies.
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
Date: Sun, 16 Jan 2011 23:20:37 -0400
To: Hannes Tschofenig <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Mainly I was just suggesting one way of looking at the "how large is 'large'=
" question.  Although it does highlight some of Martin's questions about how=
 to adapt a session initiation protocol to a one-to-very-many application, i=
f that's what we have in mind.  As he rightly points out, responses don't on=
ly happen at the application level.

Thanks!

- Art

On Jan 16, 2011, at 11:22 AM, Hannes Tschofenig <[email-masked]> w=
rote:

> Hi Art,=20
>=20
> that's an interesting comment particularly since we do not have a requirem=
ent for responses by receivers (or Recipients) of alert messages. I am not s=
ure to whom they would sent their response to. To the originator, to some ga=
teway, etc?=20
>=20
> Ciao
> Hannes
>=20
> On Jan 15, 2011, at 11:58 PM, Art Botterell wrote:
>=20
>> One difference in "broadcast" delivery is that it's frequntly impractical=
 and/or undesirable to try to track individual deliveries or process individ=
ual responses.
>>=20
>> Thanks!
>>=20
>> - Art
>>=20
>> On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig <[email-masked]=
t> wrote:
>>=20
>>> Hi all,=20
>>>=20
>>> during the ATOCA meeting at IETF#79 Igor raised a question regarding req=
uirement D2:
>>> "
>>> Req-D2:
>>>=20
>>>    The protocol solution MUST allow delivery of messages
>>>    simultaneously to a large audience.
>>> "
>>>=20
>>> He was asking whether there is a need to put a number for large audience=
 there.
>>>=20
>>> Maybe Igor has a specific number in mind that would matter from a protoc=
ol design perspective but I do not have such a number that would provide a m=
eaningful distinction.=20
>>>=20
>>> There is, however, the question what types of problems we expect with ve=
ry large number of alert message receivers and how we document this aspect i=
n the requirements document.=20
>>>=20
>>> Suggestions? Thoughts?=20
>>>=20
>>> Ciao
>>> Hannes
>>>=20
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>=20

From: <[email-masked]>
Sender: "mark.wood" <[email-masked]>
To: <[email-masked]>
Date: Mon, 17 Jan 2011 00:20:17 -0000
Subject: Re: [Atoca] Language and Media Type

Hi

Switzerland is a 'worst case scenario' example,By law they need to transmit
in German, French, Italian and "Romanshe". They will also probably transmit
in English as well to reach tourists, especially at airports. 

There may be other special cases such as Japanese in Zermat, where large
groups of Japanese often congregate. 

I expect there to be very few cases where more than half a dozen languages
would be sent for each alert message, though civic information messages are
a different matter and may either be language specific or in some cases sent
in a dozen languages. However information messages are much less time
critical than alert messages so some extra delay is tolerable.  

The matter of language is a very hotly sensitive one in many regions. For
example, in Wales you must send official communications  in Welsh and
English, even though most Welsh speak good English. This problem is very
sensitive indeed in many parts of the world, to such an extent that a
solution that does not have some solution to multiple languages is a
non-starter due to the political heat it would cause if anyone in the other
ethnic group died due to not getting a message. Conversely, politicians like
the idea of being able to reach out to ethnic groups in this way as a way of
building trust, this is why almost all of them insist on a multi-language
capability from the start. 

 In some cases indigenous populations text each other in a 'Latinized font
version' of their own language. Therefore the problem of fonts is not always
as big a problem as we may think, but clearly a more capable roadmap is
needed in the future. 

In Cell Broadcast, for example, we are proposing at least three different
mechanisms for distinguishing one from the other, because a clear winner has
not appeared yet and the debate is very contentious. Very likely, at some
point, a clear winner will emerge and I hope only one  mechanism will
suffice. Meantime, governments are wanting to keep their options open so
this is why they are proposing all three mechanisms in parallel for now, for
later review.  Because the matter is now seen as urgent, they would rather
start now with something imperfect than wait for the perfect solution to
eventually appear before making a move. 

Warm Regards, Mark Wood DRCF. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Thomson, Martin
Sent: Sunday, January 16, 2011 11:08 PM
To: Hannes Tschofenig; [email-masked]
Subject: Re: [Atoca] Language and Media Type

On 2011-01-16 at 06:30:11, Hannes Tschofenig wrote:
> Keeping Li (if the meeting minutes reflect his name correctly) noticed 
> that we had a language requirement in the requirements draft but 
> provided no corresponding solution in the SIP-CAP document.

A solution does seem desirable.  Though I suspect that many alerting systems
will be deployed with one language or with all of the small number of
"official" or "supported" languages present in the message.  This is
probably going to be necessary for all "implicit" subscriptions anyhow.

In HTTP-land, the Accept-Language header is used for that sort of thing.
The header is present in SIP, but it's use seems limited - and what evidence
I have supports the notion that most servers ignore it.

We could define a use for Accept-Language and see how that flies.

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

From: Art Botterell <[email-masked]>
Date: Sun, 16 Jan 2011 19:55:57 -0400
To: "Thomson, Martin" <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement for Originator Authentication?

I suspect we'll find that different carriers/gateways will insist on being a=
ble to apply their own authorization rules, and thus that end of things will=
 be distributed perforce.  By the same token, I don't foresee a single globa=
l identification/credentialling scheme.  The best we can hope for, I suspect=
, is a reasonable degree of reciprocity among authorities.

The first question, I think, is whether there's a use case for anonymity in a=
uthority-to-public alerting; not sure what that would be.

The next question is how far it makes sense to go in specifying the form of a=
n identification scheme.

Thanks!

- Art

On Jan 16, 2011, at 7:32 PM, "Thomson, Martin" <[email-masked]> w=
rote:

> On 2011-01-16 at 06:30:33, Hannes Tschofenig wrote:
>> Igor raised an interesting question during the meeting in context of
>> the security threats, namely:
>>=20
>> " Do we have the requirement to authenticate the originator? "
>=20
> The question that I heard was not so much related to authentication as it w=
as to authorization.  There was also a question about whether authentication=
 was identity-based or on some other property, like some asserted trait.
>=20
> What statements can we make about how recipients (and relays) authorize th=
e receipt (and sending) of alert messages?
>=20
>> I couldn't provide him an answer during the meeting because I was not
>> quite sure whether he was asking the question in the style of
>>=20
>> "Do we need end-to-end security or is a hop-by-hop security solution
>> good enough?"
>=20
> In the context of this interpretation, I think that there's a real need to=
 delegate alert distribution.  The scale of distribution makes intermediarie=
s a valuable addition.  Relying on the integrity of relays makes the authori=
zation question more difficult to resolve.
>=20
> For something concrete, the relay case is probably the simplest.  I might t=
rust my signalling peer to a certain extent.  I certainly don't trust them e=
nough to generate the massive packet storm requested by an alert message.  T=
hey might say the alert comes from the government, but I might require bette=
r proof than their say-so alone.  Distributing an alert will cost me money a=
nd I want proof.
>=20
> That's one argument.  The other argument says that peering relationships r=
equire a degree of trust that would not be broken without serious ramificati=
ons - enough to discourage its abuse.
>=20
> The recipient case might have some interesting quirks.  Particularly in wh=
olesale/reseller arrangements.  A recipient that relies on hop-by-hop might r=
eceive an alert from the network operator: an entity with whom they have no d=
irect relationship.  For instance, no fewer than two different operators are=
 involved in getting packets to my house, neither of which I have a business=
 relationship with.  How would someone - ignorant of the convoluted business=
 arrangements that underpin their Internet service - decide to authorize an a=
lert that is relayed by either party?
>=20
> --Martin
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2011 07:36:43 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Atoca] Updated Requirements and Terminology Draft

T24gMjAxMS0wMS0xNiBhdCAwNjozMDowNSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEFz
IGEgcmVzdWx0LCB3ZSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0Og0KPiBodHRwOi8vd3d3LmlldGYu
b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWF0b2NhLXJlcXVpcmVtZW50cy0NCj4gMDEu
dHh0DQoNClRoYW5rcyBIYW5uZXMgYW5kIEJyaWFuLg0K

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>, Igor Faynberg <[email-masked]>
Date: Mon, 17 Jan 2011 07:32:09 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Atoca] Requirement for Originator Authentication?

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, Art Botterell <[email-masked]>
Date: Mon, 17 Jan 2011 07:15:04 +0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

From: "Thomson, Martin" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 17 Jan 2011 07:08:17 +0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [Atoca] Language and Media Type

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 16 Jan 2011 17:22:04 +0200
To: Art Botterell <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

Hi Art,=20

that's an interesting comment particularly since we do not have a =
requirement for responses by receivers (or Recipients) of alert =
messages. I am not sure to whom they would sent their response to. To =
the originator, to some gateway, etc?=20

Ciao
Hannes

On Jan 15, 2011, at 11:58 PM, Art Botterell wrote:

> One difference in "broadcast" delivery is that it's frequntly =
impractical and/or undesirable to try to track individual deliveries or =
process individual responses.
>=20
> Thanks!
>=20
> - Art
>=20
> On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig =
<[email-masked]> wrote:
>=20
>> Hi all,=20
>>=20
>> during the ATOCA meeting at IETF#79 Igor raised a question regarding =
requirement D2:
>> "
>>  Req-D2:
>>=20
>>     The protocol solution MUST allow delivery of messages
>>     simultaneously to a large audience.
>> "
>>=20
>> He was asking whether there is a need to put a number for large =
audience there.
>>=20
>> Maybe Igor has a specific number in mind that would matter from a =
protocol design perspective but I do not have such a number that would =
provide a meaningful distinction.=20
>>=20
>> There is, however, the question what types of problems we expect with =
very large number of alert message receivers and how we document this =
aspect in the requirements document.=20
>>=20
>> Suggestions? Thoughts?=20
>>=20
>> Ciao
>> Hannes
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 16 Jan 2011 17:20:07 +0200
To: Art Botterell <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] What information is used for authorization?

Hi Art,=20

I think it would be useful to have an example here.=20

For example, it would be important to know to whom the individual (in =
our terminology the Author of the Alert message) would authenticate =
himself to.

Also, it might be useful to know what a gateway, relay or even a =
Receiver (not to talk about a Recipient) would do with this information.=20=

Then, with 'credentialling agency' you mean the entity that issued the =
credentials to the individual (the Author). For example, in a public key =
based system we are talking about the certificate authority here. Right?

Ciao
Hannes

On Jan 15, 2011, at 11:51 PM, Art Botterell wrote:

> I'd suggest requiring credible identification of the individual and of =
the credentialling agency.  (Not every gateway will necessarily honor =
credentials from every issuer.)   Different gateways could then apply =
different policies based on those and on message contents, including =
potentially special CAP parameters or other fields as desired locally.
>=20
> Thanks!
>=20
> - Art
>=20
> On Jan 15, 2011, at 11:31 AM, Hannes Tschofenig =
<[email-masked]> wrote:
>=20
>> Hi all,=20
>>=20
>> it was Igor again who raised a question regarding authorization at =
the IETF#79 ATOCA meeting. He was wondering whether we would only =
consider the identity of the originator for authorization or some other =
information as well.
>>=20
>> Are we considering trait-based authorization, see =
http://www.rfc-editor.org/rfc/rfc4484.txt,  to be utilized in this =
context?=20
>>=20
>> So, what model do we envision?=20
>> What other information is useful in the context of an authorization =
decision?=20
>>=20
>> Ciao
>> Hannes
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
Date: Sat, 15 Jan 2011 13:58:14 -0800
To: Hannes Tschofenig <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] Requirement D2: "Large Audience"

One difference in "broadcast" delivery is that it's frequntly impractical an=
d/or undesirable to try to track individual deliveries or process individual=
 responses.

Thanks!

- Art

On Jan 15, 2011, at 11:30 AM, Hannes Tschofenig <[email-masked]> w=
rote:

> Hi all,=20
>=20
> during the ATOCA meeting at IETF#79 Igor raised a question regarding requi=
rement D2:
> "
>   Req-D2:
>=20
>      The protocol solution MUST allow delivery of messages
>      simultaneously to a large audience.
> "
>=20
> He was asking whether there is a need to put a number for large audience t=
here.
>=20
> Maybe Igor has a specific number in mind that would matter from a protocol=
 design perspective but I do not have such a number that would provide a mea=
ningful distinction.=20
>=20
> There is, however, the question what types of problems we expect with very=
 large number of alert message receivers and how we document this aspect in t=
he requirements document.=20
>=20
> Suggestions? Thoughts?=20
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Art Botterell <[email-masked]>
Date: Sat, 15 Jan 2011 13:51:21 -0800
To: Hannes Tschofenig <[email-masked]>
Cc: Igor Faynberg <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Atoca] What information is used for authorization?

I'd suggest requiring credible identification of the individual and of the c=
redentialling agency.  (Not every gateway will necessarily honor credentials=
 from every issuer.)   Different gateways could then apply different policie=
s based on those and on message contents, including potentially special CAP p=
arameters or other fields as desired locally.

Thanks!

- Art

On Jan 15, 2011, at 11:31 AM, Hannes Tschofenig <[email-masked]> w=
rote:

> Hi all,=20
>=20
> it was Igor again who raised a question regarding authorization at the IET=
F#79 ATOCA meeting. He was wondering whether we would only consider the iden=
tity of the originator for authorization or some other information as well.
>=20
> Are we considering trait-based authorization, see http://www.rfc-editor.or=
g/rfc/rfc4484.txt,  to be utilized in this context?=20
>=20
> So, what model do we envision?=20
> What other information is useful in the context of an authorization decisi=
on?=20
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:31:16 +0200
To: [email-masked], Igor Faynberg <[email-masked]>
Subject: [Atoca] What information is used for authorization?

Hi all,=20

it was Igor again who raised a question regarding authorization at the =
IETF#79 ATOCA meeting. He was wondering whether we would only consider =
the identity of the originator for authorization or some other =
information as well.
=20
Are we considering trait-based authorization, see =
http://www.rfc-editor.org/rfc/rfc4484.txt,  to be utilized in this =
context?=20

So, what model do we envision?=20
What other information is useful in the context of an authorization =
decision?=20

Ciao
Hannes

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:30:33 +0200
To: [email-masked], Igor Faynberg <[email-masked]>
Subject: [Atoca] Requirement for Originator Authentication?

Hi all,=20

Igor raised an interesting question during the meeting in context of the =
security threats, namely:=20

" Do we have the requirement to authenticate the originator? "

I couldn't provide him an answer during the meeting because I was not =
quite sure whether he was asking the question in the style of=20

"Do we need end-to-end security or is a hop-by-hop security solution =
good enough?"

So, I am not quite sure how to interpret the question.=20

Ciao
Hannes

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:30:24 +0200
To: [email-masked], Igor Faynberg <[email-masked]>
Subject: [Atoca] Requirement D2: "Large Audience"

Hi all,=20

during the ATOCA meeting at IETF#79 Igor raised a question regarding =
requirement D2:
"
   Req-D2:

      The protocol solution MUST allow delivery of messages
      simultaneously to a large audience.
"

He was asking whether there is a need to put a number for large audience =
there.

Maybe Igor has a specific number in mind that would matter from a =
protocol design perspective but I do not have such a number that would =
provide a meaningful distinction.=20

There is, however, the question what types of problems we expect with =
very large number of alert message receivers and how we document this =
aspect in the requirements document.=20

Suggestions? Thoughts?=20

Ciao
Hannes

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:30:11 +0200
To: [email-masked]
Subject: [Atoca] Language and Media Type

Hi all,=20

Keeping Li (if the meeting minutes reflect his name correctly) noticed =
that we had a language requirement in the requirements draft but =
provided no corresponding solution in the SIP-CAP document.=20

For subscriptions we currently have the following requirements:

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

   Req-S1:

      The protocol solution MUST allow a potential Recipient to indicate
      the language used by alert messages.

   Req-S2:

      The protocol solution MUST allow a potential Recipient to express
      the geographical area it wants to receive alerts about.

   Req-S3:

      The protocol solution MUST allow a potential Recipient to indicate
      preferences about the type of alerts it wants to receive.

   Req-S4:

      The protocol solution MUST allow a potential Recipient to express
      preference for certain media types.  The support for different
      media types depends on the content of the warning message but also
      impacts the communication protocol.  This functionality is, for
      example, useful for hearing and vision impaired persons.

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

No doubts have been raised about the usefulness of requirement S2 and S3 =
but with the requirements S1 and S4 it is not quite the same.=20
Do we expect that a system will allow a subscriber to indicate language =
preferences and the ability to receive certain media types?=20
Are there other parameters that would be more useful?=20

Ciao
Hannes

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 21:30:05 +0200
To: [email-masked]
Subject: [Atoca] Updated Requirements and Terminology Draft

Hi all,=20

we went through the meeting minutes=20
http://www.ietf.org/proceedings/79/minutes/atoca.txt
and the recording=20
http://79archive.dyndns.org/ietf79/ietf79-ch5-fri-noon.mp3
in order to address the feedback we had gotten at IETF#79.=20

As a result, we have updated the draft:
http://www.ietf.org/internet-drafts/draft-ietf-atoca-requirements-01.txt

The changes are:=20
* In Section 1.2 we talk about the two steps  "subscription" and "alert =
delivery" as a way to classify the protocol interaction. As a =
consequence we also changed the subject headings of the requirements =
section. These are editorial changes.=20
* We shorted Section 3. This is the description of the alert delivery =
architecture.=20
* The requirements in Section 4 have not changed but they were =
re-grouped. I added an editorial clarification to  Req-D1 regarding =
congestion. This was mentioned during the meeting by Keith.=20
* The security consideration section now has a longer introduction.=20
* Acknowledged those people who provided feedback at IETF#79.=20

There are a few open issues. I will post separate mails to discuss =
those.=20

Ciao
Hannes & Brian=

From: [email-masked]
To: [email-masked]
Date: Sat, 15 Jan 2011 11:00:01 -0800
Cc: [email-masked]
Subject: [Atoca] I-D Action:draft-ietf-atoca-requirements-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Authority-to-Citizen Alert Working Group of the IETF.

	Title           : Requirements, Terminology and Framework for Exigent Communications
	Author(s)       : H. Schulzrinne, et al.
	Filename        : draft-ietf-atoca-requirements-01.txt
	Pages           : 14
	Date            : 2011-01-15

Before, during and after emergency situations various agencies need
to provide information to a group of persons or to the public within
a geographical area.  While many aspects of such systems are specific
to national or local jurisdictions, emergencies span such boundaries
and notifications need to reach visitors from other jurisdictions.

This document provides terminology, requirements and an architectural
description for protocols exchanging alerts between IP-based end
points.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-atoca-requirements-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-atoca-requirements-01.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--