Subject: Re: [earlywarning] Finishing the Charter Text Discussions
From: [email-masked]
To: "DRAGE, Keith (Keith)" <[email-masked]>
Cc: "DALY, BRIAN K \(ATTCINW\)" <[email-masked]>, "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 9 Apr 2010 19:27:29 -0400 (EDT)
List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " <earlywarning.ietf.org>

Keith -

Apologies. You are correct. I am personally not aware of any. As you and
others have stated, there are definitely discussions and work being done
at other levels in the warning/alerting standards stack - such as using
CMAS as a starting point.

Multi-language is definitely something the OGC Members are tuned into.

Thanks!

Carl

> Carl, I think the problem is that your statement: "I do not see
> discussions on L2 or CMAS or whatever", implies on first reading that
> there are none, rather than you are not aware of them.
>
> Indeed there are activities taking place on trialing cell broadcast for
> such alerts, and at least the intent I was seeing from the people involved
> in this was that they would be looking to activities in ETSI to channel
> this work into 3GPP, and that they would be using the CMAS work as a
> starting point. One key problem to solve is that in multilingual
> countries, the alert would have to be delivered in multiple languages -
> not a problem except procedures need to be defined to cycle round such
> messages, which does not exist in CMAS at the moment. I also gathered some
> clear statements that they wanted a solution independent of any work that
> took place elsewhere on other infrastructures.
>
> So to me this emphasises that the ATOCO work has to progess in a manner
> that works in a complementary fashion to other mechanisms already in
> deployment, and which in certain scenarios may be the only reliable
> mechanism of delivering the alert, and not just assume from its charter
> that the mechanism it provides when it is finished is the only fish in the
> pond.
>
> regards
>
> Keith
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Friday, April 09, 2010 6:53 PM
>> To: MUSGROVE, CHARLES P (ATTCINW)
>> Cc: [email-masked]; [email-masked];
>> DALY, BRIAN K (ATTCINW); DOLLY, MARTIN C (ATTLABS)
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>> As I was thinking - there are multiple levels of
>> standardization work going on in Europe. The OGC community is
>> dealing at the application level
>> - not the infrastructure level.
>>
>> Thanks!
>>
>> Carl
>> > Europe is looking at a warning system based on the 3GPP
>> Public Warning
>> > System (PWS) based on cell broadcast. They are studying the
>> US-based
>> > CMAS as a model for their PWS with a long-term goal of
>> supporting PWS
>> > for international roamers (among European countries as well
>> as to/from
>> > US/Asia/elsewhere). The Netherlands is already moving toward
>> > implementation of a cell broadcast-based system.
>> >
>> > Regards,
>> > Peter Musgrove
>> >
>> > -----Original Message-----
>> > From: [email-masked]
>> > [mailto:[email-masked]]
>> > On Behalf Of [email-masked]
>> > Sent: Friday, April 09, 2010 9:09 AM
>> > To: DALY, BRIAN K (ATTCINW)
>> > Cc: DOLLY, MARTIN C (ATTLABS); [email-masked];
>> > [email-masked]
>> > Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> >
>> > In Europe they are working toward a Pan-European alerting
>> and warning
>> > infrastructure with full interoperability. However, I am
>> not sure at
>> > what level in the "stack" this work is being done - perhaps more at
>> > the higher levels in the application arena. I do not see
>> discussions
>> > on L2 or CMAS or whatever. The European programs are
>> initially being
>> > funded as part of the FP 6 and 7 initiatives. Check out ORCHESTRA
>> > (http://www.eu-orchestra.org/), GMES/SAFER
>> >
>> (http://www.emergencyresponse.eu/site/FO/scripts/myFO_accueil.php?lang
>> > =EN) and SANY (http://www.sany-ip.eu/). SANY is interesting because
>> > the focus is on integrating sensor alerts into a modeling, warning,
>> > and alerting infrastructure.
>> >
>> > Similar activities are occurring in Asia, such as Debris Flow
>> > Monitoring and Alerting in Taiwan, Tsunami Alerting in
>> Indonesia, and
>> > earthquake warning in Japan.
>> >
>> > Regards
>> >
>> > Carl
>> >
>> >
>> >
>> >
>> >
>> >> Brian -
>> >>
>> >> If "no one" is asking for interoperability (and I am not
>> sure who "no
>> >> one"
>> >> is :-) ) then I agree this can be a somewhat peaceful
>> co-existence of
>> >> mandated services (CMAS, EAS, iPAWS, DMOpen vs a market driven
>> >> service that is not and will not be designed with the intention to
>> >> integrate into or interoperate with services such as CMAS.
>> >>
>> >> However, because of the potential for confusion by the reader and
>> >> regulators, all we are asking is that the charter clearly
>> state this
>> >> fact that apparently we are in agreement on.
>> >>
>> >> Can we craft some language for the charter that emphasizes this?
>> >>
>> >> Brian D.
>> >>
>> >> -----Original Message-----
>> >> From: [email-masked]
>> >> [mailto:[email-masked]]
>> >> On Behalf Of Brian Rosen
>> >> Sent: Thursday, April 08, 2010 6:34 AM
>> >> To: Padma Valluri
>> >> Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
>> >> [email-masked]; DOLLY, MARTIN C (ATTLABS)
>> >> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> >>
>> >> Because it¹s pretty hard to define ³interoperability² with L2
>> >> mechanisms that deliver alerts.  One of the biggest
>> problems I have
>> >> with most existing
>> >> L2 specific mechanisms is that they assume they are the only way
>> >> alerts are received. As a result, if you get an alert from
>> some other
>> >> mechanism, you have no idea if its the same alert or a
>> different one.
>> >> Your UI can't help you at all with this.  One of the
>> things I think
>> >> we need is some ID mechanism which is protocol agnostic and simply
>> >> serves as the way to know if you got an alert from
>> multiple sources
>> >> that they are the same alert.
>> >>
>> >> Actually, no one is asking for interoperability.  They are
>> discussing
>> >> various forms of peaceful co-existence.  Designing the protocol to
>> >> take advantage of some kinds of L2 packet delivery
>> mechanisms may be
>> >> possible however.
>> >>
>> >> Brian
>> >>
>> >>
>> >> On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:
>> >>
>> >>>
>> >>> I'm not sure what "use" means here other than to imply
>> >>> interoperable/interworking with existing capabilities
>> that are more
>> >>> efficient in certain segments of the network and deployed
>> already.
>> >>> Why can't we be up front about making the interoperabilty
>> as one of
>> >>> the main requirements of this charter to provide an end-to-end
>> >>> solution?
>> >>>
>> >>> thanks,
>> >>> Padma .
>> >>>
>> >>>
>> >>> From: Brian Rosen <[email-masked]>
>> >>> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A
>> (ATTCINW)"
>> >>> <[email-masked]>
>> >>> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)"
>> >>> <[email-masked]>
>> >>> Date: 04/07/2010 05:55 PM
>> >>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> I'm not bothered by the first part.  I don't like the
>> last phrase,
>> >>> because I'm not sure we should specifically describe such
>> >>> capabilities, and it may not be a gateway.  How about
>> changing the
>> >>> last sentence to "A goal of the work will be to be able to use
>> >>> layer-2 specific mechanisms, where available, to minimize load on
>> >>> the network."
>> >>>
>> >>>
>> >>> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>> >>>
>> >>>> Ok, I can grant that that's something that's not clearly
>> explained
>> >>>> in the current charter.  However, it's also an issue
>> that will tend
>> >>>> to be
>> >>>> layer-2 specific.  How about something like this:
>> >>>>
>> >>>> "
>> >>>> Emergency alerts that are delivered to large numbers of
>> endpoints
>> >>>> can put a large load on the network, particularly when many
>> >>>> affected users are on the same local network (e.g., the 100,000
>> >>>> attendees at a sporting event).  This working group will
>> consider
>> >>>> mechanisms for minimizing this load, such as IP multicast.  In
>> >>>> particular, some approaches have been developed to
>> handle emergency
>> >>>> alerting in different types networks, and it will be a
>> goal of this
>> >>>> working group to facilitate interoperability with these
>> approaches,
>> >>>> for example, to enable gateways to relay messages from this
>> >>>> Internet mechanism into a specific layer-2 channel.
>> >>>> "
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>> >>>>
>> >>>>> It is deficient because it does not take into account
>> the impacts
>> >>>>> that will occur to the various access technologies.  All access
>> >>>>> technologies do not have the same capacity, bandwidth, etc.
>> >>>>> Therefore any design that has the potential to send
>> information to
>> >>>>> all citizens within an area via any variety of access
>> technologies
>> >>>>> needs to consider these factors.
>> >>>>> For
>> >>>>> example, consider the scenario of trying to send an
>> alert to the
>> >>>>> 100,000 fans at a college football game.
>> >>>>>
>> >>>>> The current draft charter of ATOCA does not address
>> this which is
>> >>>>> why the additional sentences for the second paragraph
>> were proposed.
>> >>>>>
>> >>>>> DeWayne
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Richard Barnes [mailto:[email-masked]
>> >>>>> <mailto:[email-masked]> ]
>> >>>>> Sent: Wednesday, April 07, 2010 1:38 PM
>> >>>>> To: SENNETT, DEWAYNE A (ATTCINW)
>> >>>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne;
>> DOLLY, MARTIN C
>> >>>>> (ATTLABS); [email-masked]
>> >>>>> Subject: Re: [earlywarning] Finishing the Charter Text
>> Discussions
>> >>>>>
>> >>>>> Could you please clarify how you believe it to be deficient?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>> >>>>>
>> >>>>>> My "personal" view is that the charter as currently written is
>> >>>>>> not correct or adequate.
>> >>>>>>
>> >>>>>> DeWayne
>> >>>>>>
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: [email-masked]
>> >>>>>> [mailto:[email-masked]
>> >>>>>> <mailto:[email-masked]> ] On Behalf Of
>> DALY, BRIAN
>> >>>>>> K
>> >>>>>> (ATTCINW)
>> >>>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>> >>>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>> >>>>>> Cc: [email-masked]
>> >>>>>> Subject: Re: [earlywarning] Finishing the Charter Text
>> >>>>>> Discussions
>> >>>>>>
>> >>>>>> Fine but my "personal" view does not change.
>> >>>>>>
>> >>>>>> Brian Daly
>> >>>>>>
>> >>>>>>
>> >>>>>> -----Original Message-----
>> >>>>>> From: Henning Schulzrinne [mailto:[email-masked]
>> >>>>>> <mailto:[email-masked]> ]
>> >>>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>> >>>>>> To: DOLLY, MARTIN C (ATTLABS)
>> >>>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>> >>>>>> Subject: Re: [earlywarning] Finishing the Charter Text
>> >>>>>> Discussions
>> >>>>>>
>> >>>>>> The point is that people speak as individuals in the IETF and
>> >>>>>> there is no particular notion that a corporate opinion has any
>> >>>>>> more weight than that of any individual. Thus, stating a
>> >>>>>> corporate opinion is out of place and against IETF custom and
>> >>>>>> convention.
>> >>>>>>
>> >>>>>>
>> >>>>>> Henning
>> >>>>>>
>> >>>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>> >>>>>>
>> >>>>>>> They sure do, look at everyone's badge
>> >>>>>>>
>> >>>>>>> ----- Original Message -----
>> >>>>>>> From: [email-masked]
>> >>>>>>> <[email-masked]>
>> >>>>>>> To: DALY, BRIAN K (ATTCINW)
>> >>>>>>> Cc: [email-masked] <[email-masked]>
>> >>>>>>> Sent: Wed Apr 07 16:21:20 2010
>> >>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text
>> >>>>>>> Discussions
>> >>>>>>>
>> >>>>>>> I didn't know that the IETF had corporate opinions. But maybe
>> >>>>>>> the IETF
>> >>>>>> rules have changed recently?
>> >>>>>>>
>> >>>>>>> Henning
>> >>>>>>>
>> >>>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>> >>>>>>>
>> >>>>>>>> For the record, AT&T is in opposition to removing the last
>> >>>>>>>> sentence.
>> >>>>>>>>
>> >>>>>>>> Brian Daly
>> >>>>>>>> AT&T
>> >>>>>>>
>> >>>>>>> _______________________________________________
>> >>>>>>> earlywarning mailing list
>> >>>>>>> [email-masked]
>> >>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> >>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> earlywarning mailing list
>> >>>>>> [email-masked]
>> >>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> >>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>> >>>>>> _______________________________________________
>> >>>>>> earlywarning mailing list
>> >>>>>> [email-masked]
>> >>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> >>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> earlywarning mailing list
>> >>>> [email-masked]
>> >>>> https://www.ietf.org/mailman/listinfo/earlywarning
>> >>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> earlywarning mailing list
>> >>> [email-masked]
>> >>> https://www.ietf.org/mailman/listinfo/earlywarning
>> >>> <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
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > 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: "DRAGE, Keith (Keith)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "MUSGROVE, CHARLES P (ATTCINW)" <[email-masked]>
Date: Fri, 9 Apr 2010 22:07:56 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "DALY, BRIAN K \(ATTCINW\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Carl, I think the problem is that your statement: "I do not see discussions=
 on L2 or CMAS or whatever", implies on first reading that there are none, =
rather than you are not aware of them.

Indeed there are activities taking place on trialing cell broadcast for suc=
h alerts, and at least the intent I was seeing from the people involved in =
this was that they would be looking to activities in ETSI to channel this w=
ork into 3GPP, and that they would be using the CMAS work as a starting poi=
nt. One key problem to solve is that in multilingual countries, the alert w=
ould have to be delivered in multiple languages - not a problem except proc=
edures need to be defined to cycle round such messages, which does not exis=
t in CMAS at the moment. I also gathered some clear statements that they wa=
nted a solution independent of any work that took place elsewhere on other =
infrastructures.

So to me this emphasises that the ATOCO work has to progess in a manner tha=
t works in a complementary fashion to other mechanisms already in deploymen=
t, and which in certain scenarios may be the only reliable mechanism of del=
ivering the alert, and not just assume from its charter that the mechanism =
it provides when it is finished is the only fish in the pond.

regards

Keith

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Friday, April 09, 2010 6:53 PM
> To: MUSGROVE, CHARLES P (ATTCINW)
> Cc: [email-masked]; [email-masked];=20
> DALY, BRIAN K (ATTCINW); DOLLY, MARTIN C (ATTLABS)
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
> As I was thinking - there are multiple levels of=20
> standardization work going on in Europe. The OGC community is=20
> dealing at the application level
> - not the infrastructure level.
>=20
> Thanks!
>=20
> Carl
> > Europe is looking at a warning system based on the 3GPP=20
> Public Warning=20
> > System (PWS) based on cell broadcast. They are studying the=20
> US-based=20
> > CMAS as a model for their PWS with a long-term goal of=20
> supporting PWS=20
> > for international roamers (among European countries as well=20
> as to/from=20
> > US/Asia/elsewhere). The Netherlands is already moving toward=20
> > implementation of a cell broadcast-based system.
> >
> > Regards,
> > Peter Musgrove
> >
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]]
> > On Behalf Of [email-masked]
> > Sent: Friday, April 09, 2010 9:09 AM
> > To: DALY, BRIAN K (ATTCINW)
> > Cc: DOLLY, MARTIN C (ATTLABS); [email-masked];=20
> > [email-masked]
> > Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> >
> > In Europe they are working toward a Pan-European alerting=20
> and warning=20
> > infrastructure with full interoperability. However, I am=20
> not sure at=20
> > what level in the "stack" this work is being done - perhaps more at=20
> > the higher levels in the application arena. I do not see=20
> discussions=20
> > on L2 or CMAS or whatever. The European programs are=20
> initially being=20
> > funded as part of the FP 6 and 7 initiatives. Check out ORCHESTRA=20
> > (http://www.eu-orchestra.org/), GMES/SAFER
> >=20
> (http://www.emergencyresponse.eu/site/FO/scripts/myFO_accueil.php?lang
> > =3DEN) and SANY (http://www.sany-ip.eu/). SANY is interesting because=20
> > the focus is on integrating sensor alerts into a modeling, warning,=20
> > and alerting infrastructure.
> >
> > Similar activities are occurring in Asia, such as Debris Flow=20
> > Monitoring and Alerting in Taiwan, Tsunami Alerting in=20
> Indonesia, and=20
> > earthquake warning in Japan.
> >
> > Regards
> >
> > Carl
> >
> >
> >
> >
> >
> >> Brian -
> >>
> >> If "no one" is asking for interoperability (and I am not=20
> sure who "no=20
> >> one"
> >> is :-) ) then I agree this can be a somewhat peaceful=20
> co-existence of=20
> >> mandated services (CMAS, EAS, iPAWS, DMOpen vs a market driven=20
> >> service that is not and will not be designed with the intention to=20
> >> integrate into or interoperate with services such as CMAS.
> >>
> >> However, because of the potential for confusion by the reader and=20
> >> regulators, all we are asking is that the charter clearly=20
> state this=20
> >> fact that apparently we are in agreement on.
> >>
> >> Can we craft some language for the charter that emphasizes this?
> >>
> >> Brian D.
> >>
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]]
> >> On Behalf Of Brian Rosen
> >> Sent: Thursday, April 08, 2010 6:34 AM
> >> To: Padma Valluri
> >> Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);=20
> >> [email-masked]; DOLLY, MARTIN C (ATTLABS)
> >> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> >>
> >> Because it=B9s pretty hard to define =B3interoperability=B2 with L2=20
> >> mechanisms that deliver alerts.  One of the biggest=20
> problems I have=20
> >> with most existing
> >> L2 specific mechanisms is that they assume they are the only way=20
> >> alerts are received. As a result, if you get an alert from=20
> some other=20
> >> mechanism, you have no idea if its the same alert or a=20
> different one. =20
> >> Your UI can't help you at all with this.  One of the=20
> things I think=20
> >> we need is some ID mechanism which is protocol agnostic and simply=20
> >> serves as the way to know if you got an alert from=20
> multiple sources=20
> >> that they are the same alert.
> >>
> >> Actually, no one is asking for interoperability.  They are=20
> discussing=20
> >> various forms of peaceful co-existence.  Designing the protocol to=20
> >> take advantage of some kinds of L2 packet delivery=20
> mechanisms may be=20
> >> possible however.
> >>
> >> Brian
> >>
> >>
> >> On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:
> >>
> >>>
> >>> I'm not sure what "use" means here other than to imply=20
> >>> interoperable/interworking with existing capabilities=20
> that are more=20
> >>> efficient in certain segments of the network and deployed=20
> already.=20
> >>> Why can't we be up front about making the interoperabilty=20
> as one of=20
> >>> the main requirements of this charter to provide an end-to-end=20
> >>> solution?
> >>>
> >>> thanks,
> >>> Padma .
> >>>
> >>>
> >>> From: Brian Rosen <[email-masked]>
> >>> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A=20
> (ATTCINW)"
> >>> <[email-masked]>
> >>> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)"
> >>> <[email-masked]>
> >>> Date: 04/07/2010 05:55 PM
> >>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> >>>
> >>>
> >>>
> >>>
> >>> I'm not bothered by the first part.  I don't like the=20
> last phrase,=20
> >>> because I'm not sure we should specifically describe such=20
> >>> capabilities, and it may not be a gateway.  How about=20
> changing the=20
> >>> last sentence to "A goal of the work will be to be able to use=20
> >>> layer-2 specific mechanisms, where available, to minimize load on=20
> >>> the network."
> >>>
> >>>
> >>> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
> >>>
> >>>> Ok, I can grant that that's something that's not clearly=20
> explained=20
> >>>> in the current charter.  However, it's also an issue=20
> that will tend=20
> >>>> to be
> >>>> layer-2 specific.  How about something like this:
> >>>>
> >>>> "
> >>>> Emergency alerts that are delivered to large numbers of=20
> endpoints=20
> >>>> can put a large load on the network, particularly when many=20
> >>>> affected users are on the same local network (e.g., the 100,000=20
> >>>> attendees at a sporting event).  This working group will=20
> consider=20
> >>>> mechanisms for minimizing this load, such as IP multicast.  In=20
> >>>> particular, some approaches have been developed to=20
> handle emergency=20
> >>>> alerting in different types networks, and it will be a=20
> goal of this=20
> >>>> working group to facilitate interoperability with these=20
> approaches,=20
> >>>> for example, to enable gateways to relay messages from this=20
> >>>> Internet mechanism into a specific layer-2 channel.
> >>>> "
> >>>>
> >>>>
> >>>>
> >>>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> >>>>
> >>>>> It is deficient because it does not take into account=20
> the impacts=20
> >>>>> that will occur to the various access technologies.  All access=20
> >>>>> technologies do not have the same capacity, bandwidth, etc.=20
> >>>>> Therefore any design that has the potential to send=20
> information to=20
> >>>>> all citizens within an area via any variety of access=20
> technologies=20
> >>>>> needs to consider these factors.
> >>>>> For
> >>>>> example, consider the scenario of trying to send an=20
> alert to the=20
> >>>>> 100,000 fans at a college football game.
> >>>>>
> >>>>> The current draft charter of ATOCA does not address=20
> this which is=20
> >>>>> why the additional sentences for the second paragraph=20
> were proposed.
> >>>>>
> >>>>> DeWayne
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Richard Barnes [mailto:[email-masked]=20
> >>>>> <mailto:[email-masked]> ]
> >>>>> Sent: Wednesday, April 07, 2010 1:38 PM
> >>>>> To: SENNETT, DEWAYNE A (ATTCINW)
> >>>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne;=20
> DOLLY, MARTIN C=20
> >>>>> (ATTLABS); [email-masked]
> >>>>> Subject: Re: [earlywarning] Finishing the Charter Text=20
> Discussions
> >>>>>
> >>>>> Could you please clarify how you believe it to be deficient?
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> >>>>>
> >>>>>> My "personal" view is that the charter as currently written is=20
> >>>>>> not correct or adequate.
> >>>>>>
> >>>>>> DeWayne
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: [email-masked]=20
> >>>>>> [mailto:[email-masked]
> >>>>>> <mailto:[email-masked]> ] On Behalf Of=20
> DALY, BRIAN=20
> >>>>>> K
> >>>>>> (ATTCINW)
> >>>>>> Sent: Wednesday, April 07, 2010 1:33 PM
> >>>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
> >>>>>> Cc: [email-masked]
> >>>>>> Subject: Re: [earlywarning] Finishing the Charter Text=20
> >>>>>> Discussions
> >>>>>>
> >>>>>> Fine but my "personal" view does not change.
> >>>>>>
> >>>>>> Brian Daly
> >>>>>>
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Henning Schulzrinne [mailto:[email-masked]=20
> >>>>>> <mailto:[email-masked]> ]
> >>>>>> Sent: Wednesday, April 07, 2010 1:31 PM
> >>>>>> To: DOLLY, MARTIN C (ATTLABS)
> >>>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
> >>>>>> Subject: Re: [earlywarning] Finishing the Charter Text=20
> >>>>>> Discussions
> >>>>>>
> >>>>>> The point is that people speak as individuals in the IETF and=20
> >>>>>> there is no particular notion that a corporate opinion has any=20
> >>>>>> more weight than that of any individual. Thus, stating a=20
> >>>>>> corporate opinion is out of place and against IETF custom and=20
> >>>>>> convention.
> >>>>>>
> >>>>>>
> >>>>>> Henning
> >>>>>>
> >>>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
> >>>>>>
> >>>>>>> They sure do, look at everyone's badge
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>> From: [email-masked]=20
> >>>>>>> <[email-masked]>
> >>>>>>> To: DALY, BRIAN K (ATTCINW)
> >>>>>>> Cc: [email-masked] <[email-masked]>
> >>>>>>> Sent: Wed Apr 07 16:21:20 2010
> >>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text=20
> >>>>>>> Discussions
> >>>>>>>
> >>>>>>> I didn't know that the IETF had corporate opinions. But maybe=20
> >>>>>>> the IETF
> >>>>>> rules have changed recently?
> >>>>>>>
> >>>>>>> Henning
> >>>>>>>
> >>>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
> >>>>>>>
> >>>>>>>> For the record, AT&T is in opposition to removing the last=20
> >>>>>>>> sentence.
> >>>>>>>>
> >>>>>>>> Brian Daly
> >>>>>>>> AT&T
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> earlywarning mailing list
> >>>>>>> [email-masked]
> >>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> earlywarning mailing list
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
> >>>>>> _______________________________________________
> >>>>>> earlywarning mailing list
> >>>>>> [email-masked]
> >>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> earlywarning mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
> >>>
> >>>
> >>> _______________________________________________
> >>> earlywarning mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/earlywarning
> >>> <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
> >>
> >>
> >
> >
> > _______________________________________________
> > earlywarning mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/earlywarning
> >
> >
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> =

