Subject: [earlywarning] New Charter Text for ATOCA

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Mar 2010 17:26:28 -0400

Based on the discussions during the breakout session we came up with the 
following text proposal.
Please let us know whether you are OK with the wording.

Authority to Citizen Alert (ATOCA)
==================================

Authorities need mechanisms to notify citizens and visitors of emergency
events.   Traditionally, they have done so with broadcast networks (radio
and television).  The Internet provides another way for authority to 
citizen
alerts to be sent, but it also presents new challenges. While there are
some existing layer 2 mechanisms for delivering alerts the work in this 
group
focuses on delivering alerts to IP endpoints only.

The general message pattern that this group is intended to address is the
sending of alerts from a set of pre-authorized agents (e.g., governmental
agencies) to a large population. The goal of this group is not to specify
how originators of alerts obtain authorization, but rather how a messaging
system can verify authorization and deliver message to the intended 
recipients.
A critical element of the work arethe mechanisms that assure that only
authorized agents can send alerts.

The recipients of these alerts are the wide range of devices connected to
the Internet and 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.  Ideally, the alerts would contain, or refer to
media other than text media (e.g., audio and/or video), but the initial
work in the group is focused on small messages, which may be mechanically
rendered by thedevice in other forms (text to speech for example).  In
situations of a major emergency there could be scenarios where there are
multiple alerts generated that may require that a priority mechanism has
to be implemented, and this mechanism is out of scope at his time.

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
affected by the alert.  In many jurisdictions, there are regulations that
define whether recipients within the affected area have opt-in or opt-out
capability, but the protocols we will define will include both opt-in and
opt-out mechanisms. The group will explore how to support both opt-in and
opt-out at the level of communication protocols.

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts that are sent to an associated
party.  An example of such a subscription would be 'send me alerts which are
sent too my daughter based on her location'. This work builds on existing
IETF geopriv location work.

There are other efforts in other fora on alerts, which will be considered
in this effort.  For example, we expect to make use of the OASIS Common
Alerting Protocol (CAP) for the encoding of alerts.  ATIS, TIA, ITU-T, ETSI
and 3GPP also have alert efforts underway, and consultation with these
efforts will be undertaken to avoid unnecessary duplication of effort.
Of course, existing protocols for delivering messages (e.g., SIP)
will be the basis for the message delivery system of this working group.

The security implications of mechanisms that can send alerts to billions of
devices are profound, but the utility of the mechanism encourages us to face
the problems and solve them.

Milestones
 
TBD      Initial document for "Terminology and Framework" document.
         A starting point for this work is
         draft-norreys-ecrit-authority2individuals-requirements.
TBD      Initial document for conveying alerts in SIP
TBD      Initial document for subscribing to alerts using SIP
         A starting point for this work is draft-rosen-sipping-cap
TBD      Initial document for locating the alerting server for a geographic
         region. A starting point for this work is
         draft-rosen-ecrit-lost-early-warning.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Mar 2010 13:22:01 -0400

> In

I got feedback that this is a bit strong.

 From the discussions in the room I understood that this was a pure 
scoping question. The initial scope is to work out the basic mechanisms. 
Later, priority handling would be investigated (but requires a WG 
rechartering).

To those attending the meeting: Is this a fair summary of the discussion 
we had?

My suggestion is to re-word the statement a bit:

"In situations of a major emergency there could be scenarios where there are
multiple alerts generated that may require that a priority mechanism has
to be used. The work on a resource priority mechanism is out of scope of the initial charter."

Is this better? 

Ciao
Hannes

---

From: ken carlberg <[email-masked]>
Date: Thu, 25 Mar 2010 13:49:43 -0400

> to be used. The work on a resource priority mechanism is out of scope of the initial charter."

personally, I would recommend 
s/of the initial charter/of the initial charter, but may be revisited at a later date"

overall, I feel comfortable with the above and pushing aside the subject of prioritization in this first go around -- if for nothing else, to keep the proposed effort as simple and focused as possible.  But I'd like to convey that we'd keep this topic open for future discussion if the need arises.  reason being that some countries (ie, authorities) outside of the US do support/prefer to prioritize communications when a contention exists.

cheers,

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 25 Mar 2010 14:28:45 -0400

I support Ken's proposal.

Janet

[email-masked] wrote on 03/25/2010 01:49:43 PM:

> [image removed] 
> 
> Re: [earlywarning] New Charter Text for ATOCA
> 
> ken carlberg 
> 
> to:
> 
> Hannes Tschofenig
> 
> 03/25/2010 01:51 PM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> earlywarning
> 
> 
> > "In situations of a major emergency there could be scenarios 
wherethere are
> overall, I feel comfortable with the above and pushing aside the 
> subject of prioritization in this first go around -- if for nothing 
> else, to keep the proposed effort as simple and focused as possible.
> But I'd like to convey that we'd keep this topic open for future 
> discussion if the need arises.  reason being that some countries 
> (ie, authorities) outside of the US do support/prefer to prioritize 
> communications when a contention exists.
> 
> cheers,
> 
> -ken
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2010 15:27:26 -0500

At 12:22 PM 3/25/2010, Hannes Tschofenig wrote:

> scoping question. The initial scope is to work out the basic 
> mechanisms. Later, priority handling would be investigated (but 
> requires a WG rechartering).
>
>To those attending the meeting: Is this a fair summary of the 
>discussion we had?
>

I don't like this. This wording is better than what was previously 
there, but doesn't make it clear enough what will be done when it 
needs to be done. It should state explicitly that an RFC 4412 
Resource-Priority namespace is how "priority" will be addressed by 
this WG, but that will be defined in a subsequent recharter in the future.

I agree an RP namespace shouldn't be defined quickly, but I'm also 
aware of how long ECRIT has had a doc defining it's RP namespace and 
still doens't have a milestone to get a WGLC on the done doc.

This topic is something that will be looked at by many organizations, 
SDOs and governments. The idea that we don't have a priority 
mechanism in mind is something those other organizations will quickly 
question. Stating in the charter that we know about the topic, and 
actually know how to address the topic (with the reference), but are 
acknowledging that this isn't an initial priority of the WG should be fine.

At the end of the day, we all know that defining an RP namespace will 
be a 5-8 page ID that should take less than 2 days to write, so it's 
not like this WG (once it becomes a WG) will have massive choices of 
alternatives to analyze, thus necessitating long WG deliberations and 
implementation experience in testbed trials.

If CAP is to be carried in SIP, then the one existing SIP resource 
priority mechanism will be used - unless it is proven not to work 
(then a lot of other WGs will have to more work on their hands too).

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Mar 2010 16:31:15 -0400

Hi James,

I thought about including wording regarding the resource priority header 
defined for SIP in the charter text but then was wondering whether I am 
going a bit too far given that I say it is out-of-scope at the moment.

So, do you push strongly for putting RPH into the charter?

Ciao
Hannes

James M. Polk wrote:
> SDOs and governments. The idea that we don't have a priority mechanism 
> in mind is something those other organizations will quickly question. 
> Stating in the charter that we know about the topic, and actually know 
> how to address the topic (with the reference), but are acknowledging 
> that this isn't an initial priority of the WG should be fine.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 16:40:51 -0400

Also, this seems rather orthogonal. Nothing prevents use of any resource priority mechanism or namespace with alerts. It would only matter if we need to define fundamentally new RPH mechanisms. We don't need to specify which routing protocol, SIP extensions or IP options we are using, either.

Henning

On Mar 25, 2010, at 4:31 PM, Hannes Tschofenig wrote:

> Hi James,
> 
> I thought about including wording regarding the resource priority header defined for SIP in the charter text but then was wondering whether I am going a bit too far given that I say it is out-of-scope at the moment.
> 
>>> From the discussions in the room I understood that this was a pure scoping question. The initial scope is to work out the basic mechanisms. Later, priority handling would be investigated (but requires a WG rechartering).
>>> 
>>> To those attending the meeting: Is this a fair summary of the discussion we had?
>>> 
>> I don't like this. This wording is better than what was previously there, but doesn't make it clear enough what will be done when it needs to be done. It should state explicitly that an RFC 4412 Resource-Priority namespace is how "priority" will be addressed by this WG, but that will be defined in a subsequent recharter in the future.
>> 
>> I agree an RP namespace shouldn't be defined quickly, but I'm also aware of how long ECRIT has had a doc defining it's RP namespace and still doens't have a milestone to get a WGLC on the done doc.
>> 
>> This topic is something that will be looked at by many organizations, SDOs and governments. The idea that we don't have a priority mechanism in mind is something those other organizations will quickly question. Stating in the charter that we know about the topic, and actually know how to address the topic (with the reference), but are acknowledging that this isn't an initial priority of the WG should be fine.
>> 
>> At the end of the day, we all know that defining an RP namespace will be a 5-8 page ID that should take less than 2 days to write, so it's not like this WG (once it becomes a WG) will have massive choices of alternatives to analyze, thus necessitating long WG deliberations and implementation experience in testbed trials.
>> 
>> If CAP is to be carried in SIP, then the one existing SIP resource priority mechanism will be used - unless it is proven not to work (then a lot of other WGs will have to more work on their hands too).
>> 
>> James
>> 
>> 
>>> Is this better?
>>> 
>>> Ciao
>>> Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2010 17:40:48 -0500