Date: Fri, 9 Apr 2010 13:53:18 -0400 (EDT)
From: [email-masked]
To: "MUSGROVE, CHARLES P (ATTCINW)" <[email-masked]>
Importance: Normal
Cc: [email-masked], [email-masked], "DALY, BRIAN K \(ATTCINW\)" <[email-masked]>, "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

As I was thinking - there are multiple levels of standardization work
going on in Europe. The OGC community is dealing at the application level
- not the infrastructure level.

Thanks!

Carl
> Europe is looking at a warning system based on the 3GPP Public Warning
> System (PWS) based on cell broadcast. They are studying the US-based CMAS
> as a model for their PWS with a long-term goal of supporting PWS for
> international roamers (among European countries as well as to/from
> US/Asia/elsewhere). The Netherlands is already moving toward
> implementation of a cell broadcast-based system.
>
> Regards,
> Peter Musgrove
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Friday, April 09, 2010 9:09 AM
> To: DALY, BRIAN K (ATTCINW)
> Cc: DOLLY, MARTIN C (ATTLABS); [email-masked];
> [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> In Europe they are working toward a Pan-European alerting and warning
> infrastructure with full interoperability. However, I am not sure at what
> level in the "stack" this work is being done - perhaps more at the higher
> levels in the application arena. I do not see discussions on L2 or CMAS or
> whatever. The European programs are initially being funded as part of the
> FP 6 and 7 initiatives. Check out ORCHESTRA
> (http://www.eu-orchestra.org/), GMES/SAFER
> (http://www.emergencyresponse.eu/site/FO/scripts/myFO_accueil.php?lang=EN)
> and SANY (http://www.sany-ip.eu/). SANY is interesting because the focus
> is on integrating sensor alerts into a modeling, warning, and alerting
> infrastructure.
>
> Similar activities are occurring in Asia, such as Debris Flow Monitoring
> and Alerting in Taiwan, Tsunami Alerting in Indonesia, and earthquake
> warning in Japan.
>
> Regards
>
> Carl
>
>
>
>
>
>> Brian -
>>
>> If "no one" is asking for interoperability (and I am not sure who "no
>> one"
>> is :-) ) then I agree this can be a somewhat peaceful co-existence of
>> mandated services (CMAS, EAS, iPAWS, DMOpen vs a market driven service
>> that is not and will not be designed with the intention to integrate
>> into
>> or interoperate with services such as CMAS.
>>
>> However, because of the potential for confusion by the reader and
>> regulators, all we are asking is that the charter clearly state this
>> fact
>> that apparently we are in agreement on.
>>
>> Can we craft some language for the charter that emphasizes this?
>>
>> Brian D.
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]
>> On Behalf Of Brian Rosen
>> Sent: Thursday, April 08, 2010 6:34 AM
>> To: Padma Valluri
>> Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
>> [email-masked]; DOLLY, MARTIN C (ATTLABS)
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>> Because it¹s pretty hard to define ³interoperability² with L2 mechanisms
>> that deliver alerts.  One of the biggest problems I have with most
>> existing
>> L2 specific mechanisms is that they assume they are the only way alerts
>> are
>> received. As a result, if you get an alert from some other mechanism,
>> you
>> have no idea if its the same alert or a different one.  Your UI can't
>> help
>> you at all with this.  One of the things I think we need is some ID
>> mechanism which is protocol agnostic and simply serves as the way to
>> know
>> if
>> you got an alert from multiple sources that they are the same alert.
>>
>> Actually, no one is asking for interoperability.  They are discussing
>> various forms of peaceful co-existence.  Designing the protocol to take
>> advantage of some kinds of L2 packet delivery mechanisms may be possible
>> however.
>>
>> Brian
>>
>>
>> On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:
>>
>>>
>>> I'm not sure what "use" means here other than to imply
>>> interoperable/interworking with existing capabilities that are more
>>> efficient
>>> in certain segments of the network and deployed already. Why can't we
>>> be
>>> up
>>> front about making the interoperabilty as one of the main requirements
>>> of this
>>> charter to provide an end-to-end solution?
>>>
>>> thanks,
>>> Padma .
>>>
>>>
>>> From: Brian Rosen <[email-masked]>
>>> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)"
>>> <[email-masked]>
>>> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)"
>>> <[email-masked]>
>>> Date: 04/07/2010 05:55 PM
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>
>>>
>>>
>>>
>>> I'm not bothered by the first part.  I don't like the last phrase,
>>> because
>>> I'm not sure we should specifically describe such capabilities, and it
>>> may
>>> not be a gateway.  How about changing the last sentence to "A goal of
>>> the
>>> work will be to be able to use layer-2 specific mechanisms, where
>>> available,
>>> to minimize load on the network."
>>>
>>>
>>> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>>>
>>>> Ok, I can grant that that's something that's not clearly explained in
>>>> the current charter.  However, it's also an issue that will tend to be
>>>> layer-2 specific.  How about something like this:
>>>>
>>>> "
>>>> Emergency alerts that are delivered to large numbers of endpoints can
>>>> put a large load on the network, particularly when many affected users
>>>> are on the same local network (e.g., the 100,000 attendees at a
>>>> sporting event).  This working group will consider mechanisms for
>>>> minimizing this load, such as IP multicast.  In particular, some
>>>> approaches have been developed to handle emergency alerting in
>>>> different types networks, and it will be a goal of this working group
>>>> to facilitate interoperability with these approaches, for example, to
>>>> enable gateways to relay messages from this Internet mechanism into a
>>>> specific layer-2 channel.
>>>> "
>>>>
>>>>
>>>>
>>>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>>
>>>>> It is deficient because it does not take into account the impacts
>>>>> that
>>>>> will occur to the various access technologies.  All access
>>>>> technologies
>>>>> do not have the same capacity, bandwidth, etc. Therefore any design
>>>>> that
>>>>> has the potential to send information to all citizens within an area
>>>>> via
>>>>> any variety of access technologies needs to consider these factors.
>>>>> For
>>>>> example, consider the scenario of trying to send an alert to the
>>>>> 100,000
>>>>> fans at a college football game.
>>>>>
>>>>> The current draft charter of ATOCA does not address this which is why
>>>>> the additional sentences for the second paragraph were proposed.
>>>>>
>>>>> DeWayne
>>>>>
>>>>> -----Original Message-----
>>>>> From: Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>
>>>>> ]
>>>>> Sent: Wednesday, April 07, 2010 1:38 PM
>>>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>>>>> (ATTLABS); [email-masked]
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>
>>>>> Could you please clarify how you believe it to be deficient?
>>>>>
>>>>>
>>>>>
>>>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>>>
>>>>>> My "personal" view is that the charter as currently written is not
>>>>>> correct or adequate.
>>>>>>
>>>>>> DeWayne
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked]
>>>>>> [mailto:[email-masked]
>>>>>> <mailto:[email-masked]> ] On Behalf Of DALY, BRIAN K
>>>>>> (ATTCINW)
>>>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>>>>> Cc: [email-masked]
>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>>
>>>>>> Fine but my "personal" view does not change.
>>>>>>
>>>>>> Brian Daly
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Henning Schulzrinne [mailto:[email-masked]
>>>>>> <mailto:[email-masked]> ]
>>>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>>>>> To: DOLLY, MARTIN C (ATTLABS)
>>>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>>
>>>>>> The point is that people speak as individuals in the IETF and there
>>>>>> is
>>>>>> no particular notion that a corporate opinion has any more weight
>>>>>> than
>>>>>> that of any individual. Thus, stating a corporate opinion is out of
>>>>>> place and against IETF custom and convention.
>>>>>>
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>>>>>
>>>>>>> They sure do, look at everyone's badge
>>>>>>>
>>>>>>> ----- Original Message -----
>>>>>>> From: [email-masked] <[email-masked]>
>>>>>>> To: DALY, BRIAN K (ATTCINW)
>>>>>>> Cc: [email-masked] <[email-masked]>
>>>>>>> Sent: Wed Apr 07 16:21:20 2010
>>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>>>
>>>>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>>>>> IETF
>>>>>> rules have changed recently?
>>>>>>>
>>>>>>> Henning
>>>>>>>
>>>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>>>>>
>>>>>>>> For the record, AT&T is in opposition to removing the last
>>>>>>>> sentence.
>>>>>>>>
>>>>>>>> Brian Daly
>>>>>>>> AT&T
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> earlywarning mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>>>
>>>>>> _______________________________________________
>>>>>> earlywarning mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>>> _______________________________________________
>>>>>> earlywarning mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>>
>>>>
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>> <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
>>
>>
>
>
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>
>

Content-class: urn:content-classes:message
Date: Fri, 9 Apr 2010 10:43:04 -0700
From: "MUSGROVE, CHARLES P (ATTCINW)" <[email-masked]>
To: <[email-masked]>, "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked], [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Europe is looking at a warning system based on the 3GPP Public Warning =
System (PWS) based on cell broadcast. They are studying the US-based =
CMAS as a model for their PWS with a long-term goal of supporting PWS =
for international roamers (among European countries as well as to/from =
US/Asia/elsewhere). The Netherlands is already moving toward =
implementation of a cell broadcast-based system.

Regards,
Peter Musgrove

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]] On Behalf Of =
[email-masked]
Sent: Friday, April 09, 2010 9:09 AM
To: DALY, BRIAN K (ATTCINW)
Cc: DOLLY, MARTIN C (ATTLABS); [email-masked]; =
[email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

In Europe they are working toward a Pan-European alerting and warning
infrastructure with full interoperability. However, I am not sure at =
what
level in the "stack" this work is being done - perhaps more at the =
higher
levels in the application arena. I do not see discussions on L2 or CMAS =
or
whatever. The European programs are initially being funded as part of =
the
FP 6 and 7 initiatives. Check out ORCHESTRA
(http://www.eu-orchestra.org/), GMES/SAFER
(http://www.emergencyresponse.eu/site/FO/scripts/myFO_accueil.php?lang=3D=
EN)
and SANY (http://www.sany-ip.eu/). SANY is interesting because the focus
is on integrating sensor alerts into a modeling, warning, and alerting
infrastructure.

Similar activities are occurring in Asia, such as Debris Flow Monitoring
and Alerting in Taiwan, Tsunami Alerting in Indonesia, and earthquake
warning in Japan.

Regards

Carl

> Brian -
>
> If "no one" is asking for interoperability (and I am not sure who "no =
one"
> is :-) ) then I agree this can be a somewhat peaceful co-existence of
> mandated services (CMAS, EAS, iPAWS, DMOpen vs a market driven service
> that is not and will not be designed with the intention to integrate =
into
> or interoperate with services such as CMAS.
>
> However, because of the potential for confusion by the reader and
> regulators, all we are asking is that the charter clearly state this =
fact
> that apparently we are in agreement on.
>
> Can we craft some language for the charter that emphasizes this?
>
> Brian D.
>
> -----Original Message-----
> From: [email-masked] =
[mailto:[email-masked]]
> On Behalf Of Brian Rosen
> Sent: Thursday, April 08, 2010 6:34 AM
> To: Padma Valluri
> Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
> [email-masked]; DOLLY, MARTIN C (ATTLABS)
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> Because it=B9s pretty hard to define =B3interoperability=B2 with L2 =
mechanisms
> that deliver alerts.  One of the biggest problems I have with most
> existing
> L2 specific mechanisms is that they assume they are the only way =
alerts
> are
> received. As a result, if you get an alert from some other mechanism, =
you
> have no idea if its the same alert or a different one.  Your UI can't =
help
> you at all with this.  One of the things I think we need is some ID
> mechanism which is protocol agnostic and simply serves as the way to =
know
> if
> you got an alert from multiple sources that they are the same alert.
>
> Actually, no one is asking for interoperability.  They are discussing
> various forms of peaceful co-existence.  Designing the protocol to =
take
> advantage of some kinds of L2 packet delivery mechanisms may be =
possible
> however.
>
> Brian
>
>
> On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:
>
>>
>> I'm not sure what "use" means here other than to imply
>> interoperable/interworking with existing capabilities that are more
>> efficient
>> in certain segments of the network and deployed already. Why can't we =
be
>> up
>> front about making the interoperabilty as one of the main =
requirements
>> of this
>> charter to provide an end-to-end solution?
>>
>> thanks,
>> Padma .
>>
>>
>> From: Brian Rosen <[email-masked]>
>> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)"
>> <[email-masked]>
>> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)"
>> <[email-masked]>
>> Date: 04/07/2010 05:55 PM
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>>
>>
>>
>> I'm not bothered by the first part.  I don't like the last phrase,
>> because
>> I'm not sure we should specifically describe such capabilities, and =
it
>> may
>> not be a gateway.  How about changing the last sentence to "A goal of
>> the
>> work will be to be able to use layer-2 specific mechanisms, where
>> available,
>> to minimize load on the network."
>>
>>
>> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>>
>>> Ok, I can grant that that's something that's not clearly explained =
in
>>> the current charter.  However, it's also an issue that will tend to =
be
>>> layer-2 specific.  How about something like this:
>>>
>>> "
>>> Emergency alerts that are delivered to large numbers of endpoints =
can
>>> put a large load on the network, particularly when many affected =
users
>>> are on the same local network (e.g., the 100,000 attendees at a
>>> sporting event).  This working group will consider mechanisms for
>>> minimizing this load, such as IP multicast.  In particular, some
>>> approaches have been developed to handle emergency alerting in
>>> different types networks, and it will be a goal of this working =
group
>>> to facilitate interoperability with these approaches, for example, =
to
>>> enable gateways to relay messages from this Internet mechanism into =
a
>>> specific layer-2 channel.
>>> "
>>>
>>>
>>>
>>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>
>>>> It is deficient because it does not take into account the impacts =
that
>>>> will occur to the various access technologies.  All access
>>>> technologies
>>>> do not have the same capacity, bandwidth, etc. Therefore any design
>>>> that
>>>> has the potential to send information to all citizens within an =
area
>>>> via
>>>> any variety of access technologies needs to consider these factors.
>>>> For
>>>> example, consider the scenario of trying to send an alert to the
>>>> 100,000
>>>> fans at a college football game.
>>>>
>>>> The current draft charter of ATOCA does not address this which is =
why
>>>> the additional sentences for the second paragraph were proposed.
>>>>
>>>> DeWayne
>>>>
>>>> -----Original Message-----
>>>> From: Richard Barnes [mailto:[email-masked] =
<mailto:[email-masked]>
>>>> ]
>>>> Sent: Wednesday, April 07, 2010 1:38 PM
>>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>>>> (ATTLABS); [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>
>>>> Could you please clarify how you believe it to be deficient?
>>>>
>>>>
>>>>
>>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>>
>>>>> My "personal" view is that the charter as currently written is not
>>>>> correct or adequate.
>>>>>
>>>>> DeWayne
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]
>>>>> <mailto:[email-masked]> ] On Behalf Of DALY, BRIAN =
K
>>>>> (ATTCINW)
>>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>
>>>>> Fine but my "personal" view does not change.
>>>>>
>>>>> Brian Daly
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Henning Schulzrinne [mailto:[email-masked]
>>>>> <mailto:[email-masked]> ]
>>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>>>> To: DOLLY, MARTIN C (ATTLABS)
>>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>
>>>>> The point is that people speak as individuals in the IETF and =
there
>>>>> is
>>>>> no particular notion that a corporate opinion has any more weight
>>>>> than
>>>>> that of any individual. Thus, stating a corporate opinion is out =
of
>>>>> place and against IETF custom and convention.
>>>>>
>>>>>
>>>>> Henning
>>>>>
>>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>>>>
>>>>>> They sure do, look at everyone's badge
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: [email-masked] =
<[email-masked]>
>>>>>> To: DALY, BRIAN K (ATTCINW)
>>>>>> Cc: [email-masked] <[email-masked]>
>>>>>> Sent: Wed Apr 07 16:21:20 2010
>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text =
Discussions
>>>>>>
>>>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>>>> IETF
>>>>> rules have changed recently?
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>>>>
>>>>>>> For the record, AT&T is in opposition to removing the last
>>>>>>> sentence.
>>>>>>>
>>>>>>> Brian Daly
>>>>>>> AT&T
>>>>>>
>>>>>> _______________________________________________
>>>>>> earlywarning mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>>
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> <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
>
>

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

Date: Fri, 9 Apr 2010 12:09:24 -0400 (EDT)
From: [email-masked]
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Importance: Normal
Cc: "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

In Europe they are working toward a Pan-European alerting and warning
infrastructure with full interoperability. However, I am not sure at what
level in the "stack" this work is being done - perhaps more at the higher
levels in the application arena. I do not see discussions on L2 or CMAS or
whatever. The European programs are initially being funded as part of the
FP 6 and 7 initiatives. Check out ORCHESTRA
(http://www.eu-orchestra.org/), GMES/SAFER
(http://www.emergencyresponse.eu/site/FO/scripts/myFO_accueil.php?lang=EN)
and SANY (http://www.sany-ip.eu/). SANY is interesting because the focus
is on integrating sensor alerts into a modeling, warning, and alerting
infrastructure.

Similar activities are occurring in Asia, such as Debris Flow Monitoring
and Alerting in Taiwan, Tsunami Alerting in Indonesia, and earthquake
warning in Japan.

Regards

Carl

> Brian -
>
> If "no one" is asking for interoperability (and I am not sure who "no one"
> is :-) ) then I agree this can be a somewhat peaceful co-existence of
> mandated services (CMAS, EAS, iPAWS, DMOpen vs a market driven service
> that is not and will not be designed with the intention to integrate into
> or interoperate with services such as CMAS.
>
> However, because of the potential for confusion by the reader and
> regulators, all we are asking is that the charter clearly state this fact
> that apparently we are in agreement on.
>
> Can we craft some language for the charter that emphasizes this?
>
> Brian D.
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Brian Rosen
> Sent: Thursday, April 08, 2010 6:34 AM
> To: Padma Valluri
> Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
> [email-masked]; DOLLY, MARTIN C (ATTLABS)
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> Because it¹s pretty hard to define ³interoperability² with L2 mechanisms
> that deliver alerts.  One of the biggest problems I have with most
> existing
> L2 specific mechanisms is that they assume they are the only way alerts
> are
> received. As a result, if you get an alert from some other mechanism, you
> have no idea if its the same alert or a different one.  Your UI can't help
> you at all with this.  One of the things I think we need is some ID
> mechanism which is protocol agnostic and simply serves as the way to know
> if
> you got an alert from multiple sources that they are the same alert.
>
> Actually, no one is asking for interoperability.  They are discussing
> various forms of peaceful co-existence.  Designing the protocol to take
> advantage of some kinds of L2 packet delivery mechanisms may be possible
> however.
>
> Brian
>
>
> On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:
>
>>
>> I'm not sure what "use" means here other than to imply
>> interoperable/interworking with existing capabilities that are more
>> efficient
>> in certain segments of the network and deployed already. Why can't we be
>> up
>> front about making the interoperabilty as one of the main requirements
>> of this
>> charter to provide an end-to-end solution?
>>
>> thanks,
>> Padma .
>>
>>
>> From: Brian Rosen <[email-masked]>
>> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)"
>> <[email-masked]>
>> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)"
>> <[email-masked]>
>> Date: 04/07/2010 05:55 PM
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>>
>>
>>
>> I'm not bothered by the first part.  I don't like the last phrase,
>> because
>> I'm not sure we should specifically describe such capabilities, and it
>> may
>> not be a gateway.  How about changing the last sentence to "A goal of
>> the
>> work will be to be able to use layer-2 specific mechanisms, where
>> available,
>> to minimize load on the network."
>>
>>
>> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>>
>>> Ok, I can grant that that's something that's not clearly explained in
>>> the current charter.  However, it's also an issue that will tend to be
>>> layer-2 specific.  How about something like this:
>>>
>>> "
>>> Emergency alerts that are delivered to large numbers of endpoints can
>>> put a large load on the network, particularly when many affected users
>>> are on the same local network (e.g., the 100,000 attendees at a
>>> sporting event).  This working group will consider mechanisms for
>>> minimizing this load, such as IP multicast.  In particular, some
>>> approaches have been developed to handle emergency alerting in
>>> different types networks, and it will be a goal of this working group
>>> to facilitate interoperability with these approaches, for example, to
>>> enable gateways to relay messages from this Internet mechanism into a
>>> specific layer-2 channel.
>>> "
>>>
>>>
>>>
>>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>
>>>> It is deficient because it does not take into account the impacts that
>>>> will occur to the various access technologies.  All access
>>>> technologies
>>>> do not have the same capacity, bandwidth, etc. Therefore any design
>>>> that
>>>> has the potential to send information to all citizens within an area
>>>> via
>>>> any variety of access technologies needs to consider these factors.
>>>> For
>>>> example, consider the scenario of trying to send an alert to the
>>>> 100,000
>>>> fans at a college football game.
>>>>
>>>> The current draft charter of ATOCA does not address this which is why
>>>> the additional sentences for the second paragraph were proposed.
>>>>
>>>> DeWayne
>>>>
>>>> -----Original Message-----
>>>> From: Richard Barnes [mailto:[email-masked] <mailto:[email-masked]>
>>>> ]
>>>> Sent: Wednesday, April 07, 2010 1:38 PM
>>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>>>> (ATTLABS); [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>
>>>> Could you please clarify how you believe it to be deficient?
>>>>
>>>>
>>>>
>>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>>
>>>>> My "personal" view is that the charter as currently written is not
>>>>> correct or adequate.
>>>>>
>>>>> DeWayne
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]
>>>>> <mailto:[email-masked]> ] On Behalf Of DALY, BRIAN K
>>>>> (ATTCINW)
>>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>
>>>>> Fine but my "personal" view does not change.
>>>>>
>>>>> Brian Daly
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Henning Schulzrinne [mailto:[email-masked]
>>>>> <mailto:[email-masked]> ]
>>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>>>> To: DOLLY, MARTIN C (ATTLABS)
>>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>
>>>>> The point is that people speak as individuals in the IETF and there
>>>>> is
>>>>> no particular notion that a corporate opinion has any more weight
>>>>> than
>>>>> that of any individual. Thus, stating a corporate opinion is out of
>>>>> place and against IETF custom and convention.
>>>>>
>>>>>
>>>>> Henning
>>>>>
>>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>>>>
>>>>>> They sure do, look at everyone's badge
>>>>>>
>>>>>> ----- Original Message -----
>>>>>> From: [email-masked] <[email-masked]>
>>>>>> To: DALY, BRIAN K (ATTCINW)
>>>>>> Cc: [email-masked] <[email-masked]>
>>>>>> Sent: Wed Apr 07 16:21:20 2010
>>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>>
>>>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>>>> IETF
>>>>> rules have changed recently?
>>>>>>
>>>>>> Henning
>>>>>>
>>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>>>>
>>>>>>> For the record, AT&T is in opposition to removing the last
>>>>>>> sentence.
>>>>>>>
>>>>>>> Brian Daly
>>>>>>> AT&T
>>>>>>
>>>>>> _______________________________________________
>>>>>> earlywarning mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>>
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> <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
>
>

Content-class: urn:content-classes:message
Date: Thu, 8 Apr 2010 07:53:37 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "ken carlberg" <[email-masked]>, "DRAGE, Keith (Keith)" <[email-masked]>
Cc: [email-masked], "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, Tschofenig <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Actually the part in parenthesis is not speculative but law - it is part
of the WARN Act passed by Congress, and included in Part 10 of the FCC
rules.

Regarding the discussion on network stress, it is relatively easy to
stress the network in times of disaster. While the 9/11 and London
bombings may be an extreme, the more subtle cases are the Minneapolis
bridge disaster, the threat of a tsunami due to the earthquake in Chili
(which stressed the systems in SoCal when they tried to issue a tsunami
advisory). Even "benign" large scale messages such as to a college
campus can result in network stress. We have extensively studied and
modeled network behavior due to emergency situations, and the results of
these studies went into the 10 month long process developing and
optimized solution for commercial mobile networks.

The other factor is how time critical is the message - a brush fire
threat advisory is not that critical, so if it is delayed by a half
hour, hour, or several hours, no big deal. However, a tornado warning
may have only minutes of reaction time and if the message is delayed
tens of minutes to hours, then it becomes not only a useless message,
but also jeopardizes the integrity of the entire alerting system.

Actually localized alerts are as problematic - if not more than - alerts
covering a large geographic area. Wireless network are not engineered to
allow everyone to be able to access resources simultaneously - it is
based on statistical traffic modeling and historical data- the so-called
"busy hour". And the technology has limitations - for example, you can
only send 2 SMSs/second/sector as a rule of thumb. Likewise, there are a
limited number of Radio Access Bearers (RABs) available per sector, and
a limit on the number of PDP contexts that can be established at the
SGSN. So if ATOCA required users to have a PDP context established and a
push service to send the data to the device, if there are a large number
of devices per sector then you can see the congestion problem. This is
why any point to point mechanism - be it SMS, IP "push" or whatever,
will fail in alerting scenarios and why broadcast mechanisms are
required.

CMAS solves the localization of alerts that you mention as GSM has the
capability to target down to the cell site (it is an operator choice on
how fine a geographic area to deliver the alerts).

CMAS solves all the problems and use cases you mention using a mechanism
designed to take advantage of the efficiency of the "layer 2" networks.
I saw discussion that it is character limited - 90 is the real number,
not 140 as a previous post suggested. However this is only for the
initial deployment, and in the future multimedia capabilities will be
added (see the CMSAAC report).

Brian Daly

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Thursday, April 08, 2010 5:18 AM
To: DRAGE, Keith (Keith)
Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW);
[email-masked]; Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Keith,

first, thanks for the well thought out comments.  I agree with a number
of specific points you made (which are snipped out), but other things I
find some disagreement with...

> However this usage is only good for broadcasting to all users within
the cell that have turned on that type of alert (with varying degrees of
optionality - the US government may not allow you to opt out of a
presidential alert except by turning your phone off).

ouch, the part in parenthesis is quite speculative, at best.

> Note that cell broadcast is not the same as IP multicast - it happens
at the levels below IP. IP multicast in cellphone networks will normally
result in multiple point-to-point communications. Potentially MBMS could
be used if deployed to support IP multicast, but that still uses the
same traffic channels as other voice users.

agreed, but lets not constrain our view to just the UE->tower.  Parts of
the backhaul can be prone to congestion as well, and in a direction of
LTE, more components will be IP based and thus taking advantage of a
layer-3 tree distribution structure.

> I believe Janet is correct that emergency alerts happen at times of
network stress. Even if the incident to which they relate is not
generating traffic in its own right, I suspect the first response to
receiving a flood alert is to pick the phone up and call the remainder
of your family to check what precautions they are taking, thus resulting
in additional network traffic.

I would disagree with the above assertion.  From what I've gathered, its
only a small subset of alerts that happen at times of network stress.
Clearly the 9/11 attack and the London bombings are the most acute
instances of an event that grabs a lot of attention and subsequent load
on networks.  However, existing systems send alerts quite often that are
localized and do not automatically correlate to network stress. =20

A few years ago, I spoke with several local county emergency management
directors along the I-95 corridor in the North East U.S., and their
day-to-day concern isn't focused on terrorism or natural disasters, but
rather on hazardous materials on the highways.  Their interest is in
using mechanisms like inverse-911 and localizing the alerts.

As a different example, a friend of mine in DC received an alert on his
cell phone yesterday of brush fire warnings -- not that a brush fire
existed, but that the conditions were favorable for one to occur.  And
there certainly wasn't any corresponding stress on the cell network.=20

> Therefore it is likely that 3GPP network operators have to shed
traffic when major alerts are being given. Certain traffic is tagged as
having special handling on the wireless part (emergency calls and
authority to citizen / authority). There are two aspects to this:
>=20
> -	Can they identify non-essential traffic and discard a larger
proportion of this as opposed to essential traffic.
>=20
> -	Can they ensure that traffic is not duplicated in the first
place.
>=20
> In regard to the ATOCA proposal given above, neither of these are
dealt with in the charter.

My concern about the above position is that it places a requirement on
ATOCA to assume that something in layer 2, or some walled garden, exists
and is *deployed*.  I think all of us are in agreement with the point
that Dave Oran made a while back that its ideal to take advantage of
mechanisms that can optimize ATOCA solutions.  But we need to be careful
in assuming that the specification of other mechanisms does not
guarantee their deployment.

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

Content-class: urn:content-classes:message
Date: Thu, 8 Apr 2010 07:33:41 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, "Padma Valluri" <[email-masked]>
Cc: [email-masked], "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Brian -=20

If "no one" is asking for interoperability (and I am not sure who "no =
one" is :-) ) then I agree this can be a somewhat peaceful co-existence =
of mandated services (CMAS, EAS, iPAWS, DMOpen vs a market driven =
service that is not and will not be designed with the intention to =
integrate into or interoperate with services such as CMAS.

However, because of the potential for confusion by the reader and =
regulators, all we are asking is that the charter clearly state this =
fact that apparently we are in agreement on.

Can we craft some language for the charter that emphasizes this?

Brian D.

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Thursday, April 08, 2010 6:34 AM
To: Padma Valluri
Cc: [email-masked]; SENNETT, DEWAYNE A (ATTCINW); =
[email-masked]; DOLLY, MARTIN C (ATTLABS)
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Because it=B9s pretty hard to define =B3interoperability=B2 with L2 =
mechanisms
that deliver alerts.  One of the biggest problems I have with most =
existing
L2 specific mechanisms is that they assume they are the only way alerts =
are
received. As a result, if you get an alert from some other mechanism, =
you
have no idea if its the same alert or a different one.  Your UI can't =
help
you at all with this.  One of the things I think we need is some ID
mechanism which is protocol agnostic and simply serves as the way to =
know if
you got an alert from multiple sources that they are the same alert.

Actually, no one is asking for interoperability.  They are discussing
various forms of peaceful co-existence.  Designing the protocol to take
advantage of some kinds of L2 packet delivery mechanisms may be possible
however.

Brian

On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:

>=20
> I'm not sure what "use" means here other than to imply
> interoperable/interworking with existing capabilities that are more =
efficient
> in certain segments of the network and deployed already. Why can't we =
be up
> front about making the interoperabilty as one of the main requirements =
of this
> charter to provide an end-to-end solution?
>=20
> thanks,=20
> Padma .=20
>=20
>=20
> From: Brian Rosen <[email-masked]>
> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)"
> <[email-masked]>=20
> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" =
<[email-masked]>
> Date: 04/07/2010 05:55 PM
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
>=20
>=20
>=20
> I'm not bothered by the first part.  I don't like the last phrase, =
because
> I'm not sure we should specifically describe such capabilities, and it =
may
> not be a gateway.  How about changing the last sentence to "A goal of =
the
> work will be to be able to use layer-2 specific mechanisms, where =
available,
> to minimize load on the network."
>=20
>=20
> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>=20
>> Ok, I can grant that that's something that's not clearly explained in
>> the current charter.  However, it's also an issue that will tend to =
be
>> layer-2 specific.  How about something like this:
>>=20
>> "
>> Emergency alerts that are delivered to large numbers of endpoints can
>> put a large load on the network, particularly when many affected =
users
>> are on the same local network (e.g., the 100,000 attendees at a
>> sporting event).  This working group will consider mechanisms for
>> minimizing this load, such as IP multicast.  In particular, some
>> approaches have been developed to handle emergency alerting in
>> different types networks, and it will be a goal of this working group
>> to facilitate interoperability with these approaches, for example, to
>> enable gateways to relay messages from this Internet mechanism into a
>> specific layer-2 channel.
>> "
>>=20
>>=20
>>=20
>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>=20
>>> It is deficient because it does not take into account the impacts =
that
>>> will occur to the various access technologies.  All access
>>> technologies
>>> do not have the same capacity, bandwidth, etc. Therefore any design
>>> that
>>> has the potential to send information to all citizens within an area
>>> via
>>> any variety of access technologies needs to consider these factors.
>>> For
>>> example, consider the scenario of trying to send an alert to the
>>> 100,000
>>> fans at a college football game.
>>>=20
>>> The current draft charter of ATOCA does not address this which is =
why
>>> the additional sentences for the second paragraph were proposed.
>>>=20
>>> DeWayne
>>>=20
>>> -----Original Message-----
>>> From: Richard Barnes [mailto:[email-masked] =
<mailto:[email-masked]> ]
>>> Sent: Wednesday, April 07, 2010 1:38 PM
>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>>> (ATTLABS); [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>=20
>>> Could you please clarify how you believe it to be deficient?
>>>=20
>>>=20
>>>=20
>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>=20
>>>> My "personal" view is that the charter as currently written is not
>>>> correct or adequate.
>>>>=20
>>>> DeWayne
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]
>>>> <mailto:[email-masked]> ] On Behalf Of DALY, BRIAN K
>>>> (ATTCINW)
>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>>> Cc: [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>=20
>>>> Fine but my "personal" view does not change.
>>>>=20
>>>> Brian Daly
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Henning Schulzrinne [mailto:[email-masked]
>>>> <mailto:[email-masked]> ]
>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>>> To: DOLLY, MARTIN C (ATTLABS)
>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>=20
>>>> The point is that people speak as individuals in the IETF and there
>>>> is
>>>> no particular notion that a corporate opinion has any more weight
>>>> than
>>>> that of any individual. Thus, stating a corporate opinion is out of
>>>> place and against IETF custom and convention.
>>>>=20
>>>>=20
>>>> Henning
>>>>=20
>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>>>=20
>>>>> They sure do, look at everyone's badge
>>>>>=20
>>>>> ----- Original Message -----
>>>>> From: [email-masked] =
<[email-masked]>
>>>>> To: DALY, BRIAN K (ATTCINW)
>>>>> Cc: [email-masked] <[email-masked]>
>>>>> Sent: Wed Apr 07 16:21:20 2010
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>=20
>>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>>> IETF
>>>> rules have changed recently?
>>>>>=20
>>>>> Henning
>>>>>=20
>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>>>=20
>>>>>> For the record, AT&T is in opposition to removing the last
>>>>>> sentence.
>>>>>>=20
>>>>>> Brian Daly
>>>>>> AT&T
>>>>>=20
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>=20
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>=20
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> <https://www.ietf.org/mailman/listinfo/earlywarning>
>=20
>=20
>=20

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

Importance: Normal
Sensitivity: 
From: Padma Valluri <[email-masked]>
To: Brian Rosen <[email-masked]>
Date: Thu, 8 Apr 2010 09:50:33 -0400
Cc: [email-masked], "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

<FONT face=3D"Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size=
=3D2><DIV>I was thinking of a usecase where the issuing authority can use t=
he SIP mechanism to send an alert and it continues until it hits an acess n=
etwork brocast point where this gets converted to a L2 alert like it happen=
s in other IMS protocols. Won't that require some kind of interworking?<BR>=
</DIV><DIV>Padma Valluri<BR>CSC<BR><BR>15000 Conference Center Dr., Chantil=
ly, VA&nbsp;&nbsp;20151<BR>Enforcement Security &amp; Intelligence | w: 703=
-818-4937 | f: 703-818-4053 |<A href=3D"mailto:[email-masked]" target=3Db=
lank>[email-masked]</A> | <A href=3D"http://www.csc.com/" target=3Dblank>=
www.csc.com</A><BR><BR><BR><SPAN style=3D"FONT-SIZE: 10px">This is a PRIVAT=
E message. If you are not the intended recipient, please delete without cop=
ying and kindly advise us by e-mail of the mistake in delivery. <BR>NOTE: R=
egardless of content, this e-mail shall not operate to bind CSC to any orde=
r or other contract unless pursuant to explicit written agreement or govern=
ment initiative expressly permitting the use of e-mail for such purpose.</S=
PAN><DIV><BR></DIV><FONT color=3D#990099>-----Brian Rosen &lt;br@brianrosen=
.net&gt; wrote: -----<BR><BR></FONT><BLOCKQUOTE style=3D"BORDER-LEFT: #0000=
00 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARG=
IN-RIGHT: 0px">To: Padma Valluri/USA/CSC@CSC<BR>From: Brian Rosen &lt;br@br=
ianrosen.net&gt;<BR>Date: 04/08/2010 09:34AM<BR>cc: "SENNETT, DEWAYNE A (AT=
TCINW)" &lt;[email-masked]&gt;, &lt;[email-masked]&gt;, &lt;earlywar=
[email-masked]&gt;, "DOLLY, MARTIN C (ATTLABS)" &lt;[email-masked]&g=
t;, Richard Barnes &lt;[email-masked]&gt;<BR>Subject: Re: [earlywarning] F=
inishing the Charter Text Discussions<BR><BR><FONT size=3D2 face=3D"Default=
 Monospace,Courier New,Courier,monospace">Because it=C2=B9s pretty hard to =
define =C2=B3interoperability=C2=B2 with L2 mechanisms<BR>that deliver aler=
ts. &nbsp;One of the biggest problems I have with most existing<BR>L2 speci=
fic mechanisms is that they assume they are the only way alerts are<BR>rece=
ived. As a result, if you get an alert from some other mechanism, you<BR>ha=
ve no idea if its the same alert or a different one. &nbsp;Your UI can't he=
lp<BR>you at all with this. &nbsp;One of the things I think we need is some=
 ID<BR>mechanism which is protocol agnostic and simply serves as the way to=
 know if<BR>you got an alert from multiple sources that they are the same a=
lert.<BR><BR>Actually, no one is asking for interoperability. &nbsp;They ar=
e discussing<BR>various forms of peaceful co-existence. &nbsp;Designing the=
 protocol to take<BR>advantage of some kinds of L2 packet delivery mechanis=
ms may be possible<BR>however.<BR><BR>Brian<BR><BR><BR>On 4/8/10 9:18 AM, "=
Padma Valluri" &lt;[email-masked]&gt; wrote:<BR><BR>&gt; <BR>&gt; I'm not=
 sure what "use" means here other than to imply<BR>&gt; interoperable/inter=
working with existing capabilities that are more efficient<BR>&gt; in certa=
in segments of the network and deployed already. Why can't we be up<BR>&gt;=
 front about making the interoperabilty as one of the main requirements of =
this<BR>&gt; charter to provide an end-to-end solution?<BR>&gt; <BR>&gt; th=
anks, <BR>&gt; Padma . <BR>&gt; <BR>&gt; <BR>&gt; From: Brian Rosen &lt;br@=
brianrosen.net&gt;<BR>&gt; To: Richard Barnes &lt;[email-masked]&gt;, "SEN=
NETT, DEWAYNE A (ATTCINW)"<BR>&gt; &lt;[email-masked]&gt; <BR>&gt; Cc: earl=
[email-masked], "DOLLY, MARTIN C \(ATTLABS\)" &lt;[email-masked]&gt;<BR>=
&gt; Date: 04/07/2010 05:55 PM<BR>&gt; Subject: Re: [earlywarning] Finishin=
g the Charter Text Discussions<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; =
I'm not bothered by the first part. &nbsp;I don't like the last phrase, bec=
ause<BR>&gt; I'm not sure we should specifically describe such capabilities=
, and it may<BR>&gt; not be a gateway. &nbsp;How about changing the last se=
ntence to "A goal of the<BR>&gt; work will be to be able to use layer-2 spe=
cific mechanisms, where available,<BR>&gt; to minimize load on the network.=
"<BR>&gt; <BR>&gt; <BR>&gt; On 4/7/10 5:41 PM, "Richard Barnes" &lt;rbarnes=
@bbn.com&gt; wrote:<BR>&gt; <BR>&gt;&gt; Ok, I can grant that that's someth=
ing that's not clearly explained in<BR>&gt;&gt; the current charter. &nbsp;=
However, it's also an issue that will tend to be<BR>&gt;&gt; layer-2 specif=
ic. &nbsp;How about something like this:<BR>&gt;&gt; <BR>&gt;&gt; "<BR>&gt;=
&gt; Emergency alerts that are delivered to large numbers of endpoints can<=
BR>&gt;&gt; put a large load on the network, particularly when many affecte=
d users<BR>&gt;&gt; are on the same local network (e.g., the 100,000 attend=
ees at a<BR>&gt;&gt; sporting event). &nbsp;This working group will conside=
r mechanisms for<BR>&gt;&gt; minimizing this load, such as IP multicast. &n=
bsp;In particular, some<BR>&gt;&gt; approaches have been developed to handl=
e emergency alerting in<BR>&gt;&gt; different types networks, and it will b=
e a goal of this working group<BR>&gt;&gt; to facilitate interoperability w=
ith these approaches, for example, to<BR>&gt;&gt; enable gateways to relay =
messages from this Internet mechanism into a<BR>&gt;&gt; specific layer-2 c=
hannel.<BR>&gt;&gt; "<BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; On=
 Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:<BR>&gt;&gt; <=
BR>&gt;&gt;&gt; It is deficient because it does not take into account the i=
mpacts that<BR>&gt;&gt;&gt; will occur to the various access technologies. =
&nbsp;All access<BR>&gt;&gt;&gt; technologies<BR>&gt;&gt;&gt; do not have t=
he same capacity, bandwidth, etc. Therefore any design<BR>&gt;&gt;&gt; that=
<BR>&gt;&gt;&gt; has the potential to send information to all citizens with=
in an area<BR>&gt;&gt;&gt; via<BR>&gt;&gt;&gt; any variety of access techno=
logies needs to consider these factors.<BR>&gt;&gt;&gt; For<BR>&gt;&gt;&gt;=
 example, consider the scenario of trying to send an alert to the<BR>&gt;&g=
t;&gt; 100,000<BR>&gt;&gt;&gt; fans at a college football game.<BR>&gt;&gt;=
&gt; <BR>&gt;&gt;&gt; The current draft charter of ATOCA does not address t=
his which is why<BR>&gt;&gt;&gt; the additional sentences for the second pa=
ragraph were proposed.<BR>&gt;&gt;&gt; <BR>&gt;&gt;&gt; DeWayne<BR>&gt;&gt;=
&gt; <BR>&gt;&gt;&gt; -----Original Message-----<BR>&gt;&gt;&gt; From: Rich=
ard Barnes [<A href=3D"mailto:[email-masked]" target=3Dblank>mailto:rbarne=
[email-masked]</A>&nbsp;&lt;<A href=3D"mailto:[email-masked]" target=3Dblank>ma=
ilto:[email-masked]</A>&gt; ]<BR>&gt;&gt;&gt; Sent: Wednesday, April 07, 2=
010 1:38 PM<BR>&gt;&gt;&gt; To: SENNETT, DEWAYNE A (ATTCINW)<BR>&gt;&gt;&gt=
; Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C<BR>&gt;=
&gt;&gt; (ATTLABS); [email-masked]<BR>&gt;&gt;&gt; Subject: Re: [ear=
lywarning] Finishing the Charter Text Discussions<BR>&gt;&gt;&gt; <BR>&gt;&=
gt;&gt; Could you please clarify how you believe it to be deficient?<BR>&gt=
;&gt;&gt; <BR>&gt;&gt;&gt; <BR>&gt;&gt;&gt; <BR>&gt;&gt;&gt; On Apr 7, 2010=
, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:<BR>&gt;&gt;&gt; <BR>&gt;&=
gt;&gt;&gt; My "personal" view is that the charter as currently written is =
not<BR>&gt;&gt;&gt;&gt; correct or adequate.<BR>&gt;&gt;&gt;&gt; <BR>&gt;&g=
t;&gt;&gt; DeWayne<BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt=
;&gt; -----Original Message-----<BR>&gt;&gt;&gt;&gt; From: earlywarning-bou=
[email-masked]<BR>&gt;&gt;&gt;&gt; [<A href=3D"mailto:earlywarning-bounces@i=
etf.org" target=3Dblank>mailto:[email-masked]</A><BR>&gt;&gt=
;&gt;&gt; &lt;<A href=3D"mailto:[email-masked]" target=3Dbla=
nk>mailto:[email-masked]</A>&gt; ] On Behalf Of DALY, BRIAN =
K<BR>&gt;&gt;&gt;&gt; (ATTCINW)<BR>&gt;&gt;&gt;&gt; Sent: Wednesday, April =
07, 2010 1:33 PM<BR>&gt;&gt;&gt;&gt; To: Henning Schulzrinne; DOLLY, MARTIN=
 C (ATTLABS)<BR>&gt;&gt;&gt;&gt; Cc: [email-masked]<BR>&gt;&gt;&gt;&=