I'm not pushing the acceleration of this definition - merely pointing 
out the probability that many will observe this work, and this 
charter, and see at least one hole that wasn't mentioned that 
probably (in their minds) should have been. Some might conclude that 
deeming "priority as out of scope" to be shortsighted.  Mentioning 
4412 will let charter readers know this group believes it knows how 
to define priority, and has a specific solution in mind (at least for 
SIP) - yet knows that other work has to precede this definition. 
Comments may come in saying its delay should be shortened or 
lengthened. For example, Chile's government is changing their laws 
within 3 weeks to deal with exactly what this group is about - based 
on the events of their earthquake; as I've been personally contacted 
on 2 fronts to help them. Anyone want to predict that priority won't 
come up in those discussions?

James

At 03:40 PM 3/25/2010, Henning Schulzrinne wrote:
>Also, this seems rather orthogonal. Nothing prevents use of any 
>resource priority mechanism or namespace with alerts. It would only 
>matter if we need to define fundamentally new RPH mechanisms. We 
>don't need to specify which routing protocol, SIP extensions or IP 
>options we are using, either.
>
>Henning
>
> > I thought about including wording regarding the resource priority 
> header defined for SIP in the charter text but then was wondering 
> whether I am going a bit too far given that I say it is 
> out-of-scope at the moment.
> >
> >>> From the discussions in the room I understood that this was a 
> pure scoping question. The initial scope is to work out the basic 
> where there are
> >> I don't like this. This wording is better than what was 
> previously there, but doesn't make it clear enough what will be 
> done when it needs to be done. It should state explicitly that an 
> RFC 4412 Resource-Priority namespace is how "priority" will be 
> addressed by this WG, but that will be defined in a subsequent 
> recharter in the future.
> >>
> >> I agree an RP namespace shouldn't be defined quickly, but I'm 
> also aware of how long ECRIT has had a doc defining it's RP 
> namespace and still doens't have a milestone to get a WGLC on the done doc.
> >>
> >> This topic is something that will be looked at by many 
> organizations, SDOs and governments. The idea that we don't have a 
> priority mechanism in mind is something those other organizations 
> will quickly question. Stating in the charter that we know about 
> the topic, and actually know how to address the topic (with the 
> reference), but are acknowledging that this isn't an initial 
> priority of the WG should be fine.
> >>
> >> At the end of the day, we all know that defining an RP namespace 
> will be a 5-8 page ID that should take less than 2 days to write, 
> so it's not like this WG (once it becomes a WG) will have massive 
> choices of alternatives to analyze, thus necessitating long WG 
> deliberations and implementation experience in testbed trials.
> >>
> >> If CAP is to be carried in SIP, then the one existing SIP 
> resource priority mechanism will be used - unless it is proven not 
> to work (then a lot of other WGs will have to more work on their hands too).
> >>
> >> James
> >>
> >>
> >>> Is this better?
> >>>
> >>> Ciao
> >>> Hannes

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Mar 2010 18:47:20 -0400

There are three possibilities:

- We anticipate that existing priority mechanisms are trivially applicable and that the details of which one to use is likely to depend on the local jurisdiction or lower-layer technology. I have no objection to mentioning that, minus the "trivial" part.

- We need to write a draft describing this. This seems unnecessary; we don't write drafts for every single application. ("Here is the draft how generals use RPH to boss around their sergeants.") If it were, we'd need a milestone.

- We need one or more new mechanisms that are specific to the alerting application. This also doesn't seem to be the case.

Henning

On Mar 25, 2010, at 6:40 PM, James M. Polk wrote:

> I'm not pushing the acceleration of this definition - merely pointing out the probability that many will observe this work, and this charter, and see at least one hole that wasn't mentioned that probably (in their minds) should have been. Some might conclude that deeming "priority as out of scope" to be shortsighted.  Mentioning 4412 will let charter readers know this group believes it knows how to define priority, and has a specific solution in mind (at least for SIP) - yet knows that other work has to precede this definition. Comments may come in saying its delay should be shortened or lengthened. For example, Chile's government is changing their laws within 3 weeks to deal with exactly what this group is about - based on the events of their earthquake; as I've been personally contacted on 2 fronts to help them. Anyone want to predict that priority won't come up in those discussions?
> 
> James
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 25 Mar 2010 15:56:04 -0700