gt; Subject: Re: [earlywarning] Finishing the Charter Text Discussions<BR>&=
gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; Fine but my "personal" view does not c=
hange.<BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; Brian Daly<BR>&gt;&gt;&gt;&=
gt; <BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; -----Original Message-----<BR=
>&gt;&gt;&gt;&gt; From: Henning Schulzrinne [<A href=3D"mailto:[email-masked]=
bia.edu" target=3Dblank>mailto:[email-masked]</A><BR>&gt;&gt;&gt;&gt; =
&lt;<A href=3D"mailto:[email-masked]" target=3Dblank>mailto:[email-masked]=
umbia.edu</A>&gt; ]<BR>&gt;&gt;&gt;&gt; Sent: Wednesday, April 07, 2010 1:3=
1 PM<BR>&gt;&gt;&gt;&gt; To: DOLLY, MARTIN C (ATTLABS)<BR>&gt;&gt;&gt;&gt; =
Cc: DALY, BRIAN K (ATTCINW); [email-masked]<BR>&gt;&gt;&gt;&gt; Subj=
ect: Re: [earlywarning] Finishing the Charter Text Discussions<BR>&gt;&gt;&=
gt;&gt; <BR>&gt;&gt;&gt;&gt; The point is that people speak as individuals =
in the IETF and there<BR>&gt;&gt;&gt;&gt; is<BR>&gt;&gt;&gt;&gt; no particu=
lar notion that a corporate opinion has any more weight<BR>&gt;&gt;&gt;&gt;=
 than<BR>&gt;&gt;&gt;&gt; that of any individual. Thus, stating a corporate=
 opinion is out of<BR>&gt;&gt;&gt;&gt; place and against IETF custom and co=
nvention.<BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; Hen=
ning<BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; On Apr 7, 2010, at 4:28 PM, D=
OLLY, MARTIN C (ATTLABS) wrote:<BR>&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt;&gt=
; They sure do, look at everyone's badge<BR>&gt;&gt;&gt;&gt;&gt; <BR>&gt;&g=
t;&gt;&gt;&gt; ----- Original Message -----<BR>&gt;&gt;&gt;&gt;&gt; From: e=
[email-masked] &lt;[email-masked]&gt;<BR>&gt;&=
gt;&gt;&gt;&gt; To: DALY, BRIAN K (ATTCINW)<BR>&gt;&gt;&gt;&gt;&gt; Cc: ear=
[email-masked] &lt;[email-masked]&gt;<BR>&gt;&gt;&gt;&gt;&gt; Se=
nt: Wed Apr 07 16:21:20 2010<BR>&gt;&gt;&gt;&gt;&gt; Subject: Re: [earlywar=
ning] Finishing the Charter Text Discussions<BR>&gt;&gt;&gt;&gt;&gt; <BR>&g=
t;&gt;&gt;&gt;&gt; I didn't know that the IETF had corporate opinions. But =
maybe the<BR>&gt;&gt;&gt;&gt;&gt; IETF<BR>&gt;&gt;&gt;&gt; rules have chang=
ed recently?<BR>&gt;&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt;&gt; Henning<BR>&g=
t;&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt;&gt; On Apr 7, 2010, at 4:13 PM, DAL=
Y, BRIAN K (ATTCINW) wrote:<BR>&gt;&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt;&gt=
;&gt; For the record, AT&amp;T is in opposition to removing the last<BR>&gt=
;&gt;&gt;&gt;&gt;&gt; sentence.<BR>&gt;&gt;&gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt=
;&gt;&gt;&gt; Brian Daly<BR>&gt;&gt;&gt;&gt;&gt;&gt; AT&amp;T<BR>&gt;&gt;&g=
t;&gt;&gt; <BR>&gt;&gt;&gt;&gt;&gt; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F<BR>&gt;&gt;&gt;&gt;&gt; earlywarning mailing li=
st<BR>&gt;&gt;&gt;&gt;&gt; [email-masked]<BR>&gt;&gt;&gt;&gt;&gt; <A=
 href=3D"https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank=
>https://www.ietf.org/mailman/listinfo/earlywarning</A><BR>&gt;&gt;&gt;&gt;=
&gt; &lt;<A href=3D"https://www.ietf.org/mailman/listinfo/earlywarning" tar=
get=3Dblank>https://www.ietf.org/mailman/listinfo/earlywarning</A>&gt;<BR>&=
gt;&gt;&gt;&gt; <BR>&gt;&gt;&gt;&gt; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<BR>&gt;&gt;&gt;&gt; earlywarning mailing lis=
t<BR>&gt;&gt;&gt;&gt; [email-masked]<BR>&gt;&gt;&gt;&gt; <A href=3D"=
https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank>https://=
www.ietf.org/mailman/listinfo/earlywarning</A><BR>&gt;&gt;&gt;&gt; &lt;<A h=
ref=3D"https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank>h=
ttps://www.ietf.org/mailman/listinfo/earlywarning</A>&gt;<BR>&gt;&gt;&gt;&g=
t; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<BR>&g=
t;&gt;&gt;&gt; earlywarning mailing list<BR>&gt;&gt;&gt;&gt; earlywarning@i=
etf.org<BR>&gt;&gt;&gt;&gt; <A href=3D"https://www.ietf.org/mailman/listinf=
o/earlywarning" target=3Dblank>https://www.ietf.org/mailman/listinfo/earlyw=
arning</A><BR>&gt;&gt;&gt;&gt; &lt;<A href=3D"https://www.ietf.org/mailman/=
listinfo/earlywarning" target=3Dblank>https://www.ietf.org/mailman/listinfo=
/earlywarning</A>&gt;<BR>&gt;&gt;&gt; <BR>&gt;&gt; <BR>&gt;&gt; =5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<BR>&gt;&gt; early=
warning mailing list<BR>&gt;&gt; [email-masked]<BR>&gt;&gt; <A href=
=3D"https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank>http=
s://www.ietf.org/mailman/listinfo/earlywarning</A><BR>&gt;&gt; &lt;<A href=
=3D"https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank>http=
s://www.ietf.org/mailman/listinfo/earlywarning</A>&gt;<BR>&gt; <BR>&gt; <BR=
>&gt; =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<BR=
>&gt; earlywarning mailing list<BR>&gt; [email-masked]<BR>&gt; <A hr=
ef=3D"https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank>ht=
tps://www.ietf.org/mailman/listinfo/earlywarning</A><BR>&gt; &lt;<A href=3D=
"https://www.ietf.org/mailman/listinfo/earlywarning" target=3Dblank>https:/=
/www.ietf.org/mailman/listinfo/earlywarning</A>&gt;<BR>&gt; <BR>&gt; <BR>&g=
t; <BR><BR><BR></FONT></BLOCKQUOTE><BR></DIV></FONT>=

Date: Thu, 08 Apr 2010 09:34:11 -0400
From: Brian Rosen <[email-masked]>
To: Padma Valluri <[email-masked]>
Cc: [email-masked], "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Because it=B9s pretty hard to define =B3interoperability=B2 with L2 mechanisms
that deliver alerts.  One of the biggest problems I have with most existing
L2 specific mechanisms is that they assume they are the only way alerts are
received. As a result, if you get an alert from some other mechanism, you
have no idea if its the same alert or a different one.  Your UI can't help
you at all with this.  One of the things I think we need is some ID
mechanism which is protocol agnostic and simply serves as the way to know i=
f
you got an alert from multiple sources that they are the same alert.

Actually, no one is asking for interoperability.  They are discussing
various forms of peaceful co-existence.  Designing the protocol to take
advantage of some kinds of L2 packet delivery mechanisms may be possible
however.

Brian

On 4/8/10 9:18 AM, "Padma Valluri" <[email-masked]> wrote:

>=20
> I'm not sure what "use" means here other than to imply
> interoperable/interworking with existing capabilities that are more effic=
ient
> in certain segments of the network and deployed already. Why can't we be =
up
> front about making the interoperabilty as one of the main requirements of=
 this
> charter to provide an end-to-end solution?
>=20
> thanks,=20
> Padma .=20
>=20
>=20
> From: Brian Rosen <[email-masked]>
> To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)"
> <[email-masked]>=20
> Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
> Date: 04/07/2010 05:55 PM
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
>=20
>=20
>=20
> I'm not bothered by the first part.  I don't like the last phrase, becaus=
e
> I'm not sure we should specifically describe such capabilities, and it ma=
y
> not be a gateway.  How about changing the last sentence to "A goal of the
> work will be to be able to use layer-2 specific mechanisms, where availab=
le,
> to minimize load on the network."
>=20
>=20
> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>=20
>> Ok, I can grant that that's something that's not clearly explained in
>> the current charter.  However, it's also an issue that will tend to be
>> layer-2 specific.  How about something like this:
>>=20
>> "
>> Emergency alerts that are delivered to large numbers of endpoints can
>> put a large load on the network, particularly when many affected users
>> are on the same local network (e.g., the 100,000 attendees at a
>> sporting event).  This working group will consider mechanisms for
>> minimizing this load, such as IP multicast.  In particular, some
>> approaches have been developed to handle emergency alerting in
>> different types networks, and it will be a goal of this working group
>> to facilitate interoperability with these approaches, for example, to
>> enable gateways to relay messages from this Internet mechanism into a
>> specific layer-2 channel.
>> "
>>=20
>>=20
>>=20
>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>=20
>>> It is deficient because it does not take into account the impacts that
>>> will occur to the various access technologies.  All access
>>> technologies
>>> do not have the same capacity, bandwidth, etc. Therefore any design
>>> that
>>> has the potential to send information to all citizens within an area
>>> via
>>> any variety of access technologies needs to consider these factors.
>>> For
>>> example, consider the scenario of trying to send an alert to the
>>> 100,000
>>> fans at a college football game.
>>>=20
>>> The current draft charter of ATOCA does not address this which is why
>>> the additional sentences for the second paragraph were proposed.
>>>=20
>>> DeWayne
>>>=20
>>> -----Original Message-----
>>> From: Richard Barnes [mailto:[email-masked] <mailto:[email-masked]> ]
>>> Sent: Wednesday, April 07, 2010 1:38 PM
>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>>> (ATTLABS); [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>=20
>>> Could you please clarify how you believe it to be deficient?
>>>=20
>>>=20
>>>=20
>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>=20
>>>> My "personal" view is that the charter as currently written is not
>>>> correct or adequate.
>>>>=20
>>>> DeWayne
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]
>>>> <mailto:[email-masked]> ] On Behalf Of DALY, BRIAN K
>>>> (ATTCINW)
>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>>> Cc: [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>=20
>>>> Fine but my "personal" view does not change.
>>>>=20
>>>> Brian Daly
>>>>=20
>>>>=20
>>>> -----Original Message-----
>>>> From: Henning Schulzrinne [mailto:[email-masked]
>>>> <mailto:[email-masked]> ]
>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>>> To: DOLLY, MARTIN C (ATTLABS)
>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>=20
>>>> The point is that people speak as individuals in the IETF and there
>>>> is
>>>> no particular notion that a corporate opinion has any more weight
>>>> than
>>>> that of any individual. Thus, stating a corporate opinion is out of
>>>> place and against IETF custom and convention.
>>>>=20
>>>>=20
>>>> Henning
>>>>=20
>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>>>=20
>>>>> They sure do, look at everyone's badge
>>>>>=20
>>>>> ----- Original Message -----
>>>>> From: [email-masked] <[email-masked]>
>>>>> To: DALY, BRIAN K (ATTCINW)
>>>>> Cc: [email-masked] <[email-masked]>
>>>>> Sent: Wed Apr 07 16:21:20 2010
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>=20
>>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>>> IETF
>>>> rules have changed recently?
>>>>>=20
>>>>> Henning
>>>>>=20
>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>>>=20
>>>>>> For the record, AT&T is in opposition to removing the last
>>>>>> sentence.
>>>>>>=20
>>>>>> Brian Daly
>>>>>> AT&T
>>>>>=20
>>>>> _______________________________________________
>>>>> earlywarning mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>>=20
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>> _______________________________________________
>>>> earlywarning mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>>>=20
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>> <https://www.ietf.org/mailman/listinfo/earlywarning>
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> <https://www.ietf.org/mailman/listinfo/earlywarning>
>=20
>=20
>=20

From: Padma Valluri <[email-masked]>
To: Brian Rosen <[email-masked]>
Sender: Padma Valluri <[email-masked]>
Date: Thu, 8 Apr 2010 09:18:42 -0400
Cc: [email-masked], "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

This is a multipart message in MIME format.
--=_alternative 00492177852576FF_=
Content-Type: text/plain; charset="US-ASCII"

I'm not sure what "use" means here other than to imply 
interoperable/interworking with existing capabilities that are more 
efficient in certain segments of the network and deployed already. Why 
can't we be up front about making the interoperabilty as one of the main 
requirements of this charter to provide an end-to-end solution?

thanks,
Padma .

From:
Brian Rosen <[email-masked]>
To:
Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" 
<[email-masked]>
Cc:
[email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Date:
04/07/2010 05:55 PM
Subject:
Re: [earlywarning] Finishing the Charter Text Discussions

I'm not bothered by the first part.  I don't like the last phrase, because
I'm not sure we should specifically describe such capabilities, and it may
not be a gateway.  How about changing the last sentence to "A goal of the
work will be to be able to use layer-2 specific mechanisms, where 
available,
to minimize load on the network."

On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:

> Ok, I can grant that that's something that's not clearly explained in
> the current charter.  However, it's also an issue that will tend to be
> layer-2 specific.  How about something like this:
> 
> "
> Emergency alerts that are delivered to large numbers of endpoints can
> put a large load on the network, particularly when many affected users
> are on the same local network (e.g., the 100,000 attendees at a
> sporting event).  This working group will consider mechanisms for
> minimizing this load, such as IP multicast.  In particular, some
> approaches have been developed to handle emergency alerting in
> different types networks, and it will be a goal of this working group
> to facilitate interoperability with these approaches, for example, to
> enable gateways to relay messages from this Internet mechanism into a
> specific layer-2 channel.
> "
> 
> 
> 
> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> It is deficient because it does not take into account the impacts that
>> will occur to the various access technologies.  All access
>> technologies
>> do not have the same capacity, bandwidth, etc. Therefore any design
>> that
>> has the potential to send information to all citizens within an area
>> via
>> any variety of access technologies needs to consider these factors.
>> For
>> example, consider the scenario of trying to send an alert to the
>> 100,000
>> fans at a college football game.
>> 
>> The current draft charter of ATOCA does not address this which is why
>> the additional sentences for the second paragraph were proposed.
>> 
>> DeWayne
>> 
>> -----Original Message-----
>> From: Richard Barnes [mailto:[email-masked]]
>> Sent: Wednesday, April 07, 2010 1:38 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>> (ATTLABS); [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> 
>> Could you please clarify how you believe it to be deficient?
>> 
>> 
>> 
>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>> 
>>> My "personal" view is that the charter as currently written is not
>>> correct or adequate.
>>> 
>>> DeWayne
>>> 
>>> 
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
>>> (ATTCINW)
>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>> Cc: [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>> 
>>> Fine but my "personal" view does not change.
>>> 
>>> Brian Daly
>>> 
>>> 
>>> -----Original Message-----
>>> From: Henning Schulzrinne [mailto:[email-masked]]
>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>> To: DOLLY, MARTIN C (ATTLABS)
>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>> 
>>> The point is that people speak as individuals in the IETF and there
>>> is
>>> no particular notion that a corporate opinion has any more weight
>>> than
>>> that of any individual. Thus, stating a corporate opinion is out of
>>> place and against IETF custom and convention.
>>> 
>>> 
>>> Henning
>>> 
>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>> 
>>>> They sure do, look at everyone's badge
>>>> 
>>>> ----- Original Message -----
>>>> From: [email-masked] <[email-masked]>
>>>> To: DALY, BRIAN K (ATTCINW)
>>>> Cc: [email-masked] <[email-masked]>
>>>> Sent: Wed Apr 07 16:21:20 2010
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>> 
>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>> IETF
>>> rules have changed recently?
>>>> 
>>>> Henning
>>>> 
>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>> 
>>>>> For the record, AT&T is in opposition to removing the last
>>>>> sentence.
>>>>> 
>>>>> Brian Daly
>>>>> AT&T
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

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

--=_alternative 00492177852576FF_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">I'm not sure what &quot;use&quot; means
here other than to imply interoperable/interworking with existing capabilities
that are more efficient in certain segments of the network and deployed
already. Why can't we be up front about making the interoperabilty as one
of the main requirements of this charter to provide an end-to-end solution?</font>
<br>
<br><font size=2 face="sans-serif">thanks,</font>
<br><font size=2 face="sans-serif">Padma .</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Brian Rosen &lt;[email-masked]&gt;</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Richard Barnes &lt;[email-masked]&gt;,
&quot;SENNETT, DEWAYNE A (ATTCINW)&quot; &lt;[email-masked]&gt;</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">[email-masked], &quot;DOLLY,
MARTIN C \(ATTLABS\)&quot; &lt;[email-masked]&gt;</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">04/07/2010 05:55 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [earlywarning] Finishing the Charter
Text Discussions</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I'm not bothered by the first part. &nbsp;I don't
like the last phrase, because<br>
I'm not sure we should specifically describe such capabilities, and it
may<br>
not be a gateway. &nbsp;How about changing the last sentence to &quot;A
goal of the<br>
work will be to be able to use layer-2 specific mechanisms, where available,<br>
to minimize load on the network.&quot;<br>
<br>
<br>
On 4/7/10 5:41 PM, &quot;Richard Barnes&quot; &lt;[email-masked]&gt; wrote:<br>
<br>
&gt; Ok, I can grant that that's something that's not clearly explained
in<br>
&gt; the current charter. &nbsp;However, it's also an issue that will tend
to be<br>
&gt; layer-2 specific. &nbsp;How about something like this:<br>
&gt; <br>
&gt; &quot;<br>
&gt; Emergency alerts that are delivered to large numbers of endpoints
can<br>
&gt; put a large load on the network, particularly when many affected users<br>
&gt; are on the same local network (e.g., the 100,000 attendees at a<br>
&gt; sporting event). &nbsp;This working group will consider mechanisms
for<br>
&gt; minimizing this load, such as IP multicast. &nbsp;In particular, some<br>
&gt; approaches have been developed to handle emergency alerting in<br>
&gt; different types networks, and it will be a goal of this working group<br>
&gt; to facilitate interoperability with these approaches, for example,
to<br>
&gt; enable gateways to relay messages from this Internet mechanism into
a<br>
&gt; specific layer-2 channel.<br>
&gt; &quot;<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:<br>
&gt; <br>
&gt;&gt; It is deficient because it does not take into account the impacts
that<br>
&gt;&gt; will occur to the various access technologies. &nbsp;All access<br>
&gt;&gt; technologies<br>
&gt;&gt; do not have the same capacity, bandwidth, etc. Therefore any design<br>
&gt;&gt; that<br>
&gt;&gt; has the potential to send information to all citizens within an
area<br>
&gt;&gt; via<br>
&gt;&gt; any variety of access technologies needs to consider these factors.<br>
&gt;&gt; For<br>
&gt;&gt; example, consider the scenario of trying to send an alert to the<br>
&gt;&gt; 100,000<br>
&gt;&gt; fans at a college football game.<br>
&gt;&gt; <br>
&gt;&gt; The current draft charter of ATOCA does not address this which
is why<br>
&gt;&gt; the additional sentences for the second paragraph were proposed.<br>
&gt;&gt; <br>
&gt;&gt; DeWayne<br>
&gt;&gt; <br>
&gt;&gt; -----Original Message-----<br>
&gt;&gt; From: Richard Barnes [</font></tt><a href=mailto:[email-masked]><tt><font size=2>mailto:[email-masked]</font></tt></a><tt><font size=2>]<br>
&gt;&gt; Sent: Wednesday, April 07, 2010 1:38 PM<br>
&gt;&gt; To: SENNETT, DEWAYNE A (ATTCINW)<br>
&gt;&gt; Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN
C<br>
&gt;&gt; (ATTLABS); [email-masked]<br>
&gt;&gt; Subject: Re: [earlywarning] Finishing the Charter Text Discussions<br>
&gt;&gt; <br>
&gt;&gt; Could you please clarify how you believe it to be deficient?<br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; <br>
&gt;&gt; On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:<br>
&gt;&gt; <br>
&gt;&gt;&gt; My &quot;personal&quot; view is that the charter as currently
written is not<br>
&gt;&gt;&gt; correct or adequate.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; DeWayne<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; -----Original Message-----<br>
&gt;&gt;&gt; From: [email-masked]<br>
&gt;&gt;&gt; [</font></tt><a href="mailto:[email-masked]"><tt><font size=2>mailto:[email-masked]</font></tt></a><tt><font size=2>]
On Behalf Of DALY, BRIAN K<br>
&gt;&gt;&gt; (ATTCINW)<br>
&gt;&gt;&gt; Sent: Wednesday, April 07, 2010 1:33 PM<br>
&gt;&gt;&gt; To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)<br>
&gt;&gt;&gt; Cc: [email-masked]<br>
&gt;&gt;&gt; Subject: Re: [earlywarning] Finishing the Charter Text Discussions<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Fine but my &quot;personal&quot; view does not change.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Brian Daly<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; -----Original Message-----<br>
&gt;&gt;&gt; From: Henning Schulzrinne [</font></tt><a href=mailto:[email-masked]><tt><font size=2>mailto:[email-masked]</font></tt></a><tt><font size=2>]<br>
&gt;&gt;&gt; Sent: Wednesday, April 07, 2010 1:31 PM<br>
&gt;&gt;&gt; To: DOLLY, MARTIN C (ATTLABS)<br>
&gt;&gt;&gt; Cc: DALY, BRIAN K (ATTCINW); [email-masked]<br>
&gt;&gt;&gt; Subject: Re: [earlywarning] Finishing the Charter Text Discussions<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; The point is that people speak as individuals in the IETF
and there<br>
&gt;&gt;&gt; is<br>
&gt;&gt;&gt; no particular notion that a corporate opinion has any more
weight<br>
&gt;&gt;&gt; than<br>
&gt;&gt;&gt; that of any individual. Thus, stating a corporate opinion
is out of<br>
&gt;&gt;&gt; place and against IETF custom and convention.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Henning<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; They sure do, look at everyone's badge<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; ----- Original Message -----<br>
&gt;&gt;&gt;&gt; From: [email-masked] &lt;[email-masked]&gt;<br>
&gt;&gt;&gt;&gt; To: DALY, BRIAN K (ATTCINW)<br>
&gt;&gt;&gt;&gt; Cc: [email-masked] &lt;[email-masked]&gt;<br>
&gt;&gt;&gt;&gt; Sent: Wed Apr 07 16:21:20 2010<br>
&gt;&gt;&gt;&gt; Subject: Re: [earlywarning] Finishing the Charter Text
Discussions<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; I didn't know that the IETF had corporate opinions. But
maybe the<br>
&gt;&gt;&gt;&gt; IETF<br>
&gt;&gt;&gt; rules have changed recently?<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; Henning<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; For the record, AT&amp;T is in opposition to removing
the last<br>
&gt;&gt;&gt;&gt;&gt; sentence.<br>
&gt;&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt;&gt; Brian Daly<br>
&gt;&gt;&gt;&gt;&gt; AT&amp;T<br>
&gt;&gt;&gt;&gt; <br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; earlywarning mailing list<br>
&gt;&gt;&gt;&gt; [email-masked]<br>
&gt;&gt;&gt;&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; earlywarning mailing list<br>
&gt;&gt;&gt; [email-masked]<br>
&gt;&gt;&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; earlywarning mailing list<br>
&gt;&gt;&gt; [email-masked]<br>
&gt;&gt;&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
&gt;&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; earlywarning mailing list<br>
&gt; [email-masked]<br>
&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
<br>
<br>
_______________________________________________<br>
earlywarning mailing list<br>
[email-masked]<br>
</font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
--=_alternative 00492177852576FF_=--

From: ken carlberg <[email-masked]>
Date: Thu, 8 Apr 2010 08:18:05 -0400
To: "DRAGE, Keith (Keith)" <[email-masked]>
Cc: [email-masked], "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Keith,

first, thanks for the well thought out comments.  I agree with a number =
of specific points you made (which are snipped out), but other things I =
find some disagreement with...

> However this usage is only good for broadcasting to all users within =
the cell that have turned on that type of alert (with varying degrees of =
optionality - the US government may not allow you to opt out of a =
presidential alert except by turning your phone off).

ouch, the part in parenthesis is quite speculative, at best.

> Note that cell broadcast is not the same as IP multicast - it happens =
at the levels below IP. IP multicast in cellphone networks will normally =
result in multiple point-to-point communications. Potentially MBMS could =
be used if deployed to support IP multicast, but that still uses the =
same traffic channels as other voice users.

agreed, but lets not constrain our view to just the UE->tower.  Parts of =
the backhaul can be prone to congestion as well, and in a direction of =
LTE, more components will be IP based and thus taking advantage of a =
layer-3 tree distribution structure.

> I believe Janet is correct that emergency alerts happen at times of =
network stress. Even if the incident to which they relate is not =
generating traffic in its own right, I suspect the first response to =
receiving a flood alert is to pick the phone up and call the remainder =
of your family to check what precautions they are taking, thus resulting =
in additional network traffic.

I would disagree with the above assertion.  =46rom what I've gathered, =
its only a small subset of alerts that happen at times of network =
stress.  Clearly the 9/11 attack and the London bombings are the most =
acute instances of an event that grabs a lot of attention and subsequent =
load on networks.  However, existing systems send alerts quite often =
that are localized and do not automatically correlate to network stress. =
=20

A few years ago, I spoke with several local county emergency management =
directors along the I-95 corridor in the North East U.S., and their =
day-to-day concern isn't focused on terrorism or natural disasters, but =
rather on hazardous materials on the highways.  Their interest is in =
using mechanisms like inverse-911 and localizing the alerts.

As a different example, a friend of mine in DC received an alert on his =
cell phone yesterday of brush fire warnings -- not that a brush fire =
existed, but that the conditions were favorable for one to occur.  And =
there certainly wasn't any corresponding stress on the cell network.=20

> Therefore it is likely that 3GPP network operators have to shed =
traffic when major alerts are being given. Certain traffic is tagged as =
having special handling on the wireless part (emergency calls and =
authority to citizen / authority). There are two aspects to this:
>=20
> -	Can they identify non-essential traffic and discard a larger =
proportion of this as opposed to essential traffic.
>=20
> -	Can they ensure that traffic is not duplicated in the first =
place.
>=20
> In regard to the ATOCA proposal given above, neither of these are =
dealt with in the charter.

My concern about the above position is that it places a requirement on =
ATOCA to assume that something in layer 2, or some walled garden, exists =
and is *deployed*.  I think all of us are in agreement with the point =
that Dave Oran made a while back that its ideal to take advantage of =
mechanisms that can optimize ATOCA solutions.  But we need to be careful =
in assuming that the specification of other mechanisms does not =
guarantee their deployment.

-ken=20=

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Janet P Gunn <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Thu, 8 Apr 2010 11:56:32 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

What I am not seeing from this extended discussion is anything that will as=
sist in permitted deployment of this in 3GPP networks (and probably 3GPP2 n=
etworks).

The existing 3GPP cell broadcast mechanism uses spare capacity that is not =
used for any other purpose than cell broadcast. It is not used for point-to=
-point traffic. Therefore at time of government alert that capacity automat=
ically gets used for goverment alerts at the expense of any other cell broa=
dcast traffic, but not at the expense of other point-to-point data and voic=
e. However this usage is only good for broadcasting to all users within the=
 cell that have turned on that type of alert (with varying degrees of optio=
nality - the US government may not allow you to opt out of a presidential a=
lert except by turning your phone off). Note that cell broadcast is not the=
 same as IP multicast - it happens at the levels below IP. IP multicast in =
cellphone networks will normally result in multiple point-to-point communic=
ations. Potentially MBMS could be used if deployed to support IP multicast,=
 but that still uses the same traffic channels as other voice users.

Therefore within 3GPP networks there is still a use for directed communicat=
ion whereby the cellphone is treated as an internet endpoint. This would be=
 for the type of alerts, for example, that schools send to its pupils only =
indicating that their own school is closed. The rest of the population does=
 not want these events, nor do pupils of other schools who may be in the sa=
me cell coverage area. Message identifiers are not a means of excluding thi=
s communication. Now under many usages of terminology, those situations do =
not comprise "emergency events" using the terms in this charter. My assumpt=
ion is that such events will be defined by this charter, but that is not cl=
ear at the moment.=20

Now lets consider what happens under aspects of 3GPP network stress. I beli=
eve Henning has said in the past that on 9-11, the only thing that kept wor=
king was the internet. It was not possible to make cellphone calls. A simil=
ar think happened in London on the underground bombings. Except where cells=
ite infrastructure itself was destroyed, what will have happened here is th=
at the cell broadcast channel was indeed still working, but the network was=
 so overloaded with signalling attempts that it was shedding traffic. Indee=
d 3GPP operators have algorithms for what traffic is shed under such circum=
stances. IP data, CS voice data and Voice over IP all use the same radio ch=
annels. Any of them occur at the expense of the other (although the split b=
etween CS voice usage and IP (and voice over IP) is configured.

I believe Janet is correct that emergency alerts happen at times of network=
 stress. Even if the incident to which they relate is not generating traffi=
c in its own right, I suspect the first response to receiving a flood alert=
 is to pick the phone up and call the remainder of your family to check wha=
t precautions they are taking, thus resulting in additional network traffic=
.

Therefore it is likely that 3GPP network operators have to shed traffic whe=
n major alerts are being given. Certain traffic is tagged as having special=
 handling on the wireless part (emergency calls and authority to citizen / =
authority). There are two aspects to this:

-	Can they identify non-essential traffic and discard a larger proportion o=
f this as opposed to essential traffic.

-	Can they ensure that traffic is not duplicated in the first place.

In regard to the ATOCA proposal given above, neither of these are dealt wit=
h in the charter.

In the absence of any mechanisms to identify specific traffic as essential,=
 or to identify such traffic at all, the net result will be that all such t=
raffic will be deemed non-essential and will not be given authority to auth=
ority priority. Conceivably, that means that there will be no alerts at tim=
e of crisis using ATOCA mechanisms because all IP communication except voic=
e over IP, and authority to authority data has been killed. Rather than giv=
e their users a false sense of security that they will receive ATOCA alerts=
 under times of network stress, this may well mean that 3GPP operators acti=
vely discourage ATOCA subscriptions in the first place.

If the alerts that duplicate those made using the cell broadcast service ar=
e not made in the first place, and cellphone users are restricted to target=
ted alerts rather than those for the whole public, then it is possible that=
 3GPP operators will be be able to treat ATOCO alerts differently, rather t=
han killing everything. I don't know how we handle that in RFCs, but that s=
hould form part of the study of providing this mechanism.

Saying "let the market decide" at this point of charter discussion will the=
refore not result in the scenario where coexistence can occur under emergen=
cy overload. The charter needs to investigate means of enhancing coexistenc=
e with other delivery mechanisms, rather than just acknowledging that they =
exist.

regards

Keith

________________________________

	From: [email-masked] [mailto:[email-masked]]=
 On Behalf Of Janet P Gunn
	Sent: Wednesday, April 07, 2010 11:03 PM
	To: SENNETT, DEWAYNE A (ATTCINW)
	Cc: [email-masked]; Hannes Tschofenig; [email-masked]=
g
	Subject: Re: [earlywarning] Finishing the Charter Text Discussions
=09
=09

	I don't have a dog in this fight (and I am not even "working") this week- =
but I can't resist putting in my 2 cents.=20
=09
	1) Typically, the greatest congestion occurs close to the "edges", whether=
 you call it "the access network" or "the last mile".=20
	 =20
	2) There is often (but by no means always) a positive correlation between =
events that trigger both "citizen to authority" and "authority to citizen" =
messages,  and localized network congestion.=20
=09
	3) Any mechanism to support either "citizen to authority" or "authority to=
 citizen" , or "authority to authority", "special" treatment should do so i=
n a manner that does not exacerbate the localized congestion.
=09
	Janet=20
=09
	This is a PRIVATE message. If you are not the intended recipient, please d=
elete without copying and kindly advise us by e-mail of the mistake in deli=
very.=20
	NOTE: Regardless of content, this e-mail shall not operate to bind CSC to =
any order or other contract unless pursuant to explicit written agreement o=
r government initiative expressly permitting the use of e-mail for such pur=
pose.=20
=09
	[email-masked] wrote on 04/07/2010 04:20:38 PM:
=09
	> [image removed]=20
	>=20
	> Re: [earlywarning] Finishing the Charter Text Discussions=20
	>=20
	> SENNETT, DEWAYNE A (ATTCINW)=20
	>=20
	> to:=20
	>=20
	> ken carlberg=20
	>=20
	> 04/07/2010 04:21 PM=20
	>=20
	> Sent by:=20
	>=20
	> [email-masked]=20
	>=20
	> Cc:=20
	>=20
	> Hannes Tschofenig, earlywarning=20
	>=20
	> In regards to the comment on the first sentence, all services have to be
	> evaluated for impact before they are implemented in any live
	> environment.  However, a service that is designed from the beginning
	> with no consideration of the impacts to the access technologies is a
	> very badly designed service.  ATOCA will have an adverse effect to at
	> least some of the access technologies and if ATOCA is designed without
	> any considerations of the capabilities and limitations of the access
	> technologies, it will fail and it will cause adverse effects to the
	> access technologies.
	>=20
	> The proof of network congestion already exists.  This is demonstrated
	> repeatedly as "all circuits busy" error responses, dropped calls,
	> fast-busy tones, delayed delivery of SMS messages, etc.=20
	>=20
	> Since ATOCA is the new communications entity beginning proposed, the
	> burden of proof is on ATOCA to prove that it will not adversely impact
	> any of the associated access technologies.
	>=20
	> DeWayne=20
	>=20
	>=20
	> -----Original Message-----
	> From: [email-masked]
	> [mailto:[email-masked] <mailto:earlywarning-bounces@ietf.=
org> ] On Behalf Of ken carlberg
	> Sent: Wednesday, April 07, 2010 12:48 PM
	> To: SENNETT, DEWAYNE A (ATTCINW)
	> Cc: Hannes Tschofenig; [email-masked]
	> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
	>=20
	>=20
	> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
	>=20
	> > "The ATOCA solutions will not adversely affect the ability of any
	> access
	> > technology to provide emergency services to the citizens (e.g. 9-1-1
	> > calls) or to provide communication services to first responders or
	> other
	> > authorized emergency services personnel.  Additionally, ATOCA is not
	> > replacement solution for any authority to citizen alerting supported
	> by
	> > any access technology."
	>=20
	> given the previous thread on this list, I'm a bit leery of that first
	> sentence.  But, if it were agreed to add it in, then I would expect the
	> individuals who make a claim that an ATOCA solution adversely affects
	> 9-1-1 type calls will be required to prove it instead of simply stating
	> a position.
	>=20
	> as for the second sentence, that is out of scope of the IETF.  any
	> deployment of what is considered an ATOCA solution is a market decision.
	>=20
	> -ken
	>=20
	> _______________________________________________
	> earlywarning mailing list
	> [email-masked]
	> https://www.ietf.org/mailman/listinfo/earlywarning <https://www.ietf.org=
/mailman/listinfo/earlywarning>=20
	> _______________________________________________
	> earlywarning mailing list
	> [email-masked]
	> https://www.ietf.org/mailman/listinfo/earlywarning <https://www.ietf.org=
/mailman/listinfo/earlywarning>=20
=09

From: "DRAGE, Keith (Keith)" <[email-masked]>
To: Hannes Tschofenig <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 8 Apr 2010 11:59:10 +0200
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

A couple of minor comments in this message:

> for location x' (previously determined as the location of interest).=20
> This work builds on existing IETF geopriv location work.=20

This sentence left me wondering, as the key aspect of the GEOPRIV work, rat=
her than location, was privacy. There is therefore no point in my view in m=
entioning geopriv unless there is some explained privacy aspect. At the mom=
ent I do not see that explained.=09
=20
> encoding of alerts.  OGC, ATIS, TIA, ITU-T, ETSI and 3GPP=20
> also have alert efforts underway, and consultation with these=20
> efforts will be undertaken to avoid unnecessary duplication=20
> of effort.=20

There have been two agreed sets of 3GPP work, both of which ARE COMPLETE. T=
hese are ETWS which completed with the freeze of release 8 and PWS which co=
mpleted with the freeze of release 9. When Europe makes a final decision as=
 to what they require from 3GPP networks, then there may well be some more =
work initiated, but there is no active work at the moment that can be contr=
ibuted to. So it is incorrect to say "... 3GPP also have alert efforts unde=
rway...". I suspect the same applies to ATIS and TIA, at least where that w=
ork corresponds to the cell broadcast mechanisms. This of course does not p=
reclude liaison, but do not assume that 3GPP can change a frozen specificat=
ion because of that liaison.

regards

Keith

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Sent: Tuesday, April 06, 2010 12:18 PM
> To: [email-masked]
> Subject: [earlywarning] Finishing the Charter Text Discussions
>=20
> Hi all,=20
>=20
> we had some discussions in response to the charter text I=20
> distributed. I made some minor changes based on the received=20
> comments but most of the discussions seemed (at least to me)=20
> not related to the charter text itself.=20
>=20
> Is the charter text OK for everyone?=20
>=20
> Ciao
> Hannes
>=20
> ----------------
>=20
> Authority to Citizen Alert (ATOCA)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> Authorities need mechanisms to notify citizens and visitors=20
> of emergency
> events.   Traditionally, they have done so with broadcast=20
> networks (radio
> and television).  The Internet provides another way for=20
> authority to citizen alerts to be sent, but it also presents=20
> new challenges. While there are some existing layer 2=20
> mechanisms for delivering alerts the work in this group=20
> focuses on delivering alerts to IP endpoints only.=20
>=20
> The general message pattern that this group is intended to=20
> address is the sending of alerts from a set of pre-authorized=20
> agents (e.g., governmental
> agencies) to a large population. The goal of this group is=20
> not to specify how originators of alerts obtain=20
> authorization, but rather how a messaging system can verify=20
> authorization and deliver message to the intended recipients.=20
> A critical element of the work are the mechanisms that assure=20
> that only authorized agents can send alerts.=20
>=20
> The recipients of these alerts are the wide range of devices=20
> connected to the Internet and private IP networks which=20
> humans may have ?at hand? to get such events, as well as=20
> automatons who may take action based on the alerts.=20
> This implies that the content of the alert contains some=20
> information which is intended to be consumed by humans, and=20
> some which is intended to be consumed by automatons. =20
> Ideally, the alerts would contain, or refer to media other=20
> than text media (e.g., audio and/or video), but the initial=20
> work in the group is focused on small messages, which may be=20
> mechanically rendered by the device in other forms (text to=20
> speech for example). In situations of a major emergency there=20
> could be scenarios where there are multiple alerts generated=20
> that may require that a priority mechanism has to be used.=20
> The work on a resource priority mechanism is out of scope of=20
> the initial charter, but may be revisited at a later date.
>=20
> Which devices should get alerts is primarily driven by=20
> location.  The first set of recipients that must be catered=20
> for are those within the area affected by the alert.  In many=20
> jurisdictions, there are regulations that define whether=20
> recipients within the affected area have opt-in or opt-out=20
> capability, but the protocols we will define will include=20
> both opt-in and opt-out mechanisms. The group will explore=20
> how to support both opt-in and opt-out at the level of=20
> communication protocols.=20
>=20
> Another class of recipients that are in scope of the work are=20
> explicit opt-in subscriptions which ask for alerts for a=20
> specified location.=20
> An example of such a subscription would be 'send me alerts=20
> for location x' (previously determined as the location of interest).=20
> This work builds on existing IETF geopriv location work.=20
>=20
> There are efforts in other fora on early warning, which will=20
> be considered in this effort.  For example, we expect to make=20
> use of the OASIS Common Alerting Protocol (CAP) for the=20
> encoding of alerts.  OGC, ATIS, TIA, ITU-T, ETSI and 3GPP=20
> also have alert efforts underway, and consultation with these=20
> efforts will be undertaken to avoid unnecessary duplication=20
> of effort.=20
> Of course, existing protocols for delivering messages (e.g.,=20
> SIP) will be the basis for the message delivery system of=20
> this working group.
>=20
> The security implications of mechanisms that can send alerts=20
> to billions of devices are profound, but the utility of the=20
> mechanism encourages us to face the problems and solve them.=20
>=20
> Milestones
> =20
> TBD      Initial document for "Terminology and Framework" document.=20
>          A starting point for this work is
>          draft-norreys-ecrit-authority2individuals-requirements.
> TBD      Initial document for conveying alerts in SIP=20
> 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=20
>          draft-rosen-ecrit-lost-early-warning.
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> =

To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Apr 2010 18:03:17 -0400
Cc: [email-masked], Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

This is a multipart message in MIME format.
--=_alternative 00792306852576FE_=
Content-Type: text/plain; charset="US-ASCII"

I don't have a dog in this fight (and I am not even "working") this week- 
but I can't resist putting in my 2 cents.

1) Typically, the greatest congestion occurs close to the "edges", whether 
you call it "the access network" or "the last mile".
 
2) There is often (but by no means always) a positive correlation between 
events that trigger both "citizen to authority" and "authority to citizen" 
messages,  and localized network congestion.

3) Any mechanism to support either "citizen to authority" or "authority to 
citizen" , or "authority to authority", "special" treatment should do so 
in a manner that does not exacerbate the localized congestion.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

[email-masked] wrote on 04/07/2010 04:20:38 PM:

> [image removed] 
> 
> Re: [earlywarning] Finishing the Charter Text Discussions
> 
> SENNETT, DEWAYNE A (ATTCINW) 
> 
> to:
> 
> ken carlberg
> 
> 04/07/2010 04:21 PM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> Hannes Tschofenig, earlywarning
> 
> In regards to the comment on the first sentence, all services have to be
> evaluated for impact before they are implemented in any live
> environment.  However, a service that is designed from the beginning
> with no consideration of the impacts to the access technologies is a
> very badly designed service.  ATOCA will have an adverse effect to at
> least some of the access technologies and if ATOCA is designed without
> any considerations of the capabilities and limitations of the access
> technologies, it will fail and it will cause adverse effects to the
> access technologies.
> 
> The proof of network congestion already exists.  This is demonstrated
> repeatedly as "all circuits busy" error responses, dropped calls,
> fast-busy tones, delayed delivery of SMS messages, etc. 
> 
> Since ATOCA is the new communications entity beginning proposed, the
> burden of proof is on ATOCA to prove that it will not adversely impact
> any of the associated access technologies.
> 
> DeWayne 
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ken carlberg
> Sent: Wednesday, April 07, 2010 12:48 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> 
> 
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
> > "The ATOCA solutions will not adversely affect the ability of any
> access
> > technology to provide emergency services to the citizens (e.g. 9-1-1
> > calls) or to provide communication services to first responders or
> other
> > authorized emergency services personnel.  Additionally, ATOCA is not
> > replacement solution for any authority to citizen alerting supported
> by
> > any access technology."
> 
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect the
> individuals who make a claim that an ATOCA solution adversely affects
> 9-1-1 type calls will be required to prove it instead of simply stating
> a position.
> 
> as for the second sentence, that is out of scope of the IETF.  any
> deployment of what is considered an ATOCA solution is a market decision.
> 
> -ken
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

--=_alternative 00792306852576FE_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">I don't have a dog in this fight (and
I am not even &quot;working&quot;) this week- but I can't resist putting
in my 2 cents.</font>
<br>
<br><font size=2 face="sans-serif">1) Typically, the greatest congestion
occurs close to the &quot;edges&quot;, whether you call it &quot;the access
network&quot; or &quot;the last mile&quot;.</font>
<br><font size=2 face="sans-serif">&nbsp;</font>
<br><font size=2 face="sans-serif">2) There is often (but by no means always)
a positive correlation between events that trigger both &quot;citizen to
authority&quot; and &quot;authority to citizen&quot; messages, &nbsp;and
localized network congestion.</font>
<br>
<br><font size=2 face="sans-serif">3) Any mechanism to support either &quot;citizen
to authority&quot; or &quot;authority to citizen&quot; , or &quot;authority
to authority&quot;, &quot;special&quot; treatment should do so in a manner
that does not exacerbate the localized congestion.<br>
</font>
<br><font size=2 face="sans-serif">Janet</font>
<br><font size=2 face="sans-serif"><br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br><tt><font size=2>[email-masked] wrote on 04/07/2010
04:20:38 PM:<br>
<br>
&gt; [image removed] </font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Re: [earlywarning] Finishing the Charter Text Discussions</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; SENNETT, DEWAYNE A (ATTCINW) </font></tt>
<br><tt><font size=2>&gt; <br>
&gt; to:</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; ken carlberg</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; 04/07/2010 04:21 PM</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Sent by:</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; [email-masked]</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Cc:</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; Hannes Tschofenig, earlywarning</font></tt>
<br><tt><font size=2>&gt; <br>
&gt; In regards to the comment on the first sentence, all services have
to be<br>
&gt; evaluated for impact before they are implemented in any live<br>
&gt; environment. &nbsp;However, a service that is designed from the beginning<br>
&gt; with no consideration of the impacts to the access technologies is
a<br>
&gt; very badly designed service. &nbsp;ATOCA will have an adverse effect
to at<br>
&gt; least some of the access technologies and if ATOCA is designed without<br>
&gt; any considerations of the capabilities and limitations of the access<br>
&gt; technologies, it will fail and it will cause adverse effects to the<br>
&gt; access technologies.<br>
&gt; <br>
&gt; The proof of network congestion already exists. &nbsp;This is demonstrated<br>
&gt; repeatedly as &quot;all circuits busy&quot; error responses, dropped
calls,<br>
&gt; fast-busy tones, delayed delivery of SMS messages, etc. <br>
&gt; <br>
&gt; Since ATOCA is the new communications entity beginning proposed, the<br>
&gt; burden of proof is on ATOCA to prove that it will not adversely impact<br>
&gt; any of the associated access technologies.<br>
&gt; <br>
&gt; DeWayne <br>
&gt; <br>
&gt; <br>
&gt; -----Original Message-----<br>
&gt; From: [email-masked]<br>
&gt; [</font></tt><a href="mailto:[email-masked]"><tt><font size=2>mailto:[email-masked]</font></tt></a><tt><font size=2>]
On Behalf Of ken carlberg<br>
&gt; Sent: Wednesday, April 07, 2010 12:48 PM<br>
&gt; To: SENNETT, DEWAYNE A (ATTCINW)<br>
&gt; Cc: Hannes Tschofenig; [email-masked]<br>
&gt; Subject: Re: [earlywarning] Finishing the Charter Text Discussions<br>
&gt; <br>
&gt; <br>
&gt; On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:<br>
&gt; <br>
&gt; &gt; &quot;The ATOCA solutions will not adversely affect the ability
of any<br>
&gt; access<br>
&gt; &gt; technology to provide emergency services to the citizens (e.g.
9-1-1<br>
&gt; &gt; calls) or to provide communication services to first responders
or<br>
&gt; other<br>
&gt; &gt; authorized emergency services personnel. &nbsp;Additionally,
ATOCA is not<br>
&gt; &gt; replacement solution for any authority to citizen alerting supported<br>
&gt; by<br>
&gt; &gt; any access technology.&quot;<br>
&gt; <br>
&gt; given the previous thread on this list, I'm a bit leery of that first<br>
&gt; sentence. &nbsp;But, if it were agreed to add it in, then I would
expect the<br>
&gt; individuals who make a claim that an ATOCA solution adversely affects<br>
&gt; 9-1-1 type calls will be required to prove it instead of simply stating<br>
&gt; a position.<br>
&gt; <br>
&gt; as for the second sentence, that is out of scope of the IETF. &nbsp;any<br>
&gt; deployment of what is considered an ATOCA solution is a market decision.<br>
&gt; <br>
&gt; -ken<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; earlywarning mailing list<br>
&gt; [email-masked]<br>
&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
&gt; _______________________________________________<br>
&gt; earlywarning mailing list<br>
&gt; [email-masked]<br>
&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
</font></tt>
--=_alternative 00792306852576FE_=--