I like option (1), although I would contribute to Military Bossing  
Around Protocol (MBAP) if someone wants to write it.  Proposed text:
"
In situations of a major emergency there could be scenarios where  
there are multiple alerts generated that may require a priority  
mechanism.  Since solutions developed by this working group will re- 
used existing IETF messaging standards, the priority mechanisms for  
those protocols can be applied (e.g., the SIP resource priority header  
in RFC 4412).  If the initial work of this group encounters priority  
requirements specific to emergency alerting, then they may be  
addressed in a revision to this charter.
"

On Mar 25, 2010, at 3:47 PM, Henning Schulzrinne wrote:

> - We anticipate that existing priority mechanisms are trivially  
> applicable and that the details of which one to use is likely to  
> depend on the local jurisdiction or lower-layer technology. I have  
> no objection to mentioning that, minus the "trivial" part.
>
> - We need to write a draft describing this. This seems unnecessary;  
> we don't write drafts for every single application. ("Here is the  
> draft how generals use RPH to boss around their sergeants.") If it  
> were, we'd need a milestone.
>
> - We need one or more new mechanisms that are specific to the  
> alerting application. This also doesn't seem to be the case.
>
> Henning
>
>> I'm not pushing the acceleration of this definition - merely  
>> pointing out the probability that many will observe this work, and  
>> this charter, and see at least one hole that wasn't mentioned that  
>> probably (in their minds) should have been. Some might conclude  
>> that deeming "priority as out of scope" to be shortsighted.   
>> Mentioning 4412 will let charter readers know this group believes  
>> it knows how to define priority, and has a specific solution in  
>> mind (at least for SIP) - yet knows that other work has to precede  
>> this definition. Comments may come in saying its delay should be  
>> shortened or lengthened. For example, Chile's government is  
>> changing their laws within 3 weeks to deal with exactly what this  
>> group is about - based on the events of their earthquake; as I've  
>> been personally contacted on 2 fronts to help them. Anyone want to  
>> predict that priority won't come up in those discussions?
>>
>> James
>>
>>> resource priority mechanism or namespace with alerts. It would  
>>> only matter if we need to define fundamentally new RPH mechanisms.  
>>> We don't need to specify which routing protocol, SIP extensions or  
>>> IP options we are using, either.
>>>
>>> Henning
>>>
>>>> whether I am going a bit too far given that I say it is out-of- 
>>>> scope at the moment.
>>>>
>>>>>> pure scoping question. The initial scope is to work out the  
>>>>>> basic mechanisms. Later, priority handling would be  
>>>>>> investigated (but requires a WG rechartering).
>>>>>>
>>>>> done when it needs to be done. It should state explicitly that  
>>>>> an RFC 4412 Resource-Priority namespace is how "priority" will  
>>>>> be addressed by this WG, but that will be defined in a  
>>>>> subsequent recharter in the future.
>>>>>
>>>>> organizations, SDOs and governments. The idea that we don't have  
>>>>> a priority mechanism in mind is something those other  
>>>>> organizations will quickly question. Stating in the charter that  
>>>>> we know about the topic, and actually know how to address the  
>>>>> topic (with the reference), but are acknowledging that this  
>>>>> isn't an initial priority of the WG should be fine.
>>>>>
>>>>> will be a 5-8 page ID that should take less than 2 days to  
>>>>> write, so it's not like this WG (once it becomes a WG) will have  
>>>>> massive choices of alternatives to analyze, thus necessitating  
>>>>> long WG deliberations and implementation experience in testbed  
>>>>> trials.
>>>>>
>>>>> resource priority mechanism will be used - unless it is proven  
>>>>> not to work (then a lot of other WGs will have to more work on  
>>>>> their hands too).
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>>> Is this better?
>>>>>>
>>>>>> Ciao
>>>>>> Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Mar 2010 18:27:31 -0500

At 05:56 PM 3/25/2010, Richard Barnes wrote:
>Around Protocol (MBAP) if someone wants to write it.

hehe

the text below is acceptable with the following nit fix suggestions

>Proposed text:
>"
>In situations of a major emergency

"," (comma)

>there could

s/could/can

>be scenarios where
>mechanism.  Since solutions developed by this working group will re- used

s/re- used/re-used

>  existing IETF messaging standards, the priority mechanisms for

James