From: Richard Barnes <[email-masked]>
To: Brian Rosen <[email-masked]>
Date: Wed, 7 Apr 2010 17:56:23 -0400
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Fine with me.

On Apr 7, 2010, at 5:54 PM, Brian Rosen wrote:

> I'm not bothered by the first part.  I don't like the last phrase,  
> because
> I'm not sure we should specifically describe such capabilities, and  
> it may
> not be a gateway.  How about changing the last sentence to "A goal  
> of the
> work will be to be able to use layer-2 specific mechanisms, where  
> available,
> to minimize load on the network."
>
>
> On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:
>
>> Ok, I can grant that that's something that's not clearly explained in
>> the current charter.  However, it's also an issue that will tend to  
>> be
>> layer-2 specific.  How about something like this:
>>
>> "
>> Emergency alerts that are delivered to large numbers of endpoints can
>> put a large load on the network, particularly when many affected  
>> users
>> are on the same local network (e.g., the 100,000 attendees at a
>> sporting event).  This working group will consider mechanisms for
>> minimizing this load, such as IP multicast.  In particular, some
>> approaches have been developed to handle emergency alerting in
>> different types networks, and it will be a goal of this working group
>> to facilitate interoperability with these approaches, for example, to
>> enable gateways to relay messages from this Internet mechanism into a
>> specific layer-2 channel.
>> "
>>
>>
>>
>> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>
>>> It is deficient because it does not take into account the impacts  
>>> that
>>> will occur to the various access technologies.  All access
>>> technologies
>>> do not have the same capacity, bandwidth, etc. Therefore any design
>>> that
>>> has the potential to send information to all citizens within an area
>>> via
>>> any variety of access technologies needs to consider these factors.
>>> For
>>> example, consider the scenario of trying to send an alert to the
>>> 100,000
>>> fans at a college football game.
>>>
>>> The current draft charter of ATOCA does not address this which is  
>>> why
>>> the additional sentences for the second paragraph were proposed.
>>>
>>> DeWayne
>>>
>>> -----Original Message-----
>>> From: Richard Barnes [mailto:[email-masked]]
>>> Sent: Wednesday, April 07, 2010 1:38 PM
>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>>> (ATTLABS); [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>
>>> Could you please clarify how you believe it to be deficient?
>>>
>>>
>>>
>>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>>
>>>> My "personal" view is that the charter as currently written is not
>>>> correct or adequate.
>>>>
>>>> DeWayne
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
>>>> (ATTCINW)
>>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>>> Cc: [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>
>>>> Fine but my "personal" view does not change.
>>>>
>>>> Brian Daly
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Henning Schulzrinne [mailto:[email-masked]]
>>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>>> To: DOLLY, MARTIN C (ATTLABS)
>>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>
>>>> The point is that people speak as individuals in the IETF and there
>>>> is
>>>> no particular notion that a corporate opinion has any more weight
>>>> than
>>>> that of any individual. Thus, stating a corporate opinion is out of
>>>> place and against IETF custom and convention.
>>>>
>>>>
>>>> Henning
>>>>
>>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>>>
>>>>> They sure do, look at everyone's badge
>>>>>
>>>>> ----- Original Message -----
>>>>> From: [email-masked] <earlywarning- 
>>>>> [email-masked]>
>>>>> To: DALY, BRIAN K (ATTCINW)
>>>>> Cc: [email-masked] <[email-masked]>
>>>>> Sent: Wed Apr 07 16:21:20 2010
>>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>>>
>>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>>> IETF
>>>> rules have changed recently?
>>>>>
>>>>> Henning
>>>>>
>>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>>>
>>>>>> For the record, AT&T is in opposition to removing the last
>>>>>> sentence.
>>>>>>
>>>>>> Brian Daly
>>>>>> AT&T
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>
>

Date: Wed, 07 Apr 2010 17:54:56 -0400
From: Brian Rosen <[email-masked]>
To: Richard Barnes <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

I'm not bothered by the first part.  I don't like the last phrase, because
I'm not sure we should specifically describe such capabilities, and it may
not be a gateway.  How about changing the last sentence to "A goal of the
work will be to be able to use layer-2 specific mechanisms, where available,
to minimize load on the network."

On 4/7/10 5:41 PM, "Richard Barnes" <[email-masked]> wrote:

> Ok, I can grant that that's something that's not clearly explained in
> the current charter.  However, it's also an issue that will tend to be
> layer-2 specific.  How about something like this:
> 
> "
> Emergency alerts that are delivered to large numbers of endpoints can
> put a large load on the network, particularly when many affected users
> are on the same local network (e.g., the 100,000 attendees at a
> sporting event).  This working group will consider mechanisms for
> minimizing this load, such as IP multicast.  In particular, some
> approaches have been developed to handle emergency alerting in
> different types networks, and it will be a goal of this working group
> to facilitate interoperability with these approaches, for example, to
> enable gateways to relay messages from this Internet mechanism into a
> specific layer-2 channel.
> "
> 
> 
> 
> On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> It is deficient because it does not take into account the impacts that
>> will occur to the various access technologies.  All access
>> technologies
>> do not have the same capacity, bandwidth, etc. Therefore any design
>> that
>> has the potential to send information to all citizens within an area
>> via
>> any variety of access technologies needs to consider these factors.
>> For
>> example, consider the scenario of trying to send an alert to the
>> 100,000
>> fans at a college football game.
>> 
>> The current draft charter of ATOCA does not address this which is why
>> the additional sentences for the second paragraph were proposed.
>> 
>> DeWayne
>> 
>> -----Original Message-----
>> From: Richard Barnes [mailto:[email-masked]]
>> Sent: Wednesday, April 07, 2010 1:38 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
>> (ATTLABS); [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> 
>> Could you please clarify how you believe it to be deficient?
>> 
>> 
>> 
>> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>> 
>>> My "personal" view is that the charter as currently written is not
>>> correct or adequate.
>>> 
>>> DeWayne
>>> 
>>> 
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
>>> (ATTCINW)
>>> Sent: Wednesday, April 07, 2010 1:33 PM
>>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>>> Cc: [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>> 
>>> Fine but my "personal" view does not change.
>>> 
>>> Brian Daly
>>> 
>>> 
>>> -----Original Message-----
>>> From: Henning Schulzrinne [mailto:[email-masked]]
>>> Sent: Wednesday, April 07, 2010 1:31 PM
>>> To: DOLLY, MARTIN C (ATTLABS)
>>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>> 
>>> The point is that people speak as individuals in the IETF and there
>>> is
>>> no particular notion that a corporate opinion has any more weight
>>> than
>>> that of any individual. Thus, stating a corporate opinion is out of
>>> place and against IETF custom and convention.
>>> 
>>> 
>>> Henning
>>> 
>>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>> 
>>>> They sure do, look at everyone's badge
>>>> 
>>>> ----- Original Message -----
>>>> From: [email-masked] <[email-masked]>
>>>> To: DALY, BRIAN K (ATTCINW)
>>>> Cc: [email-masked] <[email-masked]>
>>>> Sent: Wed Apr 07 16:21:20 2010
>>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>> 
>>>> I didn't know that the IETF had corporate opinions. But maybe the
>>>> IETF
>>> rules have changed recently?
>>>> 
>>>> Henning
>>>> 
>>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>> 
>>>>> For the record, AT&T is in opposition to removing the last
>>>>> sentence.
>>>>> 
>>>>> Brian Daly
>>>>> AT&T
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
From: Janet P Gunn <[email-masked]>
Date: Wed, 7 Apr 2010 17:46:05 -0400
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, [email-masked], Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

This is a multipart message in MIME format.
--=_alternative 00776BD4852576FE_=
Content-Type: text/plain; charset="US-ASCII"

I think that the relative priority of "citizen to authority", "authority 
to citizen", "authority to authority",  and even "citizen to citizen" 
needs to be a matter of "local policy", and independent of any IETF 
defined mechanism.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.

From:
"DALY, BRIAN K (ATTCINW)" <[email-masked]>
To:
"Brian Rosen" <[email-masked]>, "ken carlberg" <[email-masked]>, 
"SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc:
Hannes Tschofenig <[email-masked]>, [email-masked]
Date:
04/07/2010 04:06 PM
Subject:
Re: [earlywarning] Finishing the Charter Text Discussions

Absolutely false!!

You have no clue what the incoming emergency call is about - it could be
a kitty in the tree call, as you put it, or it could be "I just had a
heart attack and need help immediately".

An authority to citizen "call" should never take priority over a citizen
to authority, and this is regulated ni the FCC rules for CMAS.

And your typhoon analogy proves the point - a typhoon is known several
days in advance, while you have minutes to take action on a heart
attack.

Brian Daly

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, April 07, 2010 1:00 PM
To: ken carlberg; SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Generally, it's not a good idea for any service to impede any other
service,
but we don't have to say that all the time.  Here, I think we don't have
to
discuss how authority to citizen should be prioritized over citizen to
authority.  I rather suspect that an outgoing warning of an impending
typhoon is more important that an incoming kitty-in-the-tree call, but
maybe
that's just me.

ATOCA may or may not be a replacement for something that exists.  Agree
with
Ken, the market (and in this case, likely governments) will decide.

So I would not want to see this text in the charter.

Brian

On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:

> 
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> "The ATOCA solutions will not adversely affect the ability of any
access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
by
>> any access technology."
> 
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect
the
> individuals who make a claim that an ATOCA solution adversely affects
9-1-1
> type calls will be required to prove it instead of simply stating a
position.
> 
> as for the second sentence, that is out of scope of the IETF.  any
deployment
> of what is considered an ATOCA solution is a market decision.
> 
> -ken
> 
> _______________________________________________
> 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

--=_alternative 00776BD4852576FE_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2 face="sans-serif">I think that the relative priority of
&quot;citizen to authority&quot;, &quot;authority to citizen&quot;, &quot;authority
to authority&quot;, &nbsp;and even &quot;citizen to citizen&quot; needs
to be a matter of &quot;local policy&quot;, and independent of any IETF
defined mechanism.</font>
<br>
<br><font size=2 face="sans-serif">Janet<br>
<br>
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. <br>
NOTE: Regardless of content, this e-mail shall not operate to bind CSC
to any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose.</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">&quot;DALY, BRIAN K (ATTCINW)&quot;
&lt;[email-masked]&gt;</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">&quot;Brian Rosen&quot; &lt;[email-masked]&gt;,
&quot;ken carlberg&quot; &lt;[email-masked]&gt;, &quot;SENNETT, DEWAYNE
A (ATTCINW)&quot; &lt;[email-masked]&gt;</font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">Hannes Tschofenig &lt;[email-masked]&gt;,
[email-masked]</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">04/07/2010 04:06 PM</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [earlywarning] Finishing the Charter
Text Discussions</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Absolutely false!!<br>
<br>
You have no clue what the incoming emergency call is about - it could be<br>
a kitty in the tree call, as you put it, or it could be &quot;I just had
a<br>
heart attack and need help immediately&quot;.<br>
<br>
An authority to citizen &quot;call&quot; should never take priority over
a citizen<br>
to authority, and this is regulated ni the FCC rules for CMAS.<br>
<br>
And your typhoon analogy proves the point - a typhoon is known several<br>
days in advance, while you have minutes to take action on a heart<br>
attack.<br>
<br>
Brian Daly<br>
<br>
-----Original Message-----<br>
From: [email-masked]<br>
[</font></tt><a href="mailto:[email-masked]"><tt><font size=2>mailto:[email-masked]</font></tt></a><tt><font size=2>]
On Behalf Of Brian Rosen<br>
Sent: Wednesday, April 07, 2010 1:00 PM<br>
To: ken carlberg; SENNETT, DEWAYNE A (ATTCINW)<br>
Cc: Hannes Tschofenig; [email-masked]<br>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions<br>
<br>
Generally, it's not a good idea for any service to impede any other<br>
service,<br>
but we don't have to say that all the time. &nbsp;Here, I think we don't
have<br>
to<br>
discuss how authority to citizen should be prioritized over citizen to<br>
authority. &nbsp;I rather suspect that an outgoing warning of an impending<br>
typhoon is more important that an incoming kitty-in-the-tree call, but<br>
maybe<br>
that's just me.<br>
<br>
ATOCA may or may not be a replacement for something that exists. &nbsp;Agree<br>
with<br>
Ken, the market (and in this case, likely governments) will decide.<br>
<br>
So I would not want to see this text in the charter.<br>
<br>
Brian<br>
<br>
<br>
On 4/7/10 3:48 PM, &quot;ken carlberg&quot; &lt;[email-masked]&gt;
wrote:<br>
<br>
&gt; <br>
&gt; On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:<br>
&gt; <br>
&gt;&gt; &quot;The ATOCA solutions will not adversely affect the ability
of any<br>
access<br>
&gt;&gt; technology to provide emergency services to the citizens (e.g.
9-1-1<br>
&gt;&gt; calls) or to provide communication services to first responders
or<br>
other<br>
&gt;&gt; authorized emergency services personnel. &nbsp;Additionally, ATOCA
is not<br>
&gt;&gt; replacement solution for any authority to citizen alerting supported<br>
by<br>
&gt;&gt; any access technology.&quot;<br>
&gt; <br>
&gt; given the previous thread on this list, I'm a bit leery of that first<br>
&gt; sentence. &nbsp;But, if it were agreed to add it in, then I would
expect<br>
the<br>
&gt; individuals who make a claim that an ATOCA solution adversely affects<br>
9-1-1<br>
&gt; type calls will be required to prove it instead of simply stating
a<br>
position.<br>
&gt; <br>
&gt; as for the second sentence, that is out of scope of the IETF. &nbsp;any<br>
deployment<br>
&gt; of what is considered an ATOCA solution is a market decision.<br>
&gt; <br>
&gt; -ken<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; earlywarning mailing list<br>
&gt; [email-masked]<br>
&gt; </font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
<br>
<br>
_______________________________________________<br>
earlywarning mailing list<br>
[email-masked]<br>
</font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
_______________________________________________<br>
earlywarning mailing list<br>
[email-masked]<br>
</font></tt><a href=https://www.ietf.org/mailman/listinfo/earlywarning><tt><font size=2>https://www.ietf.org/mailman/listinfo/earlywarning</font></tt></a><tt><font size=2><br>
</font></tt>
<br>
<br>
--=_alternative 00776BD4852576FE_=--

From: Richard Barnes <[email-masked]>
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 17:41:46 -0400
Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Ok, I can grant that that's something that's not clearly explained in  
the current charter.  However, it's also an issue that will tend to be  
layer-2 specific.  How about something like this:

"
Emergency alerts that are delivered to large numbers of endpoints can  
put a large load on the network, particularly when many affected users  
are on the same local network (e.g., the 100,000 attendees at a  
sporting event).  This working group will consider mechanisms for  
minimizing this load, such as IP multicast.  In particular, some  
approaches have been developed to handle emergency alerting in  
different types networks, and it will be a goal of this working group  
to facilitate interoperability with these approaches, for example, to  
enable gateways to relay messages from this Internet mechanism into a  
specific layer-2 channel.
"

On Apr 7, 2010, at 4:47 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> It is deficient because it does not take into account the impacts that
> will occur to the various access technologies.  All access  
> technologies
> do not have the same capacity, bandwidth, etc. Therefore any design  
> that
> has the potential to send information to all citizens within an area  
> via
> any variety of access technologies needs to consider these factors.   
> For
> example, consider the scenario of trying to send an alert to the  
> 100,000
> fans at a college football game.
>
> The current draft charter of ATOCA does not address this which is why
> the additional sentences for the second paragraph were proposed.
>
> DeWayne
>
> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:38 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
> (ATTLABS); [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> Could you please clarify how you believe it to be deficient?
>
>
>
> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>
>> My "personal" view is that the charter as currently written is not
>> correct or adequate.
>>
>> DeWayne
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
>> (ATTCINW)
>> Sent: Wednesday, April 07, 2010 1:33 PM
>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>> Cc: [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>> Fine but my "personal" view does not change.
>>
>> Brian Daly
>>
>>
>> -----Original Message-----
>> From: Henning Schulzrinne [mailto:[email-masked]]
>> Sent: Wednesday, April 07, 2010 1:31 PM
>> To: DOLLY, MARTIN C (ATTLABS)
>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>> The point is that people speak as individuals in the IETF and there  
>> is
>> no particular notion that a corporate opinion has any more weight  
>> than
>> that of any individual. Thus, stating a corporate opinion is out of
>> place and against IETF custom and convention.
>>
>>
>> Henning
>>
>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>>
>>> They sure do, look at everyone's badge
>>>
>>> ----- Original Message -----
>>> From: [email-masked] <[email-masked]>
>>> To: DALY, BRIAN K (ATTCINW)
>>> Cc: [email-masked] <[email-masked]>
>>> Sent: Wed Apr 07 16:21:20 2010
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>>
>>> I didn't know that the IETF had corporate opinions. But maybe the
>>> IETF
>> rules have changed recently?
>>>
>>> Henning
>>>
>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>>
>>>> For the record, AT&T is in opposition to removing the last  
>>>> sentence.
>>>>
>>>> Brian Daly
>>>> AT&T
>>>
>>> _______________________________________________
>>> 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
>

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 14:29:10 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "James M. Polk" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

In response to " If someone doesn't implement what the IETF specifies in
ATOCA, then they don't implement it. We let the market decide -- of
course where jurisdictions allow'

Why not develop a charter and ultimately a protocol that makes sense and
everyone can live with, which will increase the likelihood of it being
used, rather than developing a service with blinders on thus making it
more likely it will not be adopted?

Brian

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Wednesday, April 07, 2010 2:22 PM
To: SENNETT, DEWAYNE A (ATTCINW); Hannes Tschofenig;
[email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

At 10:30 AM 4/7/2010, SENNETT, DEWAYNE A (ATTCINW) wrote:
>Hi Hannes,
>
>Based upon the previous email decisions, changes to the charter text
are
>still needed.
>
>The second paragraph of the charter provides a high level purpose and
>scope for the ATOCA work.  The following should be added to the end of
>the second paragraph to provide further clarification on the purpose
and
>scope of the ATOCA work:
>
>"The ATOCA solutions will not adversely affect the ability of any
access
>technology to provide emergency services to the citizens (e.g. 9-1-1
>calls) or to provide communication services to first responders or
other
>authorized emergency services personnel.

The above sentence is troubling to me too.  Take the old adage "one=20
man's victory is another man's defeat". In that - I mean -- who's to=20
say that an ATOCA (layer 3-7) solution adversely affects a layer 2=20
solution (existing or planned)?  This is nearly always in the eyes of=20
the beholder.  The IETF, for the most part, deals only with layers=20
3-7, and leaves lower layer solutions to other SDOs. The classic=20
example is wrt IEEE.

Put another way - if you are a proponent of the WARN act, you like=20
the 140 character limitation for any message.  Most of us in the IETF=20
feel that's too limiting, and believe we can create something that is=20
much more useful.  Now, anyone that MUST be in compliance with the=20
WARN act needs to support at least the 140 character limitation. Does=20
that mean there can be no other communication with a richer set of
information?

Some might say that idea alone "adversely affect an access=20
technology" because who implements both are taking on increased
complexity.

Is that a reason to stop progress?

In the 50s the railroad industry tried to prevent the airline=20
industry from becoming certified, at least in the US.  The rail=20
industry say the airline industry as a threat.  Now, was that effort=20
good for anyone?

If someone doesn't implement what the IETF specifies in ATOCA, then=20
they don't implement it. We let the market decide -- of course where=20
jurisdictions allow.

I am opposed to the suggested change to the charter.

James

>Additionally, ATOCA is not
>replacement solution for any authority to citizen alerting supported by
>any access technology."
>
>Regards,
>
>DeWayne A. Sennett
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>Sent: Tuesday, April 06, 2010 4:18 AM
>To: [email-masked]
>Subject: [earlywarning] Finishing the Charter Text Discussions
>
>Hi all,
>
>we had some discussions in response to the charter text I distributed.
I
>made some minor changes based on the received comments but most of the
>discussions seemed (at least to me) not related to the charter text
>itself.
>
>Is the charter text OK for everyone?
>
>Ciao
>Hannes
>
>----------------
>
>Authority to Citizen Alert (ATOCA)
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>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 are the 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 the device 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 used. The work on a resource priority mechanism is out of scope of
>the
>initial charter, but may be revisited at a later date.
>
>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 for a specified location.
>An example of such a subscription would be 'send me alerts for
>location x' (previously determined as the location of interest).
>This work builds on existing IETF geopriv location work.
>
>There are efforts in other fora on early warning, 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.  OGC, 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.
>
>_______________________________________________
>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: Wed, 07 Apr 2010 17:22:42 -0400
From: Brian Rosen <[email-masked]>
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, Richard Barnes <[email-masked]>
Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

But your proposed text doesn't say that: it addresses other services, and
other solutions, not the impact of this (new) service on the network.

Brian

On 4/7/10 4:47 PM, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]> wrote:

> It is deficient because it does not take into account the impacts that
> will occur to the various access technologies.  All access technologies
> do not have the same capacity, bandwidth, etc. Therefore any design that
> has the potential to send information to all citizens within an area via
> any variety of access technologies needs to consider these factors.  For
> example, consider the scenario of trying to send an alert to the 100,000
> fans at a college football game.
> 
> The current draft charter of ATOCA does not address this which is why
> the additional sentences for the second paragraph were proposed.
> 
> DeWayne
> 
> -----Original Message-----
> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:38 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
> (ATTLABS); [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> 
> Could you please clarify how you believe it to be deficient?
> 
> 
> 
> On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> My "personal" view is that the charter as currently written is not
>> correct or adequate.
>> 
>> DeWayne
>> 
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
>> (ATTCINW)
>> Sent: Wednesday, April 07, 2010 1:33 PM
>> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
>> Cc: [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> 
>> Fine but my "personal" view does not change.
>> 
>> Brian Daly
>> 
>> 
>> -----Original Message-----
>> From: Henning Schulzrinne [mailto:[email-masked]]
>> Sent: Wednesday, April 07, 2010 1:31 PM
>> To: DOLLY, MARTIN C (ATTLABS)
>> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> 
>> The point is that people speak as individuals in the IETF and there is
>> no particular notion that a corporate opinion has any more weight than
>> that of any individual. Thus, stating a corporate opinion is out of
>> place and against IETF custom and convention.
>> 
>> 
>> Henning
>> 
>> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>> 
>>> They sure do, look at everyone's badge
>>> 
>>> ----- Original Message -----
>>> From: [email-masked] <[email-masked]>
>>> To: DALY, BRIAN K (ATTCINW)
>>> Cc: [email-masked] <[email-masked]>
>>> Sent: Wed Apr 07 16:21:20 2010
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>> 
>>> I didn't know that the IETF had corporate opinions. But maybe the
>>> IETF
>> rules have changed recently?
>>> 
>>> Henning
>>> 
>>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>> 
>>>> For the record, AT&T is in opposition to removing the last sentence.
>>>> 
>>>> Brian Daly
>>>> AT&T
>>> 
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Wed, 07 Apr 2010 16:22:27 -0500
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>, "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
From: "James M. Polk" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

At 10:30 AM 4/7/2010, SENNETT, DEWAYNE A (ATTCINW) wrote:
>Hi Hannes,
>
>Based upon the previous email decisions, changes to the charter text are
>still needed.
>
>The second paragraph of the charter provides a high level purpose and
>scope for the ATOCA work.  The following should be added to the end of
>the second paragraph to provide further clarification on the purpose and
>scope of the ATOCA work:
>
>"The ATOCA solutions will not adversely affect the ability of any access
>technology to provide emergency services to the citizens (e.g. 9-1-1
>calls) or to provide communication services to first responders or other
>authorized emergency services personnel.

The above sentence is troubling to me too.  Take the old adage "one 
man's victory is another man's defeat". In that - I mean -- who's to 
say that an ATOCA (layer 3-7) solution adversely affects a layer 2 
solution (existing or planned)?  This is nearly always in the eyes of 
the beholder.  The IETF, for the most part, deals only with layers 
3-7, and leaves lower layer solutions to other SDOs. The classic 
example is wrt IEEE.

Put another way - if you are a proponent of the WARN act, you like 
the 140 character limitation for any message.  Most of us in the IETF 
feel that's too limiting, and believe we can create something that is 
much more useful.  Now, anyone that MUST be in compliance with the 
WARN act needs to support at least the 140 character limitation. Does 
that mean there can be no other communication with a richer set of information?

Some might say that idea alone "adversely affect an access 
technology" because who implements both are taking on increased complexity.

Is that a reason to stop progress?

In the 50s the railroad industry tried to prevent the airline 
industry from becoming certified, at least in the US.  The rail 
industry say the airline industry as a threat.  Now, was that effort 
good for anyone?

If someone doesn't implement what the IETF specifies in ATOCA, then 
they don't implement it. We let the market decide -- of course where 
jurisdictions allow.

I am opposed to the suggested change to the charter.

James

>Additionally, ATOCA is not
>replacement solution for any authority to citizen alerting supported by
>any access technology."
>
>Regards,
>
>DeWayne A. Sennett
>
>
>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
>Sent: Tuesday, April 06, 2010 4:18 AM
>To: [email-masked]
>Subject: [earlywarning] Finishing the Charter Text Discussions
>
>Hi all,
>
>we had some discussions in response to the charter text I distributed. I
>made some minor changes based on the received comments but most of the
>discussions seemed (at least to me) not related to the charter text
>itself.
>
>Is the charter text OK for everyone?
>
>Ciao
>Hannes
>
>----------------
>
>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 are the 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 the device 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 used. The work on a resource priority mechanism is out of scope of
>the
>initial charter, but may be revisited at a later date.
>
>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 for a specified location.
>An example of such a subscription would be 'send me alerts for
>location x' (previously determined as the location of interest).
>This work builds on existing IETF geopriv location work.
>
>There are efforts in other fora on early warning, 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.  OGC, 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.
>
>_______________________________________________
>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: Wed, 07 Apr 2010 16:09:22 -0500
To: Henning Schulzrinne <[email-masked]>, "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
From: "James M. Polk" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

At 03:30 PM 4/7/2010, Henning Schulzrinne wrote:
>The point is that people speak as individuals in the IETF and there 
>is no particular notion that a corporate opinion has any more weight 
>than that of any individual. Thus, stating a corporate opinion is 
>out of place and against IETF custom and convention.

+1

>Henning
>
>On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>
> > They sure do, look at everyone's badge

not everyone at the IETF is employed, so this position is not universal

James

> >
> > ----- Original Message -----
> > From: [email-masked] <[email-masked]>
> > To: DALY, BRIAN K (ATTCINW)
> > Cc: [email-masked] <[email-masked]>
> > Sent: Wed Apr 07 16:21:20 2010
> > Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> >
> > I didn't know that the IETF had corporate opinions. But maybe the 
> IETF rules have changed recently?
> >
> > Henning
> >
> > On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
> >
> >> For the record, AT&T is in opposition to removing the last sentence.
> >>
> >> Brian Daly
> >> AT&T
> >
> > _______________________________________________
> > 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: Wed, 7 Apr 2010 13:47:57 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "Richard Barnes" <[email-masked]>
Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

It is deficient because it does not take into account the impacts that
will occur to the various access technologies.  All access technologies
do not have the same capacity, bandwidth, etc. Therefore any design that
has the potential to send information to all citizens within an area via
any variety of access technologies needs to consider these factors.  For
example, consider the scenario of trying to send an alert to the 100,000
fans at a college football game.

The current draft charter of ATOCA does not address this which is why
the additional sentences for the second paragraph were proposed.=20

DeWayne

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]]=20
Sent: Wednesday, April 07, 2010 1:38 PM
To: SENNETT, DEWAYNE A (ATTCINW)
Cc: DALY, BRIAN K (ATTCINW); Henning Schulzrinne; DOLLY, MARTIN C
(ATTLABS); [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Could you please clarify how you believe it to be deficient?

On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> My "personal" view is that the charter as currently written is not
> correct or adequate.
>
> DeWayne
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
> (ATTCINW)
> Sent: Wednesday, April 07, 2010 1:33 PM
> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
> Cc: [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> Fine but my "personal" view does not change.
>
> Brian Daly
>
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:31 PM
> To: DOLLY, MARTIN C (ATTLABS)
> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> The point is that people speak as individuals in the IETF and there is
> no particular notion that a corporate opinion has any more weight than
> that of any individual. Thus, stating a corporate opinion is out of
> place and against IETF custom and convention.
>
>
> Henning
>
> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>
>> They sure do, look at everyone's badge
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: DALY, BRIAN K (ATTCINW)
>> Cc: [email-masked] <[email-masked]>
>> Sent: Wed Apr 07 16:21:20 2010
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>> I didn't know that the IETF had corporate opinions. But maybe the =20
>> IETF
> rules have changed recently?
>>
>> Henning
>>
>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>
>>> For the record, AT&T is in opposition to removing the last sentence.
>>>
>>> Brian Daly
>>> AT&T
>>
>> _______________________________________________
>> 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

From: Richard Barnes <[email-masked]>
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 16:37:55 -0400
Cc: [email-masked], "DOLLY, MARTIN C \(ATTLABS\)" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Could you please clarify how you believe it to be deficient?

On Apr 7, 2010, at 4:37 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> My "personal" view is that the charter as currently written is not
> correct or adequate.
>
> DeWayne
>
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of DALY, BRIAN K
> (ATTCINW)
> Sent: Wednesday, April 07, 2010 1:33 PM
> To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
> Cc: [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> Fine but my "personal" view does not change.
>
> Brian Daly
>
>
> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:31 PM
> To: DOLLY, MARTIN C (ATTLABS)
> Cc: DALY, BRIAN K (ATTCINW); [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> The point is that people speak as individuals in the IETF and there is
> no particular notion that a corporate opinion has any more weight than
> that of any individual. Thus, stating a corporate opinion is out of
> place and against IETF custom and convention.
>
>
> Henning
>
> On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:
>
>> They sure do, look at everyone's badge
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: DALY, BRIAN K (ATTCINW)
>> Cc: [email-masked] <[email-masked]>
>> Sent: Wed Apr 07 16:21:20 2010
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>> I didn't know that the IETF had corporate opinions. But maybe the  
>> IETF
> rules have changed recently?
>>
>> Henning
>>
>> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>>
>>> For the record, AT&T is in opposition to removing the last sentence.
>>>
>>> Brian Daly
>>> AT&T
>>
>> _______________________________________________
>> 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

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 13:37:01 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, "Henning Schulzrinne" <[email-masked]>, "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

My "personal" view is that the charter as currently written is not
correct or adequate.

DeWayne=20

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of DALY, BRIAN K
(ATTCINW)
Sent: Wednesday, April 07, 2010 1:33 PM
To: Henning Schulzrinne; DOLLY, MARTIN C (ATTLABS)
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Fine but my "personal" view does not change.

Brian Daly

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]=20
Sent: Wednesday, April 07, 2010 1:31 PM
To: DOLLY, MARTIN C (ATTLABS)
Cc: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The point is that people speak as individuals in the IETF and there is
no particular notion that a corporate opinion has any more weight than
that of any individual. Thus, stating a corporate opinion is out of
place and against IETF custom and convention.

Henning

On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:

> They sure do, look at everyone's badge
>=20
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked] <[email-masked]>
> Sent: Wed Apr 07 16:21:20 2010
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
> I didn't know that the IETF had corporate opinions. But maybe the IETF
rules have changed recently?
>=20
> Henning
>=20
> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>=20
>> For the record, AT&T is in opposition to removing the last sentence.
>>=20
>> Brian Daly
>> AT&T
>=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 Barnes <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Date: Wed, 7 Apr 2010 16:35:36 -0400
Cc: "SENNETT, DEWAYNE A \(ATTCINW\)" <[email-masked]>, Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Could you clarify how ATOCA "contradicts" these rules?

Isn't that kind of like saying that SIP contradicts XMPP?  The idea of  
ATOCA is to build a system with some different features than CMAS,  
that is still generally interoperable with it.  SIP has much better  
support for lots of PSTN-replacement stuff than XMPP, and conversely  
XMPP can be a lot simpler to use inter-domain, but you can still pass  
IMs and dialogues from one to another.  Likewise, we expect the ATOCA  
system to meet a different set of trade-offs than CMAS, but still  
allow alerts to move back and forth.

--Richard

On Apr 7, 2010, at 4:21 PM, DALY, BRIAN K (ATTCINW) wrote:

> We are just stating that ATOCA contradicts the CMAS (& EAS) rules, as
> well as iPAWS and DMOpen architectures, and thus is in a different
> class. Thus we believe we do need to be up front in the charter and  
> nto
> to confuse the industry.
>
> Brian
>
> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:18 PM
> To: DALY, BRIAN K (ATTCINW); ken carlberg; SENNETT, DEWAYNE A  
> (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>
> In what way would any RFC not have to meet that requirement?
>
> I understand that you are concerned that this work overlaps layer 2
> specific
> solutions.  However, there is no need to explicitly put this work in
> second
> class.  It's not going to affect any words in a protocol  
> specification.
> If
> there is a regulatory requirement that makes ATOCA compliant
> implementations, like any other service, subservient in some way to  
> some
> other service, so be it.  The charter, and the spec, don't need to say
> that;
> it's always true.
>
> Brian
>
>
>
>
> On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
>
>> The second is more than a market decision - it is an interaction with
> a
>> regulatory requirement.
>>
>> Perhaps a better way to phrase is as follows:
>>
>> "Additionally, ATOCA will not interfere with nor replace solutions
>> designed to meet regulatory requirements for any authority to citizen
>> alerting of any access technology."
>>
>> Brian Daly
>> AT&T
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ken carlberg
>> Sent: Wednesday, April 07, 2010 12:48 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: Hannes Tschofenig; [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>
>>
>> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>
>>> "The ATOCA solutions will not adversely affect the ability of any
>> access
>>> technology to provide emergency services to the citizens (e.g. 9-1-1
>>> calls) or to provide communication services to first responders or
>> other
>>> authorized emergency services personnel.  Additionally, ATOCA is not
>>> replacement solution for any authority to citizen alerting supported
>> by
>>> any access technology."
>>
>> given the previous thread on this list, I'm a bit leery of that first
>> sentence.  But, if it were agreed to add it in, then I would expect
> the
>> individuals who make a claim that an ATOCA solution adversely affects
>> 9-1-1 type calls will be required to prove it instead of simply
> stating
>> a position.
>>
>> as for the second sentence, that is out of scope of the IETF.  any
>> deployment of what is considered an ATOCA solution is a market
> decision.
>>
>> -ken
>>
>> _______________________________________________
>> 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

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 13:33:51 -0700
From: "MUSGROVE, CHARLES P (ATTCINW)" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>, "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Folks,

I agree with the proposed text additions to the charter as amended by
Brian Daly.

Peter Musgrove

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Henning Schulzrinne
Sent: Wednesday, April 07, 2010 1:31 PM
To: DOLLY, MARTIN C (ATTLABS)
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The point is that people speak as individuals in the IETF and there is
no particular notion that a corporate opinion has any more weight than
that of any individual. Thus, stating a corporate opinion is out of
place and against IETF custom and convention.

Henning

On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:

> They sure do, look at everyone's badge
>=20
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked] <[email-masked]>
> Sent: Wed Apr 07 16:21:20 2010
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
> I didn't know that the IETF had corporate opinions. But maybe the IETF
rules have changed recently?
>=20
> Henning
>=20
> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>=20
>> For the record, AT&T is in opposition to removing the last sentence.
>>=20
>> Brian Daly
>> AT&T
>=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: Wed, 7 Apr 2010 13:32:51 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>, "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Fine but my "personal" view does not change.

Brian Daly

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]=20
Sent: Wednesday, April 07, 2010 1:31 PM
To: DOLLY, MARTIN C (ATTLABS)
Cc: DALY, BRIAN K (ATTCINW); [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The point is that people speak as individuals in the IETF and there is
no particular notion that a corporate opinion has any more weight than
that of any individual. Thus, stating a corporate opinion is out of
place and against IETF custom and convention.

Henning

On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:

> They sure do, look at everyone's badge
>=20
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked] <[email-masked]>
> Sent: Wed Apr 07 16:21:20 2010
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
> I didn't know that the IETF had corporate opinions. But maybe the IETF
rules have changed recently?
>=20
> Henning
>=20
> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>=20
>> For the record, AT&T is in opposition to removing the last sentence.
>>=20
>> Brian Daly
>> AT&T
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:30:57 -0400
To: "DOLLY, MARTIN C (ATTLABS)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The point is that people speak as individuals in the IETF and there is =
no particular notion that a corporate opinion has any more weight than =
that of any individual. Thus, stating a corporate opinion is out of =
place and against IETF custom and convention.

Henning

On Apr 7, 2010, at 4:28 PM, DOLLY, MARTIN C (ATTLABS) wrote:

> They sure do, look at everyone's badge
>=20
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked] <[email-masked]>
> Sent: Wed Apr 07 16:21:20 2010
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
> I didn't know that the IETF had corporate opinions. But maybe the IETF =
rules have changed recently?
>=20
> Henning
>=20
> On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:
>=20
>> For the record, AT&T is in opposition to removing the last sentence.
>>=20
>> Brian Daly
>> AT&T
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Date: Wed, 07 Apr 2010 16:30:26 -0400
From: Marc Linsner <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Brian,

>From 
http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-281433A1.pdf

"Wireless carriers that choose to participate"

Or
http://www.fcc.gov/cgb/consumerfacts/cmas.html

"wireless service providers that voluntarily choose to participate in CMAS"

I take that to mean wireless carriers could chose not to participate, hence
the decision to participate is driven by something other than regulatory
requirement.

It's good that ATOCA doesn't fall under the FCC rules.  The hope is that a
ATOCA solution would be far more functional than any regulatory requirement.

-Marc-

On 4/7/10 4:17 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> The opt-in was not a market decision - I disagree. It was a
> congressional and FCC mandate stemmed from the WARN Act resulting in the
> FCC Part 10 rules.
> 
> ATOCA does not fall under that.
> 
> Brian
> 
> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:15 PM
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> 
> The opt-in was a market decision, not a requirement.
> 
> If ATOCA builds a different solution, it too will be a market decision
> to
> offer or not.
> 
> -Marc-
> 
> 
> On 4/7/10 4:09 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> 
>> But those operators that opt-in must follow the FCC Part 10 rules for
>> CMAS. So I do nto understand your comment.
>> 
>> Brian
>> 
>> -----Original Message-----
>> From: Marc Linsner [mailto:[email-masked]]
>> Sent: Wednesday, April 07, 2010 1:08 PM
>> To: DALY, BRIAN K (ATTCINW)
>> Cc: [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> 
>> CMAS was opt-in by the carriers, not a requirement....??
>> 
>> -Marc-
>> 
>> 
>> On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
>> 
>>> The second is more than a market decision - it is an interaction with
>> a
>>> regulatory requirement.
>>> 
>>> Perhaps a better way to phrase is as follows:
>>> 
>>> "Additionally, ATOCA will not interfere with nor replace solutions
>>> designed to meet regulatory requirements for any authority to citizen
>>> alerting of any access technology."
>>> 
>>> Brian Daly
>>> AT&T
>>> 
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of ken carlberg
>>> Sent: Wednesday, April 07, 2010 12:48 PM
>>> To: SENNETT, DEWAYNE A (ATTCINW)
>>> Cc: Hannes Tschofenig; [email-masked]
>>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>> 
>>> 
>>> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>> 
>>>> "The ATOCA solutions will not adversely affect the ability of any
>>> access
>>>> technology to provide emergency services to the citizens (e.g. 9-1-1
>>>> calls) or to provide communication services to first responders or
>>> other
>>>> authorized emergency services personnel.  Additionally, ATOCA is not
>>>> replacement solution for any authority to citizen alerting supported
>>> by
>>>> any access technology."
>>> 
>>> given the previous thread on this list, I'm a bit leery of that first
>>> sentence.  But, if it were agreed to add it in, then I would expect
>> the
>>> individuals who make a claim that an ATOCA solution adversely affects
>>> 9-1-1 type calls will be required to prove it instead of simply
>> stating
>>> a position.
>>> 
>>> as for the second sentence, that is out of scope of the IETF.  any
>>> deployment of what is considered an ATOCA solution is a market
>> decision.
>>> 
>>> -ken
>>> 
>>> _______________________________________________
>>> 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: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:24:52 -0400
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

I gather you'd also require each new web site to get permission from =
AT&T, given that it can have an adverse effect? I didn't know the =
appellate decision on network neutrality would have an effect quite as =
quickly :-)

Henning

On Apr 7, 2010, at 4:20 PM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> In regards to the comment on the first sentence, all services have to =
be
> evaluated for impact before they are implemented in any live
> environment.  However, a service that is designed from the beginning
> with no consideration of the impacts to the access technologies is a
> very badly designed service.  ATOCA will have an adverse effect to at
> least some of the access technologies and if ATOCA is designed without
> any considerations of the capabilities and limitations of the access
> technologies, it will fail and it will cause adverse effects to the
> access technologies.
>=20
> The proof of network congestion already exists.  This is demonstrated
> repeatedly as "all circuits busy" error responses, dropped calls,
> fast-busy tones, delayed delivery of SMS messages, etc.=20
>=20
> Since ATOCA is the new communications entity beginning proposed, the
> burden of proof is on ATOCA to prove that it will not adversely impact
> any of the associated access technologies.
>=20
> DeWayne=20
>=20
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ken carlberg
> Sent: Wednesday, April 07, 2010 12:48 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
>=20
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>=20
>> "The ATOCA solutions will not adversely affect the ability of any
> access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
> other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
> by
>> any access technology."
>=20
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect =
the
> individuals who make a claim that an ATOCA solution adversely affects
> 9-1-1 type calls will be required to prove it instead of simply =
stating
> a position.
>=20
> as for the second sentence, that is out of scope of the IETF.  any
> deployment of what is considered an ATOCA solution is a market =
decision.
>=20
> -ken
>=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
>=20

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 13:21:56 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, "ken carlberg" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

We are just stating that ATOCA contradicts the CMAS (& EAS) rules, as
well as iPAWS and DMOpen architectures, and thus is in a different
class. Thus we believe we do need to be up front in the charter and nto
to confuse the industry.

Brian

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]=20
Sent: Wednesday, April 07, 2010 1:18 PM
To: DALY, BRIAN K (ATTCINW); ken carlberg; SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

In what way would any RFC not have to meet that requirement?

I understand that you are concerned that this work overlaps layer 2
specific
solutions.  However, there is no need to explicitly put this work in
second
class.  It's not going to affect any words in a protocol specification.
If
there is a regulatory requirement that makes ATOCA compliant
implementations, like any other service, subservient in some way to some
other service, so be it.  The charter, and the spec, don't need to say
that;
it's always true.

Brian

On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> The second is more than a market decision - it is an interaction with
a
> regulatory requirement.
>=20
> Perhaps a better way to phrase is as follows:
>=20
> "Additionally, ATOCA will not interfere with nor replace solutions
> designed to meet regulatory requirements for any authority to citizen
> alerting of any access technology."
>=20
> Brian Daly
> AT&T
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ken carlberg
> Sent: Wednesday, April 07, 2010 12:48 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
>=20
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>=20
>> "The ATOCA solutions will not adversely affect the ability of any
> access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
> other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
> by
>> any access technology."
>=20
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect
the
> individuals who make a claim that an ATOCA solution adversely affects
> 9-1-1 type calls will be required to prove it instead of simply
stating
> a position.
>=20
> as for the second sentence, that is out of scope of the IETF.  any
> deployment of what is considered an ATOCA solution is a market
decision.
>=20
> -ken
>=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: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:21:20 -0400
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

I didn't know that the IETF had corporate opinions. But maybe the IETF =
rules have changed recently?

Henning

On Apr 7, 2010, at 4:13 PM, DALY, BRIAN K (ATTCINW) wrote:

> For the record, AT&T is in opposition to removing the last sentence.
>=20
> Brian Daly
> AT&T

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 13:20:38 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "ken carlberg" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

In regards to the comment on the first sentence, all services have to be
evaluated for impact before they are implemented in any live
environment.  However, a service that is designed from the beginning
with no consideration of the impacts to the access technologies is a
very badly designed service.  ATOCA will have an adverse effect to at
least some of the access technologies and if ATOCA is designed without
any considerations of the capabilities and limitations of the access
technologies, it will fail and it will cause adverse effects to the
access technologies.

The proof of network congestion already exists.  This is demonstrated
repeatedly as "all circuits busy" error responses, dropped calls,
fast-busy tones, delayed delivery of SMS messages, etc.=20

Since ATOCA is the new communications entity beginning proposed, the
burden of proof is on ATOCA to prove that it will not adversely impact
any of the associated access technologies.

DeWayne=20

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Wednesday, April 07, 2010 12:48 PM
To: SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> "The ATOCA solutions will not adversely affect the ability of any
access
> technology to provide emergency services to the citizens (e.g. 9-1-1
> calls) or to provide communication services to first responders or
other
> authorized emergency services personnel.  Additionally, ATOCA is not
> replacement solution for any authority to citizen alerting supported
by
> any access technology."

given the previous thread on this list, I'm a bit leery of that first
sentence.  But, if it were agreed to add it in, then I would expect the
individuals who make a claim that an ATOCA solution adversely affects
9-1-1 type calls will be required to prove it instead of simply stating
a position.

as for the second sentence, that is out of scope of the IETF.  any
deployment of what is considered an ATOCA solution is a market decision.

-ken

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

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 7 Apr 2010 16:19:55 -0400
To: Marc Linsner <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

+1

The notion that ATOCA, or any IETF WG, can somehow accommodate =
"regulation" is a bit peculiar. Which regulation? Of which country or =
countries? Does it mean that if a country rules out use of VoIP, as some =
do, that we can't standardize protocols for that? Would the charter of =
the RAI WGs have to note that use of this technology is illegal in =
Egypt?

Clearly, any product or service using IETF protocols is subject to =
regulation in the country or other jurisdiction it is being deployed in. =
The FCC (assuming an appellate court lets them...) can prohibit the use =
of ATOCA mechanisms, but that's not our problem, except in the sense =
that the technology may not be deployed at all or only in limited =
environments. However, if we went by the deployment regulations in force =
at the time of standardization, we'd still be working on ISDN at this =
point. It's pretty clear that mobile technology is in transition; =
mechanisms that made perfect sense with 2G technologies may not be =
nearly as useful in 4G networks.

Henning

On Apr 7, 2010, at 4:12 PM, Marc Linsner wrote:

> I agree with Ken, strike the last sentence.
>=20
> -Marc-
>=20
>=20
> On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:
>=20
>>=20
>> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>=20
>>> "The ATOCA solutions will not adversely affect the ability of any =
access
>>> technology to provide emergency services to the citizens (e.g. 9-1-1
>>> calls) or to provide communication services to first responders or =
other
>>> authorized emergency services personnel.  Additionally, ATOCA is not
>>> replacement solution for any authority to citizen alerting supported =
by
>>> any access technology."
>>=20
>> given the previous thread on this list, I'm a bit leery of that first
>> sentence.  But, if it were agreed to add it in, then I would expect =
the
>> individuals who make a claim that an ATOCA solution adversely affects =
9-1-1
>> type calls will be required to prove it instead of simply stating a =
position.
>>=20
>> as for the second sentence, that is out of scope of the IETF.  any =
deployment
>> of what is considered an ATOCA solution is a market decision.
>>=20
>> -ken
>>=20
>> _______________________________________________
>> earlywarning mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/earlywarning
>=20
>=20
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning
>=20

Date: Wed, 07 Apr 2010 16:17:44 -0400
From: Brian Rosen <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>, ken carlberg <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

In what way would any RFC not have to meet that requirement?

I understand that you are concerned that this work overlaps layer 2 specific
solutions.  However, there is no need to explicitly put this work in second
class.  It's not going to affect any words in a protocol specification.  If
there is a regulatory requirement that makes ATOCA compliant
implementations, like any other service, subservient in some way to some
other service, so be it.  The charter, and the spec, don't need to say that;
it's always true.

Brian

On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> The second is more than a market decision - it is an interaction with a
> regulatory requirement.
> 
> Perhaps a better way to phrase is as follows:
> 
> "Additionally, ATOCA will not interfere with nor replace solutions
> designed to meet regulatory requirements for any authority to citizen
> alerting of any access technology."
> 
> Brian Daly
> AT&T
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ken carlberg
> Sent: Wednesday, April 07, 2010 12:48 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> 
> 
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> "The ATOCA solutions will not adversely affect the ability of any
> access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
> other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
> by
>> any access technology."
> 
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect the
> individuals who make a claim that an ATOCA solution adversely affects
> 9-1-1 type calls will be required to prove it instead of simply stating
> a position.
> 
> as for the second sentence, that is out of scope of the IETF.  any
> deployment of what is considered an ATOCA solution is a market decision.
> 
> -ken
> 
> _______________________________________________
> 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: Wed, 7 Apr 2010 13:17:02 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Marc Linsner" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The opt-in was not a market decision - I disagree. It was a
congressional and FCC mandate stemmed from the WARN Act resulting in the
FCC Part 10 rules.

ATOCA does not fall under that.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]=20
Sent: Wednesday, April 07, 2010 1:15 PM
To: DALY, BRIAN K (ATTCINW)
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The opt-in was a market decision, not a requirement.

If ATOCA builds a different solution, it too will be a market decision
to
offer or not.

-Marc-

On 4/7/10 4:09 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> But those operators that opt-in must follow the FCC Part 10 rules for
> CMAS. So I do nto understand your comment.
>=20
> Brian
>=20
> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:08 PM
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
> CMAS was opt-in by the carriers, not a requirement....??
>=20
> -Marc-
>=20
>=20
> On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
>=20
>> The second is more than a market decision - it is an interaction with
> a
>> regulatory requirement.
>>=20
>> Perhaps a better way to phrase is as follows:
>>=20
>> "Additionally, ATOCA will not interfere with nor replace solutions
>> designed to meet regulatory requirements for any authority to citizen
>> alerting of any access technology."
>>=20
>> Brian Daly
>> AT&T
>>=20
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ken carlberg
>> Sent: Wednesday, April 07, 2010 12:48 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: Hannes Tschofenig; [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>>=20
>>=20
>> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>>=20
>>> "The ATOCA solutions will not adversely affect the ability of any
>> access
>>> technology to provide emergency services to the citizens (e.g. 9-1-1
>>> calls) or to provide communication services to first responders or
>> other
>>> authorized emergency services personnel.  Additionally, ATOCA is not
>>> replacement solution for any authority to citizen alerting supported
>> by
>>> any access technology."
>>=20
>> given the previous thread on this list, I'm a bit leery of that first
>> sentence.  But, if it were agreed to add it in, then I would expect
> the
>> individuals who make a claim that an ATOCA solution adversely affects
>> 9-1-1 type calls will be required to prove it instead of simply
> stating
>> a position.
>>=20
>> as for the second sentence, that is out of scope of the IETF.  any
>> deployment of what is considered an ATOCA solution is a market
> decision.
>>=20
>> -ken
>>=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
>=20
>=20

Date: Wed, 07 Apr 2010 16:14:35 -0400
From: Marc Linsner <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The opt-in was a market decision, not a requirement.

If ATOCA builds a different solution, it too will be a market decision to
offer or not.

-Marc-

On 4/7/10 4:09 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> But those operators that opt-in must follow the FCC Part 10 rules for
> CMAS. So I do nto understand your comment.
> 
> Brian
> 
> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, April 07, 2010 1:08 PM
> To: DALY, BRIAN K (ATTCINW)
> Cc: [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> 
> CMAS was opt-in by the carriers, not a requirement....??
> 
> -Marc-
> 
> 
> On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:
> 
>> The second is more than a market decision - it is an interaction with
> a
>> regulatory requirement.
>> 
>> Perhaps a better way to phrase is as follows:
>> 
>> "Additionally, ATOCA will not interfere with nor replace solutions
>> designed to meet regulatory requirements for any authority to citizen
>> alerting of any access technology."
>> 
>> Brian Daly
>> AT&T
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of ken carlberg
>> Sent: Wednesday, April 07, 2010 12:48 PM
>> To: SENNETT, DEWAYNE A (ATTCINW)
>> Cc: Hannes Tschofenig; [email-masked]
>> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>> 
>> 
>> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>> 
>>> "The ATOCA solutions will not adversely affect the ability of any
>> access
>>> technology to provide emergency services to the citizens (e.g. 9-1-1
>>> calls) or to provide communication services to first responders or
>> other
>>> authorized emergency services personnel.  Additionally, ATOCA is not
>>> replacement solution for any authority to citizen alerting supported
>> by
>>> any access technology."
>> 
>> given the previous thread on this list, I'm a bit leery of that first
>> sentence.  But, if it were agreed to add it in, then I would expect
> the
>> individuals who make a claim that an ATOCA solution adversely affects
>> 9-1-1 type calls will be required to prove it instead of simply
> stating
>> a position.
>> 
>> as for the second sentence, that is out of scope of the IETF.  any
>> deployment of what is considered an ATOCA solution is a market
> decision.
>> 
>> -ken
>> 
>> _______________________________________________
>> 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: Wed, 7 Apr 2010 13:13:52 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Marc Linsner" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

For the record, AT&T is in opposition to removing the last sentence.

Brian Daly
AT&T

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Wednesday, April 07, 2010 1:12 PM
To: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

I agree with Ken, strike the last sentence.

-Marc-

On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:

>=20
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>=20
>> "The ATOCA solutions will not adversely affect the ability of any
access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
by
>> any access technology."
>=20
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect
the
> individuals who make a claim that an ATOCA solution adversely affects
9-1-1
> type calls will be required to prove it instead of simply stating a
position.
>=20
> as for the second sentence, that is out of scope of the IETF.  any
deployment
> of what is considered an ATOCA solution is a market decision.
>=20
> -ken
>=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

Date: Wed, 07 Apr 2010 16:12:20 -0400
From: Marc Linsner <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

I agree with Ken, strike the last sentence.

-Marc-

On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:

> 
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> "The ATOCA solutions will not adversely affect the ability of any access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported by
>> any access technology."
> 
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect the
> individuals who make a claim that an ATOCA solution adversely affects 9-1-1
> type calls will be required to prove it instead of simply stating a position.
> 
> as for the second sentence, that is out of scope of the IETF.  any deployment
> of what is considered an ATOCA solution is a market decision.
> 
> -ken
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 13:09:06 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Marc Linsner" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

But those operators that opt-in must follow the FCC Part 10 rules for
CMAS. So I do nto understand your comment.

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]=20
Sent: Wednesday, April 07, 2010 1:08 PM
To: DALY, BRIAN K (ATTCINW)
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

CMAS was opt-in by the carriers, not a requirement....??

-Marc-

On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> The second is more than a market decision - it is an interaction with
a
> regulatory requirement.
>=20
> Perhaps a better way to phrase is as follows:
>=20
> "Additionally, ATOCA will not interfere with nor replace solutions
> designed to meet regulatory requirements for any authority to citizen
> alerting of any access technology."
>=20
> Brian Daly
> AT&T
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ken carlberg
> Sent: Wednesday, April 07, 2010 12:48 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
>=20
>=20
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>=20
>> "The ATOCA solutions will not adversely affect the ability of any
> access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
> other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
> by
>> any access technology."
>=20
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect
the
> individuals who make a claim that an ATOCA solution adversely affects
> 9-1-1 type calls will be required to prove it instead of simply
stating
> a position.
>=20
> as for the second sentence, that is out of scope of the IETF.  any
> deployment of what is considered an ATOCA solution is a market
decision.
>=20
> -ken
>=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

Date: Wed, 07 Apr 2010 16:07:35 -0400
From: Marc Linsner <[email-masked]>
To: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

CMAS was opt-in by the carriers, not a requirement....??

-Marc-

On 4/7/10 3:56 PM, "DALY, BRIAN K (ATTCINW)" <[email-masked]> wrote:

> The second is more than a market decision - it is an interaction with a
> regulatory requirement.
> 
> Perhaps a better way to phrase is as follows:
> 
> "Additionally, ATOCA will not interfere with nor replace solutions
> designed to meet regulatory requirements for any authority to citizen
> alerting of any access technology."
> 
> Brian Daly
> AT&T
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of ken carlberg
> Sent: Wednesday, April 07, 2010 12:48 PM
> To: SENNETT, DEWAYNE A (ATTCINW)
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [earlywarning] Finishing the Charter Text Discussions
> 
> 
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> "The ATOCA solutions will not adversely affect the ability of any
> access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
> other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
> by
>> any access technology."
> 
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect the
> individuals who make a claim that an ATOCA solution adversely affects
> 9-1-1 type calls will be required to prove it instead of simply stating
> a position.
> 
> as for the second sentence, that is out of scope of the IETF.  any
> deployment of what is considered an ATOCA solution is a market decision.
> 
> -ken
> 
> _______________________________________________
> 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: Wed, 7 Apr 2010 13:06:39 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "Brian Rosen" <[email-masked]>, "ken carlberg" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Absolutely false!!

You have no clue what the incoming emergency call is about - it could be
a kitty in the tree call, as you put it, or it could be "I just had a
heart attack and need help immediately".

An authority to citizen "call" should never take priority over a citizen
to authority, and this is regulated ni the FCC rules for CMAS.

And your typhoon analogy proves the point - a typhoon is known several
days in advance, while you have minutes to take action on a heart
attack.

Brian Daly

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Wednesday, April 07, 2010 1:00 PM
To: ken carlberg; SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Generally, it's not a good idea for any service to impede any other
service,
but we don't have to say that all the time.  Here, I think we don't have
to
discuss how authority to citizen should be prioritized over citizen to
authority.  I rather suspect that an outgoing warning of an impending
typhoon is more important that an incoming kitty-in-the-tree call, but
maybe
that's just me.

ATOCA may or may not be a replacement for something that exists.  Agree
with
Ken, the market (and in this case, likely governments) will decide.

So I would not want to see this text in the charter.

Brian

On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:

>=20
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
>=20
>> "The ATOCA solutions will not adversely affect the ability of any
access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or
other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported
by
>> any access technology."
>=20
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect
the
> individuals who make a claim that an ATOCA solution adversely affects
9-1-1
> type calls will be required to prove it instead of simply stating a
position.
>=20
> as for the second sentence, that is out of scope of the IETF.  any
deployment
> of what is considered an ATOCA solution is a market decision.
>=20
> -ken
>=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

Date: Wed, 07 Apr 2010 16:00:04 -0400
From: Brian Rosen <[email-masked]>
To: ken carlberg <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Generally, it's not a good idea for any service to impede any other service,
but we don't have to say that all the time.  Here, I think we don't have to
discuss how authority to citizen should be prioritized over citizen to
authority.  I rather suspect that an outgoing warning of an impending
typhoon is more important that an incoming kitty-in-the-tree call, but maybe
that's just me.

ATOCA may or may not be a replacement for something that exists.  Agree with
Ken, the market (and in this case, likely governments) will decide.

So I would not want to see this text in the charter.

Brian

On 4/7/10 3:48 PM, "ken carlberg" <[email-masked]> wrote:

> 
> On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:
> 
>> "The ATOCA solutions will not adversely affect the ability of any access
>> technology to provide emergency services to the citizens (e.g. 9-1-1
>> calls) or to provide communication services to first responders or other
>> authorized emergency services personnel.  Additionally, ATOCA is not
>> replacement solution for any authority to citizen alerting supported by
>> any access technology."
> 
> given the previous thread on this list, I'm a bit leery of that first
> sentence.  But, if it were agreed to add it in, then I would expect the
> individuals who make a claim that an ATOCA solution adversely affects 9-1-1
> type calls will be required to prove it instead of simply stating a position.
> 
> as for the second sentence, that is out of scope of the IETF.  any deployment
> of what is considered an ATOCA solution is a market decision.
> 
> -ken
> 
> _______________________________________________
> earlywarning mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/earlywarning

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 12:56:52 -0700
From: "DALY, BRIAN K (ATTCINW)" <[email-masked]>
To: "ken carlberg" <[email-masked]>, "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

The second is more than a market decision - it is an interaction with a
regulatory requirement.

Perhaps a better way to phrase is as follows:

"Additionally, ATOCA will not interfere with nor replace solutions
designed to meet regulatory requirements for any authority to citizen
alerting of any access technology."

Brian Daly
AT&T

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ken carlberg
Sent: Wednesday, April 07, 2010 12:48 PM
To: SENNETT, DEWAYNE A (ATTCINW)
Cc: Hannes Tschofenig; [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> "The ATOCA solutions will not adversely affect the ability of any
access
> technology to provide emergency services to the citizens (e.g. 9-1-1
> calls) or to provide communication services to first responders or
other
> authorized emergency services personnel.  Additionally, ATOCA is not
> replacement solution for any authority to citizen alerting supported
by
> any access technology."

given the previous thread on this list, I'm a bit leery of that first
sentence.  But, if it were agreed to add it in, then I would expect the
individuals who make a claim that an ATOCA solution adversely affects
9-1-1 type calls will be required to prove it instead of simply stating
a position.

as for the second sentence, that is out of scope of the IETF.  any
deployment of what is considered an ATOCA solution is a market decision.

-ken

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

From: ken carlberg <[email-masked]>
Date: Wed, 7 Apr 2010 15:48:11 -0400
To: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>, [email-masked]
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

On Apr 7, 2010, at 11:30 AM, SENNETT, DEWAYNE A (ATTCINW) wrote:

> "The ATOCA solutions will not adversely affect the ability of any =
access
> technology to provide emergency services to the citizens (e.g. 9-1-1
> calls) or to provide communication services to first responders or =
other
> authorized emergency services personnel.  Additionally, ATOCA is not
> replacement solution for any authority to citizen alerting supported =
by
> any access technology."

given the previous thread on this list, I'm a bit leery of that first =
sentence.  But, if it were agreed to add it in, then I would expect the =
individuals who make a claim that an ATOCA solution adversely affects =
9-1-1 type calls will be required to prove it instead of simply stating =
a position.

as for the second sentence, that is out of scope of the IETF.  any =
deployment of what is considered an ATOCA solution is a market decision.

-ken

Content-class: urn:content-classes:message
Date: Wed, 7 Apr 2010 08:30:39 -0700
From: "SENNETT, DEWAYNE A (ATTCINW)" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>, <[email-masked]>
Subject: Re: [earlywarning] Finishing the Charter Text Discussions

Hi Hannes,

Based upon the previous email decisions, changes to the charter text are
still needed. =20

The second paragraph of the charter provides a high level purpose and
scope for the ATOCA work.  The following should be added to the end of
the second paragraph to provide further clarification on the purpose and
scope of the ATOCA work:

"The ATOCA solutions will not adversely affect the ability of any access
technology to provide emergency services to the citizens (e.g. 9-1-1
calls) or to provide communication services to first responders or other
authorized emergency services personnel.  Additionally, ATOCA is not
replacement solution for any authority to citizen alerting supported by
any access technology."

Regards,

DeWayne A. Sennett

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Tuesday, April 06, 2010 4:18 AM
To: [email-masked]
Subject: [earlywarning] Finishing the Charter Text Discussions

Hi all,=20

we had some discussions in response to the charter text I distributed. I
made some minor changes based on the received comments but most of the
discussions seemed (at least to me) not related to the charter text
itself.=20

Is the charter text OK for everyone?=20

Ciao
Hannes

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

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

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=20
alerts to be sent, but it also presents new challenges. While there are=20
some existing layer 2 mechanisms for delivering alerts the work in this
group=20
focuses on delivering alerts to IP endpoints only.=20

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

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.=20
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=20
work in the group is focused on small messages, which may be
mechanically=20
rendered by the device in other forms (text to speech for example). In=20
situations of a major emergency there could be scenarios where there are

multiple alerts generated that may require that a priority mechanism has
to=20
be used. The work on a resource priority mechanism is out of scope of
the=20
initial charter, but may be revisited at a later date.

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=20
opt-out at the level of communication protocols.=20

Another class of recipients that are in scope of the work are explicit
opt-in subscriptions which ask for alerts for a specified location.=20
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest).=20
This work builds on existing IETF geopriv location work.=20

There are efforts in other fora on early warning, 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.  OGC, ATIS, TIA,
ITU-T,=20
ETSI and 3GPP also have alert efforts underway, and consultation with
these=20
efforts will be undertaken to avoid unnecessary duplication of effort.=20
Of course, existing protocols for delivering messages (e.g., SIP)=20
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.=20

Milestones
=20
TBD      Initial document for "Terminology and Framework" document.=20
         A starting point for this work is
         draft-norreys-ecrit-authority2individuals-requirements.
TBD      Initial document for conveying alerts in SIP=20
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=20
         draft-rosen-ecrit-lost-early-warning.

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

Date: Tue, 06 Apr 2010 13:18:18 +0200
From: "Hannes Tschofenig" <[email-masked]>
To: [email-masked]
Subject: [earlywarning] Finishing the Charter Text Discussions

Hi all, 

we had some discussions in response to the charter text I distributed. I made some minor changes based on the received comments but most of the discussions seemed (at least to me) not related to the charter text itself. 

Is the charter text OK for everyone? 

Ciao
Hannes

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

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 are the 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 the device 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 used. The work on a resource priority mechanism is out of scope of the 
initial charter, but may be revisited at a later date.

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 for a specified location. 
An example of such a subscription would be 'send me alerts for
location x' (previously determined as the location of interest). 
This work builds on existing IETF geopriv location work. 

There are efforts in other fora on early warning, 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.  OGC, 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: "Carl Reed" <[email-masked]>
To: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 2 Apr 2010 11:36:33 -0600
Organization: OGC
Cc: [email-masked]
Subject: Re: [earlywarning] New Charter Text for ATOCA

Hannes -

Apologies for the delay in responding. Was attending the Where 2.0 
Conference and a Disaster Management Workshop (in the Bay area).

I guess I am asking that the charter add the OGC as a group that the EW 
community needs to collaborate with. This because we have Members working 
many aspects of the EW stack, especially at the application level. Many use 
cases and much implementation experience as well as interoperability 
testbeds to draw upon.

Regards

Carl

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 24, 2010 4:22 PM
Subject: Re: [earlywarning] New Charter Text for ATOCA

> Hi Carl,
>
> thanks for the input.
>
> How would your feedback be reflected in the charter text?
>
> Ciao
> Hannes
>
> [email-masked] wrote:
>> Hannes -
>>
>> Some additional information. In Canada, they use a Canadian Profile of 
>> CAP
>> for authority to authority and then transform the CAP message to GeoRSS
>> GML, SMS, or KML for authority to citizen. In Taiwan, there has been some
>> work also in the alerting world using a new draft spec called GeoSMS. In
>> Taiwan, they are also using a draft OGC standards called Sensor Alert
>> Service (SAS), but this will change based on the work described below.
>>
>> That said, the OGC community is forging ahead looking at frameworks and
>> architectures for alerting. In the OGC Web Services 7.0 testbed:
>>
>> OWS-7 is doing a lot of testing related to alert notification
>> capabilities.  They are currently looking at a new service tentatively
>> titled SES (Sensor Event Service)
>> http://portal.opengeospatial.org/files/?artifact_id=29576 (earlier
>> discussion paper) which is being enhanced to output the alert in several
>> different formats - CAP, ATOM, and I believe GeoRSS.  I believe the 
>> Sensor
>> part of the Event Service is a misnomer as this service will not be tied
>> to only sensors so I think the name will change eventually.  It is the
>> consensus of the OWS-7 group that the draft OGC Sensor Alert Service will
>> no longer be required.  As I understand it, the OGC Web Notification
>> Service is a method of delivery of the message (email, Short Message
>> Service (SMS), Instant Messaging (IM), automated phone calls or faxes) as
>> such is more of a message transport service. SAS and WNS are beng
>> integrated into the SES specification.
>>
>> Who is supporting this work within the OGC community? OWS-7 is described
>> here: http://www.opengeospatial.org/standards/requests/60. There are
>> numerous additional OGC Member organizations working this application
>> area. The OWS-7 work is aligned with the GMES, ORCHESTRA, and GEOSS
>> requirements for alerting.
>>
>> The OGC work is being done perhaps at a higher level in the applications
>> stack than the IETF work being envisioned.
>>
>> Cheers
>>
>> Carl
>>
>>
>>
>>
>>> 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.
>>>
>>> _______________________________________________
>>> earlywarning mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/earlywarning
>>>
>>>
>>
>>
>