On Sep 13, = 2011, at 9:26 AM, Peter Sanders wrote:

Hi,

Is the meeting still on? If = so, would someone please distribute the agenda and dial-in = information?

Thanks

Peter = Sanders
Product = Manager
o n e 2 m a n yLeeuwenbrug 115
7411 TH Deventer
The Netherlands
T: +31 = (0)88 0034915
M: +31 6 = 5198 3017
E: peter.sanders@one2many.eu
This e-mail and any attachment = is for authorised use by the intended recipient(s) only. It contains = proprietary material, confidential information and/or be subject to = legal privilege. It should not be copied, disclosed to, retained or used = by, any other party. If you are not an intended recipient then please = promptly delete this e-mail and any attachment and all copies and inform = the sender. Thank you
To: Robert Sparks , Peter Sanders Date: Tue, 13 Sep 2011 17:54:55 +0200 Thread-Topic: [atoca] meeting today, but how Thread-Index: AcxyK+WAT7ErZ9ViT8qqaRQjU5ngBgAAHuNA Message-ID: References: <004701cc7221$236683f0$6a338bd0$@sanders@one2many.eu> <4C0CB380-CFC5-4E81-9919-BFBF76C9A672@nostrum.com> In-Reply-To: <4C0CB380-CFC5-4E81-9919-BFBF76C9A672@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE220BA45B0FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "atoca@ietf.org" Subject: Re: [atoca] meeting today, but how X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 15:52:55 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE220BA45B0FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A design team doing what. I see no active internet drafts - the most recent one expired in January. The only information I can find on the proposed content of the call is in t= he Quebec meeting report: 2. Chairs presented a plan for working group progress. Work on requirement= s and architecture will be delegated to a small group of volunteers who wil= l produce a draft. This draft, plus some progress on the solution, will be= presented at a virtual interim in September. Initial drafts for each of t= he pieces of the solution will be prepared for the November meeting in Taip= ei. And Conclusion: Plan to have a vritual interim meeting Middle in Sep, 2011. Will use poll t= o set up this meeting. Have Hennes, David, Brian, Richard, James Polk in the design team. Work on = the three or four drafts by the interim. Get something more concerete for the next F2F meeting to discuss. I'm giving up part of my evening to participate - it would be nice to actua= lly do the preparation reading during working hours. Keith ________________________________ From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of R= obert Sparks Sent: 13 September 2011 16:43 To: Peter Sanders Cc: atoca@ietf.org Subject: Re: [atoca] meeting today, but how Peter - The plan hasn't been changed - the agenda is still to get a readout from th= e design team as discussed in Quebec. The chairs acquired a bridge from the secretariat - we'll get that to the l= ist as soon as possible. It's unfortunate that you needed to ask either of those questions though. RjS On Sep 13, 2011, at 9:26 AM, Peter Sanders wrote: Hi, Is the meeting still on? If so, would someone please distribute the agenda = and dial-in information? Thanks Peter Sanders Product Manager __________________ o n e 2 m a n y Leeuwenbrug 115 7411 TH Deventer The Netherlands T: +31 (0)88 0034915 M: +31 6 5198 3017 E: peter.sanders@one2many.eu www.one2many.eu This e-mail and any attachment is for authorised use by the intended recipi= ent(s) only. It contains proprietary material, confidential information and= /or be subject to legal privilege. It should not be copied, disclosed to, r= etained or used by, any other party. If you are not an intended recipient t= hen please promptly delete this e-mail and any attachment and all copies an= d inform the sender. Thank you _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca --_000_EDC0A1AE77C57744B664A310A0B23AE220BA45B0FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A design team doing what.

I see no active internet drafts –= ; the most recent one expired in January.

The only information I can find on the proposed content of the call is in the Quebec meeting report:

2= . Chairs presented a plan for working group progress. Work on require= ments and architecture will be delegated to a small group of volunteers who= will produce a draft. This draft, plus some progress on the solution= , will be presented at a virtual interim in September. Initial drafts= for each of the pieces of the solution will be prepared for the November m= eeting in Taipei.
<= /o:p>

And

C= onclusion:
Plan to have= a vritual interim meeting Middle in Sep, 2011. Will use poll to set up thi= s meeting.
Have Hennes,= David, Brian, Richard, James Polk in the design team. Work on the three or= four drafts by the interim.
Get somethin= g more concerete for the next F2F meeting to discuss.

I’m giving up part of my evening= to participate – it would be nice to actually do the preparation reading during working hours.

Keith

From:= atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 13 September 2011 16:4= 3
To: Peter Sanders
Cc: atoca@ietf.org
Subject: Re: [atoca] meeting today, but how

Peter -

The plan hasn't been changed - the agenda is still to get a readout from the design team as discussed in Quebec.

The chairs acquired a bridge from the secretariat - we'll get that = to the list as soon as possible.

It's unfortunate that you needed to ask either of those questi= ons though.

RjS

On Sep 13, 2011, at 9:26 AM, Peter Sanders wrote:=

Hi,

Is the meeting still on? If so, would someone please distribute the agenda and dial-in information?

Thanks

Peter Sanders

Product Manager

__________________

o n e= = ;2 m a n y<= /u1:p>

Leeuwenbrug 115<= /u1:p>

7411 TH Deventer<= /u1:p>

The Netherlands

T: +31 (0)88 0034915<= /u1:p>

M: +31 6 5198 3017<= /u1:p>

E: peter.sanders@= one2many.eu

www.one2many.eu

This e-mail and an= y attachment is for authorised use by the intended recipient(s) only. It cont= ains proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly dele= te this e-mail and any attachment and all copies and inform the sender. Thank = you

_______________________________________________
atoca mailing list
atoca@ietf.org
https://www.ietf.or= g/mailman/listinfo/atoca
--_000_EDC0A1AE77C57744B664A310A0B23AE220BA45B0FRMRSSXCHMBSC3d_-- From rbarnes@bbn.com Tue Sep 13 09:15:14 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E781621F8CA4 for ; Tue, 13 Sep 2011 09:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UXE1dWDzP1f for ; Tue, 13 Sep 2011 09:15:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFC221F8C5F for ; Tue, 13 Sep 2011 09:15:08 -0700 (PDT) Received: from [192.1.255.224] (port=50671 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R3VfV-0000R3-6N; Tue, 13 Sep 2011 12:17:05 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 13 Sep 2011 12:16:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <64CCE0AD-A88F-4CFB-BB00-967B13C2958E@bbn.com> References: <004701cc7221$236683f0$6a338bd0$@sanders@one2many.eu> <4C0CB380-CFC5-4E81-9919-BFBF76C9A672@nostrum.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: "atoca@ietf.org" Subject: Re: [atoca] meeting today, but how X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:15:15 -0000 Hey Keith, The design team has had some discussions of what the architecture and = protocols should look like, but we haven't created an Internet-Draft. = Our plan was to go through some slides describing that vision in the = meeting today, and get some drafts ready in time for the Taipei meeting. If you would like to look at the slides in advance of the meeting, I've = posted a link on the WG wiki: --Richard On Sep 13, 2011, at 11:54 AM, DRAGE, Keith (Keith) wrote: > A design team doing what. > =20 > I see no active internet drafts =96 the most recent one expired in = January. > =20 > The only information I can find on the proposed content of the call is = in the Quebec meeting report: > =20 > 2. Chairs presented a plan for working group progress. Work on = requirements and architecture will be delegated to a small group of = volunteers who will produce a draft. This draft, plus some progress on = the solution, will be presented at a virtual interim in September. = Initial drafts for each of the pieces of the solution will be prepared = for the November meeting in Taipei. > =20 > And > =20 > Conclusion: > Plan to have a vritual interim meeting Middle in Sep, 2011. Will use = poll to set up this meeting. > Have Hennes, David, Brian, Richard, James Polk in the design team. = Work on the three or four drafts by the interim. > Get something more concerete for the next F2F meeting to discuss. > =20 > I=92m giving up part of my evening to participate =96 it would be nice = to actually do the preparation reading during working hours. > =20 > Keith > =20 > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf = Of Robert Sparks > Sent: 13 September 2011 16:43 > To: Peter Sanders > Cc: atoca@ietf.org > Subject: Re: [atoca] meeting today, but how > =20 > Peter -=20 > =20 > The plan hasn't been changed - the agenda is still to get a readout = from the design team as discussed in Quebec.=20 > The chairs acquired a bridge from the secretariat - we'll get that to = the list as soon as possible.=20 > It's unfortunate that you needed to ask either of those questions = though. > =20 > RjS > =20 > On Sep 13, 2011, at 9:26 AM, Peter Sanders wrote: >=20 >=20 > Hi, > =20 > Is the meeting still on? If so, would someone please distribute the = agenda and dial-in information? > =20 > Thanks > =20 > Peter Sanders > Product Manager > __________________ > o n e 2 m a n y > Leeuwenbrug 115 > 7411 TH Deventer > The Netherlands > T: +31 (0)88 0034915 > M: +31 6 5198 3017 > E: peter.sanders@one2many.eu > www.one2many.eu > =20 > This e-mail and any attachment is for authorised use by the intended = recipient(s) only. It contains proprietary material, confidential = information and/or be subject to legal privilege. It should not be = copied, disclosed to, retained or used by, any other party. If you are = not an intended recipient then please promptly delete this e-mail and = any attachment and all copies and inform the sender. Thank you > =20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > =20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From wwwrun@ietfa.amsl.com Tue Sep 13 09:15:17 2011 Return-Path: X-Original-To: atoca@ietf.org Delivered-To: atoca@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 6420B21F8CAC; Tue, 13 Sep 2011 09:15:17 -0700 (PDT) From: IESG Secretary To: atoca@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110913161517.6420B21F8CAC@ietfa.amsl.com> Date: Tue, 13 Sep 2011 09:15:17 -0700 (PDT) Subject: [atoca] WebEx Info for ATOCA WG Virtual Interim Meeting X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 16:15:17 -0000 Topic: ATOCA WG Virtual Interim Meeting Date: Tuesday, September 13, 2011 Time: 1:00 pm, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting Number: 966 261 132 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=181789112&UID=1249260112&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=181789112&UID=1249260112&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=181789112&tollFree=0 Access code:966 261 132 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=181789112&UID=1249260112&ICS=MI&LD=1&RD=2&ST=1&SHA2=eRP3DeM30ajtihFdlpiUZj3ubFDEr/UpkrtqXY6F3s8=&RT=MiM0 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+14087926300x966261132# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From rbarnes@bbn.com Tue Sep 13 13:01:15 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB311E80E2 for ; Tue, 13 Sep 2011 13:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Z6eIdFNY8i for ; Tue, 13 Sep 2011 13:01:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96211E8102 for ; Tue, 13 Sep 2011 13:01:14 -0700 (PDT) Received: from [192.1.255.224] (port=51565 helo=col-dhcp-192-1-255-224.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R3ZCO-0003jo-Uc; Tue, 13 Sep 2011 16:03:17 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <63CB7F46-51AA-41BD-BE6C-EA85687C8FD0@brianrosen.net> Date: Tue, 13 Sep 2011 16:03:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCCA955-C6EA-4C56-A435-0AD05BF191E3@bbn.com> References: <004701cc7221$236683f0$6a338bd0$@sanders@one2many.eu> <4C0CB380-CFC5-4E81-9919-BFBF76C9A672@nostrum.com> <64CCE0AD-A88F-4CFB-BB00-967B13C2958E@bbn.com> <63CB7F46-51AA-41BD-BE6C-EA85687C8FD0@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1084) Cc: atoca@ietf.org Subject: Re: [atoca] meeting today, but how X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 20:01:15 -0000 Came out on this list around 12:00 today EST. Pasted below. -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to = https://workgreen.webex.com/workgreen/j.php?ED=3D181789112&UID=3D124926011= 2&RT=3DMiM0=20 2. If requested, enter your name and email address.=20 3. If a password is required, enter the meeting password: (This meeting = does not require a password.)=20 4. Click "Join".=20 To view in other time zones or languages, please click the link:=20 = https://workgreen.webex.com/workgreen/j.php?ED=3D181789112&UID=3D124926011= 2&ORT=3DMiM0=20 -------------------------------------------------------=20 To join the audio conference only=20 -------------------------------------------------------=20 To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.=20 Call-in toll number (US/Canada): 1-408-792-6300=20 Global call-in numbers: = https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=3DMC&ED= =3D181789112&tollFree=3D0=20 Access code:966 261 132=20 On Sep 13, 2011, at 3:59 PM, Brian Rosen wrote: > Have I missed the dial in info? It's not on the wiki. >=20 > Brian >=20 > On Sep 13, 2011, at 12:16 PM, Richard L. Barnes wrote: >=20 >> Hey Keith, >>=20 >> The design team has had some discussions of what the architecture and = protocols should look like, but we haven't created an Internet-Draft. = Our plan was to go through some slides describing that vision in the = meeting today, and get some drafts ready in time for the Taipei meeting. >>=20 >> If you would like to look at the slides in advance of the meeting, = I've posted a link on the WG wiki: >> >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Sep 13, 2011, at 11:54 AM, DRAGE, Keith (Keith) wrote: >>=20 >>> A design team doing what. >>>=20 >>> I see no active internet drafts =96 the most recent one expired in = January. >>>=20 >>> The only information I can find on the proposed content of the call = is in the Quebec meeting report: >>>=20 >>> 2. Chairs presented a plan for working group progress. Work on = requirements and architecture will be delegated to a small group of = volunteers who will produce a draft. This draft, plus some progress on = the solution, will be presented at a virtual interim in September. = Initial drafts for each of the pieces of the solution will be prepared = for the November meeting in Taipei. >>>=20 >>> And >>>=20 >>> Conclusion: >>> Plan to have a vritual interim meeting Middle in Sep, 2011. Will use = poll to set up this meeting. >>> Have Hennes, David, Brian, Richard, James Polk in the design team. = Work on the three or four drafts by the interim. >>> Get something more concerete for the next F2F meeting to discuss. >>>=20 >>> I=92m giving up part of my evening to participate =96 it would be = nice to actually do the preparation reading during working hours. >>>=20 >>> Keith >>>=20 >>> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of Robert Sparks >>> Sent: 13 September 2011 16:43 >>> To: Peter Sanders >>> Cc: atoca@ietf.org >>> Subject: Re: [atoca] meeting today, but how >>>=20 >>> Peter -=20 >>>=20 >>> The plan hasn't been changed - the agenda is still to get a readout = from the design team as discussed in Quebec.=20 >>> The chairs acquired a bridge from the secretariat - we'll get that = to the list as soon as possible.=20 >>> It's unfortunate that you needed to ask either of those questions = though. >>>=20 >>> RjS >>>=20 >>> On Sep 13, 2011, at 9:26 AM, Peter Sanders wrote: >>>=20 >>>=20 >>> Hi, >>>=20 >>> Is the meeting still on? If so, would someone please distribute the = agenda and dial-in information? >>>=20 >>> Thanks >>>=20 >>> Peter Sanders >>> Product Manager >>> __________________ >>> o n e 2 m a n y >>> Leeuwenbrug 115 >>> 7411 TH Deventer >>> The Netherlands >>> T: +31 (0)88 0034915 >>> M: +31 6 5198 3017 >>> E: peter.sanders@one2many.eu >>> www.one2many.eu >>>=20 >>> This e-mail and any attachment is for authorised use by the intended = recipient(s) only. It contains proprietary material, confidential = information and/or be subject to legal privilege. It should not be = copied, disclosed to, retained or used by, any other party. If you are = not an intended recipient then please promptly delete this e-mail and = any attachment and all copies and inform the sender. Thank you >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>>=20 >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 From sob@harvard.edu Tue Sep 13 16:51:16 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CA421F8BE5 for ; Tue, 13 Sep 2011 16:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwH1rmRhPhxG for ; Tue, 13 Sep 2011 16:51:14 -0700 (PDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56C21F8BAE for ; Tue, 13 Sep 2011 16:51:14 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by golem.sobco.com (Postfix) with ESMTP id 9AA1912619F for ; Tue, 13 Sep 2011 19:53:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from golem.sobco.com ([127.0.0.1]) by localhost (golem.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NL1Tf9j6I-0 for ; Tue, 13 Sep 2011 19:53:15 -0400 (EDT) Received: from [127.0.0.1] (unknown [127.0.0.1]) by golem.sobco.com (Postfix) with ESMTPS id 9D89F126182 for ; Tue, 13 Sep 2011 19:53:15 -0400 (EDT) From: Scott O Bradner Content-Type: multipart/alternative; boundary="Apple-Mail=_A1BDA74B-8CF8-4CC8-974C-7ADD14EE0432" Date: Tue, 13 Sep 2011 19:53:15 -0400 References: To: atoca@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [atoca] Fwd: ATOCA WG Interim Meeting Notes/Minutes X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 23:51:16 -0000 --Apple-Mail=_A1BDA74B-8CF8-4CC8-974C-7ADD14EE0432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii here are the minutes of today's ATOCA virtual interim meeting - thanks = to Matt for his notes Scott Begin forwarded message: > From: Matt Miller > Subject: ATOCA WG Interim Meeting Notes/Minutes > Date: September 13, 2011 5:05:39 PM EDT > To: Scott Bradner >=20 > ATOCA Interim Virtual Meeting - 2011-09-13T20:00:00Z > =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Slide 2: How Alerts work Today -- overview > ------------------------------------------ > two-step model: > - authorities distribute alert to subscribers (networks) - one = protocol > - networks broadcast alert to recipients without=20 >=20 > Brian Rosen: Current systems do this, but not sure we want to make the = jump they ought to do it this way. > RLB: this is a question to answer is if two systems with different = protocols is the right approach > Keith Drage: Some things are not going to change (e.g. mobile phones) >=20 > Slide 3: how alerts work today -- distribution > ---------------------------------------------- > small, static list > some prior art >=20 > Slide 4: How alerts work today -- broadcast > ------------------------------------------- > large, very dynamic list > depends on what device is connected to/listening on > some prior art >=20 > Slide 5: How alerts work tomorrow? > ---------------------------------- > One approach: extend existing architecture/frameworks to IP > * nice to bridge alerts in addition to packets (e.g. cell to wifi) >=20 > Slide 6: Standards Requirements > ------------------------------- > If we expect some arbitrary IP device to receive alerts, then we need = to define a standard for=20 > BR: Showing two-level of distribution is way too simplistic; there's = really many levels of distribution. The cell phone example is one = example of three-level. > Dave Crocker: One of the things in these types of discussions is if = these models are adequate > BR: I agree with that, and that's why I think there's no technical = need that distinguishes the distro side from the broadcast side > RBL: In the distro model, you have a fixed layer that needs/wants = robustness, while the broadcast model doesn't need or support that > BR: I think the fundamentals are identical > RBL: I think these things look more alike than they are different > DR: What different mechanisms do you see for systems in place, mine is = email. My model is MUA to MTA which is incredibly simplistic, but still = useful for discussion. While there are some others that have more = elaborate models built on the first to cover specific discussions. > Mark Wood: One of the things we found in researching using mobile = networks. You need to stop look at point-to-point protocols and start = looking at point-to-multipoint in order to scale. If a network wishes = to particpate, while their network is small, the recipient number is = very large, and geolocation a factor. > BR: I think the distribution model is not 1:1, but that there are = some number of intermiediaries. > MW: I think there are things to be concerned about within and across = the layers. We need to make sure we carry enough information for next = stage to continue (e.g. the alert polygon) > BR: I agree that we have these things to worry about. I think the = geolocation filtering needs to be applied at various levels. > MW: I think this simplication is useful for moving forward, but we = need to make sure geoloc information is tranmitted > KD: Until we define the intermediary, we don't know what information = we need to include. Second, the assertion that if there's IP, we need a = standard is not necessary. Such as if you're just using text. > DC: Even if you are using text, you need to do profiling, and there = are 3 or 4 different ways to profile > RLB: In either case, we need an RFC to define these things. > James Polk: There's another aspect you're glossing over; you're only = focusing on national alerts. Not everywhere that FiOS is will get the = same alert. Sometimes only a very small slice of FiOS will get it. >=20 > Slide 7: Proposed Milestones > ---------------------------- > * architecture document > * secure alert format (e.g. signatures) > * protocol(s) to push this stuff around (currently 2) >=20 > Slide 8: Secure Alert Format > ---------------------------- > * want end-to-end security without relying on layer-2 >=20 > BR: There's lots of security properties, but you're lumping them = altogether. You need integrity protection end-to-end, but maybe not = authentication. > RBL: I'm going to argue that's a concern with key distribution, and = not the formats. > RBL: To paraphrase for Brian, we want to know the authority that sent = the alert really was who they said they are; and when I travel to = Luxembourg, I want to receive alerts but I don't know how to verify that = it's the authority that's sending it to me? > BR: Are we sure we need end-to-end, or is hop-to-hop enough? > DC: That is a very important but very low-level question. The = high-level question is whether the recipient needs to validate the = integrity of the sender. > JP: There will be multiple distribution authorities > BR: Again, do we need end-to-end or hop-to-hop? > RBL: That's a good question, but not important yet. There's some need = to sign the alert format. >=20 > Slide 9: Broadcast Reqs > ----------------------- > * Deliver msgs in common format so that a device that registers for = alerts gets and understands the alerts, regardless of the transport. >=20 > KD: I'm going to jump on this slide again. You're assuming a model = where the distributors and the recipients don't necessarily have a = relationship. You also need to take into account where the model knows = about the layer-2 protocols. > BR: the reason that we're not going down that road is because we = don't want to be limited based on the layer-2 > RBL: I think there's something like Skype, which is aware of the = layer-2 details, but wants to participate. We don't want to rely on = layer-2 characteristics, but take advantage of them if we can. If we = were relying on a UDP datagram, the app can listen for that; if the = network knows about this it can broadcast that UDP datagram content in = an optimized manner. > MW: I think we've got at least two mechanisms that can utilize this. > Scott Bradner: While that feature is available in some, it's not = available in all > BR: I think there's two ways to do that [the form of the alert]. Can = we rely on the recipient to announce what format it wants, or do we send = multiple and the recipient selects the one they want? > RBL: Let's take location as an example. > BR: I think we want to handle both. And we need to find a way to put = that into the CAP message, or wrap multiple CAP messages. >=20 > Slide 10: Broadcast Design Principals > ------------------------------------- > There's a question on ho >=20 > DC: There's a distinction that needs to be made that hasn't been made = yet. The distribution is the relaying function, and broadcast is the = receiving function. There's a distinction in what you need in the = broadcast stage versus what is needed in the end-to-end stage. To = incorporate both means you have an explosion of complexity. > BR: I understand, but I don't think=20 > RBL: The notion that I brought up in broadcast that needs to be = generalized. > RBL: And we want this registration thing to span across protocols. > BR: I think we can say that we need to have some of this filtering = done on both sides. I think we ought to say that the recipient always = needs to be able to filter, but the sender might be able to filter as an = optimization >=20 > Slide NN: Discussion > -------------------- >=20 > * Sounds like we might want to refactor into a high-level = transport/registration and a low-level transport. >=20 > * Mark Wood: I'm most interested in the broadcast side of things > * SB: I think we need to wait for the minutes before we start handing = out assignments. This has been a rich discussion that needs more = consideration. Secure CAP Format, Architecture, but not the rest just = yet. > KD: Is it a require to scale up to large networks > RBL: We want to=20 > MW: In the midst of the emerency, they are already at (or past) the = load point of failure. > MW: When you are talking about school closings, you're not at the = load to the point of failure, but if you're in an emergency you are. = There might be some things we want to do that are not scale considered, = and some we are. > BR: There are things we want to work in both large and small scales, = but we want as much commonality between the two as possible. > MW: Of course when you are dealing with going from single-cast to = multi-cast, there more information you need to convey to get there. For = instance, there are limits on the number of octets on some transports, = so targeting a multi-cast later on means there's less data you can send = in the first place, but if you're targetting a smaller distribution you = can include things like images. > SB: I think this has been a good discussion, and there's things for = the chairs to decide. > - m&m >=20 > Matt Miller - > Collaboration Software Group - Cisco Systems, Inc. >=20 --Apple-Mail=_A1BDA74B-8CF8-4CC8-974C-7ADD14EE0432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii here = are the minutes of today's ATOCA virtual interim meeting - thanks to = Matt for his notes

Scott

Begin = forwarded message:

From: Matt Miller <mamille2@cisco.com>
Subject: = ATOCA WG Interim Meeting = Notes/Minutes
Date: September 13, 2011 5:05:39 PM = EDT
To: Scott Bradner <sob@harvard.edu>
ATOCA Interim Virtual Meeting - = 2011-09-13T20:00:00Z
=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=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Slide 2: How Alerts work Today -- = overview
------------------------------------------
two-step = model:
- authorities distribute alert to subscribers (networks) - one = protocol
- networks broadcast alert to recipients without =

Brian Rosen: Current systems do this, but not sure we want to = make the jump they ought to do it this way.
RLB: this is a question = to answer is if two systems with different protocols is the right = approach
Keith Drage: Some things are not going to change (e.g. = mobile phones)

Slide 3: how alerts work today -- = distribution
----------------------------------------------
small, = static list
some prior art

Slide 4: How alerts work today -- = broadcast
-------------------------------------------
large, very = dynamic list
depends on what device is connected to/listening = on
some prior art

Slide 5: How alerts work = tomorrow?
----------------------------------
One approach: extend = existing architecture/frameworks to IP
* nice to bridge alerts in = addition to packets (e.g. cell to wifi)

Slide 6: Standards = Requirements
-------------------------------
If we expect some = arbitrary IP device to receive alerts, then we need to define a standard = for
BR: Showing two-level of distribution is way too simplistic; = there's really many levels of distribution. The cell phone example is = one example of three-level.
Dave Crocker: One of the things in these = types of discussions is if these models are adequate
BR: I = agree with that, and that's why I think there's no technical need that = distinguishes the distro side from the broadcast side
RBL: In the = distro model, you have a fixed layer that needs/wants robustness, while = the broadcast model doesn't need or support that
BR: I think the = fundamentals are identical
RBL: I think these things look more alike = than they are different
DR: What different mechanisms do you see for = systems in place, mine is email. My model is MUA to MTA which is = incredibly simplistic, but still useful for discussion. While = there are some others that have more elaborate models built on the first = to cover specific discussions.
Mark Wood: One of the things we found = in researching using mobile networks. You need to stop look at = point-to-point protocols and start looking at point-to-multipoint in = order to scale. If a network wishes to particpate, while their = network is small, the recipient number is very large, and geolocation a = factor.
BR: I think the distribution model is not 1:1, but that = there are some number of intermiediaries.
MW: I think there are = things to be concerned about within and across the layers. We need = to make sure we carry enough information for next stage to continue = (e.g. the alert polygon)
BR: I agree that we have these things = to worry about. I think the geolocation filtering needs to be = applied at various levels.
MW: I think this simplication is = useful for moving forward, but we need to make sure geoloc information = is tranmitted
KD: Until we define the intermediary, we don't = know what information we need to include. Second, the assertion = that if there's IP, we need a standard is not necessary. Such as = if you're just using text.
DC: Even if you are using text, you = need to do profiling, and there are 3 or 4 different ways to = profile
RLB: In either case, we need an RFC to define these = things.
James Polk: There's another aspect you're glossing over; = you're only focusing on national alerts. Not everywhere that FiOS = is will get the same alert.   Sometimes only a very small = slice of FiOS will get it.

Slide 7: Proposed = Milestones
----------------------------
* architecture = document
* secure alert format (e.g. signatures)
* protocol(s) to = push this stuff around (currently 2)

Slide 8: Secure Alert = Format
----------------------------
* want end-to-end security = without relying on layer-2

BR: There's lots of security = properties, but you're lumping them altogether. You need integrity = protection end-to-end, but maybe not authentication.
RBL: I'm going = to argue that's a concern with key distribution, and not the = formats.
RBL: To paraphrase for Brian, we want to know the authority = that sent the alert really was who they said they are; and when I travel = to Luxembourg, I want to receive alerts but I don't know how to verify = that it's the authority that's sending it to me?
BR: Are we = sure we need end-to-end, or is hop-to-hop enough?
DC: That is a = very important but very low-level question. The high-level = question is whether the recipient needs to validate the integrity of the = sender.
JP: There will be multiple distribution = authorities
BR: Again, do we need end-to-end or = hop-to-hop?
RBL: That's a good question, but not important yet. = There's some need to sign the alert format.

Slide 9: = Broadcast Reqs
-----------------------
* Deliver msgs in common = format so that a device that registers for alerts gets and understands = the alerts, regardless of the transport.

KD: I'm going to = jump on this slide again. You're assuming a model where the = distributors and the recipients don't necessarily have a relationship. = You also need to take into account where the model knows about the = layer-2 protocols.
BR: the reason that we're not going down = that road is because we don't want to be limited based on the = layer-2
RBL: I think there's something like Skype, which is aware of = the layer-2 details, but wants to participate. We don't want to = rely on layer-2 characteristics, but take advantage of them if we can. = If we were relying on a UDP datagram, the app can listen for that; = if the network knows about this it can broadcast that UDP datagram = content in an optimized manner.
MW: I think we've got at least = two mechanisms that can utilize this.
Scott Bradner: While that = feature is available in some, it's not available in all
BR: I = think there's two ways to do that [the form of the alert]. Can we rely = on the recipient to announce what format it wants, or do we send = multiple and the recipient selects the one they want?
RBL: Let's take = location as an example.
BR: I think we want to handle both. = And we need to find a way to put that into the CAP message, or = wrap multiple CAP messages.

Slide 10: Broadcast Design = Principals
-------------------------------------
There's a = question on ho

DC: There's a distinction that needs to be = made that hasn't been made yet. The distribution is the relaying = function, and broadcast is the receiving function. There's a = distinction in what you need in the broadcast stage versus what is = needed in the end-to-end stage. To incorporate both means you have = an explosion of complexity.
BR: I understand, but I don't think =
RBL: The notion that I brought up in broadcast that needs to be = generalized.
RBL: And we want this registration thing to span across = protocols.
BR: I think we can say that we need to have some of = this filtering done on both sides. I think we ought to say that = the recipient always needs to be able to filter, but the sender might be = able to filter as an optimization

Slide NN: = Discussion
--------------------

* Sounds like we might = want to refactor into a high-level transport/registration and a = low-level transport.

* Mark Wood: I'm most interested in = the broadcast side of things
* SB: I think we need to wait for = the minutes before we start handing out assignments. This has been = a rich discussion that needs more consideration. Secure CAP = Format, Architecture, but not the rest just yet.
KD: Is it a = require to scale up to large networks
RBL: We want to
MW: = In the midst of the emerency, they are already at (or past) the = load point of failure.
MW: When you are talking about school = closings, you're not at the load to the point of failure, but if you're = in an emergency you are. There might be some things we want to do = that are not scale considered, and some we are.
BR: There are = things we want to work in both large and small scales, but we want as = much commonality between the two as possible.
MW: Of course = when you are dealing with going from single-cast to multi-cast, there = more information you need to convey to get there. For instance, = there are limits on the number of octets on some transports, so = targeting a multi-cast later on means there's less data you can send in = the first place, but if you're targetting a smaller distribution you can = include things like images.
SB: I think this has been a good = discussion, and there's things for the chairs to decide.
- = m&m

Matt Miller - <mamille2@cisco.com>
Collabora= tion Software Group - Cisco Systems, = Inc.

= --Apple-Mail=_A1BDA74B-8CF8-4CC8-974C-7ADD14EE0432-- From hannes.tschofenig@gmx.net Tue Sep 13 23:51:00 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A288721F8C7E for ; Tue, 13 Sep 2011 23:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdu63HMaDrTz for ; Tue, 13 Sep 2011 23:51:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id AD62821F8C7B for ; Tue, 13 Sep 2011 23:50:59 -0700 (PDT) Received: (qmail invoked by alias); 14 Sep 2011 06:53:05 -0000 Received: from hermes1-224.csc.fi (EHLO hermes1-224.csc.fi) [193.166.163.224] by mail.gmx.net (mp027) with SMTP; 14 Sep 2011 08:53:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX184lSt6JLg40QhVDsM5PljxzLjeVcfJhRVJUb1SRY SMoSVa0hyXLnMb From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Sep 2011 09:53:05 +0300 Message-Id: <33B5FE76-F47E-4521-AB9E-E2FBC3112592@gmx.net> To: atoca@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 06:51:00 -0000 =46rom the meeting minutes:=20 > Slide 9: Broadcast Reqs > ----------------------- > * Deliver msgs in common format so that a device that registers for = alerts gets and understands the alerts, regardless of the transport. >=20 > KD: I'm going to jump on this slide again. You're assuming a model = where the distributors and the recipients don't necessarily have a = relationship. You also need to take into account where the model knows = about the layer-2 protocols. > BR: the reason that we're not going down that road is because we = don't want to be limited based on the layer-2 > RBL: I think there's something like Skype, which is aware of the = layer-2 details, but wants to participate. We don't want to rely on = layer-2 characteristics, but take advantage of them if we can. If we = were relying on a UDP datagram, the app can listen for that; if the = network knows about this it can broadcast that UDP datagram content in = an optimized manner. > MW: I think we've got at least two mechanisms that can utilize this. > Scott Bradner: While that feature is available in some, it's not = available in all > BR: I think there's two ways to do that [the form of the alert]. Can = we rely on the recipient to announce what format it wants, or do we send = multiple and the recipient selects the one they want? > RBL: Let's take location as an example. > BR: I think we want to handle both. And we need to find a way to put = that into the CAP message, or wrap multiple CAP messages. I have not been able to participate at the phone conference and so I am = trying to reconstruct the discussion based on the meeting minutes.=20 I fail to see how a broadcast mechanism can distribute multiple CAP = message in a single UDP message or how it can provide different formats = to different receivers.=20 I also confused by the first sentence. I hope that the idea of defining = a broadcast mechanism is to define one rather than multiple.=20= From keith.drage@alcatel-lucent.com Wed Sep 14 03:39:48 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318D521F8CAA for ; Wed, 14 Sep 2011 03:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.917 X-Spam-Level: X-Spam-Status: No, score=-105.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMF0VnfpmU3J for ; Wed, 14 Sep 2011 03:39:47 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id DD35F21F8CA9 for ; Wed, 14 Sep 2011 03:39:46 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8EAffip022155 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Sep 2011 12:41:46 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 14 Sep 2011 12:41:43 +0200 From: "DRAGE, Keith (Keith)" To: Scott O Bradner , "atoca@ietf.org" Date: Wed, 14 Sep 2011 12:41:42 +0200 Thread-Topic: [atoca] Fwd: ATOCA WG Interim Meeting Notes/Minutes Thread-Index: AcxycFr8daPyNjrDRSu2Db694Yf1VgAWM1Xg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [atoca] Fwd: ATOCA WG Interim Meeting Notes/Minutes X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 10:39:48 -0000 Some corrections. "KD: =A0Until we define the intermediary, we don't know what information we= need to include. =A0Second, the assertion that if there's IP, we need a st= andard is not necessary. =A0Such as if you're just using text." My point in the second sentence is not brought out. I contended that the au= thor appeared to be jumping directly from the fact that it was an IP based = protocol, to the assertion that IETF needed to define a standard for it. I = pointed out that if there is just a need to render text, there may not be a= need for a new standard. I wish to see the identification of an interopera= bility need before we progress to defining a standards track document. (At = this point there was a discussion with Dave Crocker about profiles and that= these are RFCs which I don't think affects my main point). "KD: =A0I'm going to jump on this slide again. =A0You're assuming a model w= here the distributors and the recipients don't necessarily have a relations= hip. =A0You also need to take into account where the model knows about the = layer-2 protocols." I was pointing out here that there could well be a relationship between dis= tributor and recipient whereby distributor downloaded application to user w= hen the user registered for the service, and if that was the use case, it r= equired very little or no standards track activity. Further I pointed out i= n response to a point about layer two capability that all the discussion in= the past had included some form of subscription or registration to the ser= vice, and layer 2 characteristics of the recipient could be passed from rec= ipient to distributor at that point. "KD: =A0Is it a require to scale up to large networks" This wasn't the question I asked. I asked if we would deal with scaling req= uirements as part of the architecture discussion (and I don't think that qu= estion got answered). Regards Keith ________________________________________ From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of S= cott O Bradner Sent: 14 September 2011 00:53 To: atoca@ietf.org Subject: [atoca] Fwd: ATOCA WG Interim Meeting Notes/Minutes here are the minutes of today's ATOCA virtual interim meeting - thanks to M= att for his notes Scott Begin forwarded message: From: Matt Miller Subject: ATOCA WG Interim Meeting Notes/Minutes Date: September 13, 2011 5:05:39 PM EDT To: Scott Bradner ATOCA Interim Virtual Meeting - 2011-09-13T20:00:00Z =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Slide 2: How Alerts work Today -- overview ------------------------------------------ two-step model: - authorities distribute alert to subscribers (networks) - one protocol - networks broadcast alert to recipients without=20 Brian Rosen: Current systems do this, but not sure we want to make the jump= they ought to do it this way. RLB: this is a question to answer is if two systems with different protocol= s is the right approach Keith Drage: Some things are not going to change (e.g. mobile phones) Slide 3: how alerts work today -- distribution ---------------------------------------------- small, static list some prior art Slide 4: How alerts work today -- broadcast ------------------------------------------- large, very dynamic list depends on what device is connected to/listening on some prior art Slide 5: How alerts work tomorrow? ---------------------------------- One approach: extend existing architecture/frameworks to IP * nice to bridge alerts in addition to packets (e.g. cell to wifi) Slide 6: Standards Requirements ------------------------------- If we expect some arbitrary IP device to receive alerts, then we need to de= fine a standard for=20 BR: Showing two-level of distribution is way too simplistic; there's really= many levels of distribution. The cell phone example is one example of thre= e-level. Dave Crocker: One of the things in these types of discussions is if these m= odels are adequate BR: =A0I agree with that, and that's why I think there's no technical need = that distinguishes the distro side from the broadcast side RBL: In the distro model, you have a fixed layer that needs/wants robustnes= s, while the broadcast model doesn't need or support that BR: I think the fundamentals are identical RBL: I think these things look more alike than they are different DR: What different mechanisms do you see for systems in place, mine is emai= l. =A0My model is MUA to MTA which is incredibly simplistic, but still usef= ul for discussion. =A0While there are some others that have more elaborate = models built on the first to cover specific discussions. Mark Wood: One of the things we found in researching using mobile networks.= =A0You need to stop look at point-to-point protocols and start looking at = point-to-multipoint in order to scale. =A0If a network wishes to particpate= , while their network is small, the recipient number is very large, and geo= location a factor. BR: =A0I think the distribution model is not 1:1, but that there are some n= umber of intermiediaries. MW: =A0I think there are things to be concerned about within and across the= layers. =A0We need to make sure we carry enough information for next stage= to continue (e.g. the alert polygon) BR: =A0I agree that we have these things to worry about. =A0I think the geo= location filtering needs to be applied at various levels. MW: =A0I think this simplication is useful for moving forward, but we need = to make sure geoloc information is tranmitted KD: =A0Until we define the intermediary, we don't know what information we = need to include. =A0Second, the assertion that if there's IP, we need a sta= ndard is not necessary. =A0Such as if you're just using text. DC: =A0Even if you are using text, you need to do profiling, and there are = 3 or 4 different ways to profile RLB: In either case, we need an RFC to define these things. James Polk: There's another aspect you're glossing over; you're only focusi= ng on national alerts. =A0Not everywhere that FiOS is will get the same ale= rt. =A0=A0Sometimes only a very small slice of FiOS will get it. Slide 7: Proposed Milestones ---------------------------- * architecture document * secure alert format (e.g. signatures) * protocol(s) to push this stuff around (currently 2) Slide 8: Secure Alert Format ---------------------------- * want end-to-end security without relying on layer-2 BR: =A0There's lots of security properties, but you're lumping them altoget= her. =A0You need integrity protection end-to-end, but maybe not authenticat= ion. RBL: I'm going to argue that's a concern with key distribution, and not the= formats. RBL: To paraphrase for Brian, we want to know the authority that sent the a= lert really was who they said they are; and when I travel to Luxembourg, I = want to receive alerts but I don't know how to verify that it's the authori= ty that's sending it to me? BR: =A0Are we sure we need end-to-end, or is hop-to-hop enough? DC: =A0That is a very important but very low-level question. =A0The high-le= vel question is whether the recipient needs to validate the integrity of th= e sender. JP: =A0There will be multiple distribution authorities BR: =A0Again, do we need end-to-end or hop-to-hop? RBL: That's a good question, but not important yet. =A0There's some need to= sign the alert format. Slide 9: Broadcast Reqs ----------------------- * Deliver msgs in common format so that a device that registers for alerts = gets and understands the alerts, regardless of the transport. KD: =A0I'm going to jump on this slide again. =A0You're assuming a model wh= ere the distributors and the recipients don't necessarily have a relationsh= ip. =A0You also need to take into account where the model knows about the l= ayer-2 protocols. BR: =A0the reason that we're not going down that road is because we don't w= ant to be limited based on the layer-2 RBL: I think there's something like Skype, which is aware of the layer-2 de= tails, but wants to participate. =A0We don't want to rely on layer-2 charac= teristics, but take advantage of them if we can. =A0If we were relying on a= UDP datagram, the app can listen for that; if the network knows about this= it can broadcast that UDP datagram content in an optimized manner. MW: =A0I think we've got at least two mechanisms that can utilize this. Scott Bradner: =A0While that feature is available in some, it's not availab= le in all BR: =A0I think there's two ways to do that [the form of the alert]. Can we = rely on the recipient to announce what format it wants, or do we send multi= ple and the recipient selects the one they want? RBL: Let's take location as an example. BR: =A0I think we want to handle both. =A0And we need to find a way to put = that into the CAP message, or wrap multiple CAP messages. Slide 10: Broadcast Design Principals ------------------------------------- There's a question on ho DC: =A0There's a distinction that needs to be made that hasn't been made ye= t. =A0The distribution is the relaying function, and broadcast is the recei= ving function. =A0There's a distinction in what you need in the broadcast s= tage versus what is needed in the end-to-end stage. =A0To incorporate both = means you have an explosion of complexity. BR: =A0I understand, but I don't think=20 RBL: The notion that I brought up in broadcast that needs to be generalized= . RBL: And we want this registration thing to span across protocols. BR: =A0I think we can say that we need to have some of this filtering done = on both sides. =A0I think we ought to say that the recipient always needs t= o be able to filter, but the sender might be able to filter as an optimizat= ion Slide NN: Discussion -------------------- * =A0Sounds like we might want to refactor into a high-level transport/regi= stration and a low-level transport. * Mark Wood: =A0I'm most interested in the broadcast side of things * SB: =A0I think we need to wait for the minutes before we start handing ou= t assignments. =A0This has been a rich discussion that needs more considera= tion. =A0Secure CAP Format, Architecture, but not the rest just yet. KD: =A0Is it a require to scale up to large networks RBL: We want to=20 MW: =A0In the midst of the emerency, they are already at (or past) the load= point of failure. MW: =A0When you are talking about school closings, you're not at the load t= o the point of failure, but if you're in an emergency you are. =A0There mig= ht be some things we want to do that are not scale considered, and some we = are. BR: =A0There are things we want to work in both large and small scales, but= we want as much commonality between the two as possible. MW: =A0Of course when you are dealing with going from single-cast to multi-= cast, there more information you need to convey to get there. =A0For instan= ce, there are limits on the number of octets on some transports, so targeti= ng a multi-cast later on means there's less data you can send in the first = place, but if you're targetting a smaller distribution you can include thin= gs like images. SB: =A0I think this has been a good discussion, and there's things for the = chairs to decide. - m&m Matt Miller - Collaboration Software Group - Cisco Systems, Inc. From mark.wood@drcf.net Wed Sep 14 06:58:44 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3D121F8BFE for ; Wed, 14 Sep 2011 06:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwz8SjGxuPCN for ; Wed, 14 Sep 2011 06:58:43 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774EA21F8C19 for ; Wed, 14 Sep 2011 06:58:43 -0700 (PDT) X-Trace: 423004044/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAP6ycE5RVitW/2dsb2JhbABBp2Z5gVMBBggyHBUHFAQBBgMhAzsaBh4BAQQeDYdhljKlQ4EFBJhIh3SEKQ X-IronPort-AV: E=Sophos;i="4.68,380,1312153200"; d="scan'208";a="423004044" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 14 Sep 2011 15:00:51 +0100 From: "'Mark'" Sender: "Mark" To: In-Reply-To: <33B5FE76-F47E-4521-AB9E-E2FBC3112592@gmx.net> Date: Wed, 14 Sep 2011 15:00:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcxyqvxPIwa6fIX9QT2OF9AiW5xoFwAN8k2A X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20110914135843.774EA21F8C19@ietfa.amsl.com> Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 13:58:44 -0000 Hans question was; -- quote -- I fail to see how a broadcast mechanism can distribute multiple CAP message in a single UDP message or how it can provide different formats to different receivers. I also confused by the first sentence. I hope that the idea of defining a broadcast mechanism is to define one rather than multiple. -- unqote -- Chaps; Hans makes a valid point and one that needs much more further discussion. I don't know the answer to this yet but we need to work it out. I know that this forum is not a cell broadcast forum, but since CB is the only model we have at the moment, some (not all) of the issues with it will be the same. With CB the available payload space is too small to transmit the whole CAP message, and so only the 'Headline' text is transmitted, the rest of the CAP message is stripped off by the Alert Gateway (or some other unit). The geo specificity is implied by which cell the terminal has camped on, so the cell broadcast centre CBC receives the polygon and the text, but only the text is sent over the air. However a cell can be several km across and so this does cause some fuzzyness as to geo resolution. It is possible to also transmit the 'Polygon' part of the CAP message also, so that terminals which have some sort of location system, can determine if they are inside the polygon or not. If not, the terminal ignores the message. (This causes the resolution to be the same as that of the terminals geo location system). But this is still very small amount of data compared to the whole of the CAP message. The full CAP message is (in CB) used by the various gateways but only the text (and perhaps also in the future, the polygon) will be sent to the terminal. In the near future many governments will need to transmit in multiple languages, and while how to do this is still the subject of much heated debate, one method is to repeat the message, and either have an additional coding scheme to indicate the language (which is ignored by terminals not supporting that language) or by using a different Message Identifier (Multicast address) for each language. The phone then ignores any versions of the message not appropriate. The advantage of this approach is that there is no 'stateful' relationship between the terminal and the system, which means that it is passively mass scalable at the moment of use. The disadvantage is that only those formats that the government have chosen to transmit are multicast. However devices could subscribe to another push technology in some cases, but on a 'best effort' basis during the acute phase of overload. In fact there is no way to prevent anyone from subscribing to 'Google Hub' if they want to. Regarding IP multicast, as you know I am not an IP expert but I understand that neither IGMP, SIP nor PIM sparse mode, seem to have a geo specific part implemented. This seems to indicate that only quite coarse geo resolution based on administrator settings would occur. Therefore in that case perhaps 'polygon' information would be sent to the terminal so that the intelligence of location is done by the terminal. Given that there are not such restrictions on data size in IP, perhaps in some cases the whole of the CAP message (or a subset of it) can be multicast and we let the terminal decide what parts of it are relevant. Naturally we repeat the multicast periodically (eg once per minute for 20 minutes), but there is only one copy for all stations on an access link. Since XML is extensible, several different version of the message can be multicast in the same package, and we let the terminal take what it needs. This may be less traffic than letting 10^7 terminals try to haggle for stateful relationships with the distribution servers. I would be very interested in hearing observations on this. Warm regards mark Wood DRCF. From bd2985@att.com Wed Sep 14 07:14:27 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34A921F8C40 for ; Wed, 14 Sep 2011 07:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.485 X-Spam-Level: X-Spam-Status: No, score=-106.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChpVDiO3KIzS for ; Wed, 14 Sep 2011 07:14:23 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB1821F8C18 for ; Wed, 14 Sep 2011 07:14:22 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1316009790!19395123!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27594 invoked from network); 14 Sep 2011 14:16:31 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-8.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Sep 2011 14:16:31 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8EEGUcd017429; Wed, 14 Sep 2011 09:16:30 -0500 Received: from WABOTH9MSGHUB8D.ITServices.sbc.com (waboth9msghub8d.itservices.sbc.com [135.163.35.93]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8EEGGLW017126; Wed, 14 Sep 2011 09:16:24 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8D.ITServices.sbc.com ([135.163.35.93]) with mapi id 14.01.0289.001; Wed, 14 Sep 2011 07:16:19 -0700 From: "DALY, BRIAN K" To: "'Mark'" , "atoca@ietf.org" Thread-Topic: [atoca] Broadcast Reqs Thread-Index: AcxyqvxPIwa6fIX9QT2OF9AiW5xoFwAN8k2AAAFobcA= Date: Wed, 14 Sep 2011 14:16:19 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F96234979@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <33B5FE76-F47E-4521-AB9E-E2FBC3112592@gmx.net> <20110914135843.774EA21F8C19@ietfa.amsl.com> In-Reply-To: <20110914135843.774EA21F8C19@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 14:14:27 -0000 To your comments: >With CB the available payload space is too small to transmit the whole CAP message, and so only the 'Headline' text is transmitted, the rest of the CA= P message is stripped off by the Alert Gateway (or some other unit). If you are talking about CMAS, this is not entirely correct. The CAP "headl= ine' is not necessarily the field that is broadcast by the cell broadcast s= ervice. >It is possible to also transmit the 'Polygon' part of the CAP message also= , so that terminals which have some sort of location system, can determine if they are inside the polygon or not. This is not defined in the current PWS/CMAS specifications. > In the near future many governments will need to transmit in multiple languages, and while how to do this is still the subject of much heated debate, one method is to repeat the message, and either have an additional coding scheme to indicate the language (which is ignored by terminals not supporting that language) or by using a different Message Identifier (Multicast address) for each language. ATIS is currently developing CMAS standards for Spanish. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of '= Mark' Sent: Wednesday, September 14, 2011 7:01 AM To: atoca@ietf.org Subject: Re: [atoca] Broadcast Reqs Hans question was; -- quote -- I fail to see how a broadcast mechanism can distribute multiple CAP message in a single UDP message or how it can provide different formats to differen= t receivers.=20 I also confused by the first sentence. I hope that the idea of defining a broadcast mechanism is to define one rather than multiple.=20 -- unqote -- Chaps; Hans makes a valid point and one that needs much more further discussion. I don't know the answer to this yet but we need to work it out. =20 I know that this forum is not a cell broadcast forum, but since CB is the only model we have at the moment, some (not all) of the issues with it will be the same. With CB the available payload space is too small to transmit the whole CAP message, and so only the 'Headline' text is transmitted, the rest of the CA= P message is stripped off by the Alert Gateway (or some other unit). The geo specificity is implied by which cell the terminal has camped on, so the cel= l broadcast centre CBC receives the polygon and the text, but only the text i= s sent over the air.=20 However a cell can be several km across and so this does cause some fuzzyness as to geo resolution.=20 It is possible to also transmit the 'Polygon' part of the CAP message also, so that terminals which have some sort of location system, can determine if they are inside the polygon or not. If not, the terminal ignores the message. (This causes the resolution to be the same as that of the terminal= s geo location system). =20 But this is still very small amount of data compared to the whole of the CA= P message. The full CAP message is (in CB) used by the various gateways but only the text (and perhaps also in the future, the polygon) will be sent to the terminal.=20 In the near future many governments will need to transmit in multiple languages, and while how to do this is still the subject of much heated debate, one method is to repeat the message, and either have an additional coding scheme to indicate the language (which is ignored by terminals not supporting that language) or by using a different Message Identifier (Multicast address) for each language. The phone then ignores any versions of the message not appropriate.=20 The advantage of this approach is that there is no 'stateful' relationship between the terminal and the system, which means that it is passively mass scalable at the moment of use. The disadvantage is that only those formats that the government have chosen to transmit are multicast.=20 However devices could subscribe to another push technology in some cases, but on a 'best effort' basis during the acute phase of overload. In fact there is no way to prevent anyone from subscribing to 'Google Hub' if they want to.=20 Regarding IP multicast, as you know I am not an IP expert but I understand that neither IGMP, SIP nor PIM sparse mode, seem to have a geo specific par= t implemented. This seems to indicate that only quite coarse geo resolution based on administrator settings would occur.=20 Therefore in that case perhaps 'polygon' information would be sent to the terminal so that the intelligence of location is done by the terminal. Give= n that there are not such restrictions on data size in IP, perhaps in some cases the whole of the CAP message (or a subset of it) can be multicast and we let the terminal decide what parts of it are relevant. Naturally we repeat the multicast periodically (eg once per minute for 20 minutes), but there is only one copy for all stations on an access link.=20 Since XML is extensible, several different version of the message can be multicast in the same package, and we let the terminal take what it needs.= =20 This may be less traffic than letting 10^7 terminals try to haggle for stateful relationships with the distribution servers. I would be very interested in hearing observations on this. Warm regards mark Wood DRCF. =20 _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From mark.wood@drcf.net Wed Sep 14 07:30:02 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC8321F8CB6 for ; Wed, 14 Sep 2011 07:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_20=-0.74, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8oFt0KfbvWu for ; Wed, 14 Sep 2011 07:30:01 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by ietfa.amsl.com (Postfix) with ESMTP id E28D821F8CBB for ; Wed, 14 Sep 2011 07:29:47 -0700 (PDT) X-Trace: 477852821/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHAHe5cE5RVitW/2dsb2JhbABBmS+ON3mBUwEGCDIcMAUGAyE+GgYeAQEEHg2HYZYgpUmBBQSMRowCh3SEKQ X-IronPort-AV: E=Sophos;i="4.68,380,1312153200"; d="scan'208";a="477852821" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 14 Sep 2011 15:31:54 +0100 From: "Mark" To: In-Reply-To: <95C5C7A891135E4685CCFAE997351F96234979@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Wed, 14 Sep 2011 15:31:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcxyqvxPIwa6fIX9QT2OF9AiW5xoFwAN8k2AAAFobcAAAE1IkA== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20110914142947.E28D821F8CBB@ietfa.amsl.com> Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 14:30:02 -0000 Friends; Thanks for your clarifications Brian, -BD- If you are talking about CMAS, this is not entirely correct. The CAP "headline' is not necessarily the field that is broadcast by the cell broadcast service. -MW- Yes correct, the AGW is programmed to use whatever part of the CAP message is the appropriate part for that specific 'instance' of network and requirement from the sender. -BD- [polygon sending] is not defined in the current PWS/CMAS specifications. -MW- Yes, thanks for that clarification, while polygon transmission is 'possible' it is not currently defined or implemented by any present revision of PWS system. ATIS is currently developing CMAS standards for Spanish. -MW- I am pleased that progress in this matter is being made. From artbotterell@gmail.com Wed Sep 14 07:46:16 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCDE21F8CF5 for ; Wed, 14 Sep 2011 07:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5ajCVjQ94WC for ; Wed, 14 Sep 2011 07:46:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0B07121F8CBC for ; Wed, 14 Sep 2011 07:46:15 -0700 (PDT) Received: by gyd12 with SMTP id 12so1635853gyd.31 for ; Wed, 14 Sep 2011 07:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=5Qu7sUZ0c+ljzZIGbnL9hvlDS25CXcZsT8PGEdeqnqk=; b=OwAJXWrPJotczIvaFWoWIbNoBnyRQM+8XsU7jwG0it/Oivcq/9i7Pzz1AWJZKp9d// 2ouqjc9+zBvBz1gEMFfJ/HOXfVSRx/ANv/F7AE3DXw0J87yALsi2f+PwtKtllkird0gK M38hgtY/ol9nH6RKmsowGlRgL5U/b2+xJzv20= Received: by 10.236.178.10 with SMTP id e10mr42517441yhm.31.1316011705120; Wed, 14 Sep 2011 07:48:25 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id n27sm377104yhe.18.2011.09.14.07.48.22 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 07:48:23 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <20110914142947.E28D821F8CBB@ietfa.amsl.com> Date: Wed, 14 Sep 2011 07:48:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 14:46:16 -0000 Just as a reminder... there's a packed ASN.1 serialization available for = CAP as well as the XML format. Not sure how much of a payload size = reduction that achieves, but it might be significant. Also, it may be useful to distinguish explicitly between the = interoperable network-level format (CAP) and various technology-specific = presentation-level formats (CMAS text, CAP headline, SAME, siren = activation bit, etc.) My experience has been that those two situations = sometimes get conflated in discussion, which can cause confusion. =20 Usually the conversion from CAP to a presentation format is lossy and = therefore essentially a one-way trip, although I suppose it's possible = that some presentation schemes might actually involve adding information = (e.g., visual styling) from which the full original CAP data could be = retrieved later. - Art From artbotterell@gmail.com Wed Sep 14 09:05:11 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9215821F8B33 for ; Wed, 14 Sep 2011 09:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzQcejRbEqER for ; Wed, 14 Sep 2011 09:05:11 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id F1D9821F8B2F for ; Wed, 14 Sep 2011 09:05:10 -0700 (PDT) Received: by yie12 with SMTP id 12so1722359yie.31 for ; Wed, 14 Sep 2011 09:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=8HmBNVxuOa493YTEMm1lB0hrRMqJPgwlYmHsuFoJFS0=; b=x6FZ6E6KP4WJG9+G2vh2dUvm4P70wUPNTlCQaH3Dg2+b7SzM+sDGObSNURl7ki4beV 0rP4MZvbHSNoHZ3q9bjm0MGyNMkye4Qd1e8gVBdggjOaQ6O3alomBhDxNlsIRsKBd0ys EA3NndtOgzluLphgs0dtlmzp0AjlSPH2vLWSg= Received: by 10.90.47.7 with SMTP id u7mr3621308agu.143.1316016440036; Wed, 14 Sep 2011 09:07:20 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net [99.182.125.96]) by mx.google.com with ESMTPS id g17sm4235255ana.15.2011.09.14.09.07.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Sep 2011 09:07:18 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: Date: Wed, 14 Sep 2011 09:07:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 16:05:11 -0000 On Sep 14, 2011, at 8:00 AM, Brian Rosen wrote: > I would like to avoid ASN.1 if possible. Any particular reason, or just personal preference? I hold no personal = brief for the ASN.1 serialization, but it is the standardized approach = to compacting CAP without losing data. > One of the things I want to explore is how we do appropriate mapping = from what is in the message to what is presented. I'm not talking about = style issues. Some devices really would be best giving a shorter = version of the alert, while others have better displays and = interactivity mechanisms that allow a richer presentation. We might = want to make sure we can send/extract what a particular recipient = needed. As mentioned earlier, a "down-conversion" from CAP to something = presentation-specific is almost always a one-way trip, and thus, to = maximize interoperability, should be done as far downstream... as close = to the receiving edge... as possible. It may be wisest to maintain a = fairly strict separation between the interoperable network and the = technology-specific presentation, lest we wind up with a proliferation = of semi-compatible formats floating around, which would sort of defeat = the basic objective of CAP. > I also want to be able to label things like a link for more = information in a way that a renderer can do something appropriate with = it. The CAP resource block supports the sort of filtering I think you're = after. - Art From Martin.Thomson@commscope.com Thu Sep 15 00:07:28 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B7821F84C5 for ; Thu, 15 Sep 2011 00:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0N3cKT0ywSt for ; Thu, 15 Sep 2011 00:07:27 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id C69D521F84C2 for ; Thu, 15 Sep 2011 00:07:27 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-4d-4e71a4b08a78 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id D5.22.19263.0B4A17E4; Thu, 15 Sep 2011 02:09:36 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 15 Sep 2011 02:09:36 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 15 Sep 2011 15:09:32 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , Hannes Tschofenig Date: Thu, 15 Sep 2011 15:09:30 +0800 Thread-Topic: Alert signing Thread-Index: AcxzWPQgP0gWWX6NQTyISXc8krXrTgAG3GRg Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> In-Reply-To: <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "atoca@ietf.org" Subject: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 07:07:28 -0000 (moving this topic on-list to include a few more folks) (as individual) On 2011-09-15 at 13:38:33, Richard L. Barnes wrote: > > * In slide 8 you talk about the secure alert format. In the Prague > IETF presentation I spoke about security and there was a big outcry=20 > about using XML (and XMLDSIG) to protect the CAP message. Since we=20 > settled with CAP as a format I wonder where we are with this issue.=20 > The only alternative I see is to switch to JSON and use JSON based signin= g. > This would deal with our problems, I believe. >=20 > I think CMS is also viable, but I don't care that much. I hesitate a=20 > little to use the WOES/JOSE stuff, only because it's not there yet. I understand the reservations about JOSE, but the very fact that JOSE even = exists should tell you something about this. I think that the primary considerations are: - size - practicality of implementation Smaller size will help us avoid some problems, such as alert fragmentation.= Smaller packets are less likely to cause congestion. But once beyond som= e as-yet-undetermined threshold, size becomes a secondary concern and we ha= ve to turn to the other. Once any hard limits are deal with, we need to optimize for adoption. XMLD= SIG is not a practically interoperable technology. We might find that CAP = in PER with CMS gives us the best size overall, but that it doesn't get imp= lemented at all because it sucks to implement. Or even just because it loo= ks hard. From trutkowski@netmagic.com Thu Sep 15 01:23:26 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A721F8568 for ; Thu, 15 Sep 2011 01:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dd5enX7ix+6i for ; Thu, 15 Sep 2011 01:23:25 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by ietfa.amsl.com (Postfix) with ESMTP id 96C4621F8558 for ; Thu, 15 Sep 2011 01:23:25 -0700 (PDT) Received: from [192.168.1.74] ([unknown] [93.63.185.230]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LRK00HG1228U2A0@vms173017.mailsrvcs.net> for atoca@ietf.org; Thu, 15 Sep 2011 03:25:26 -0500 (CDT) Message-id: <4E71B670.1080104@netmagic.com> Date: Thu, 15 Sep 2011 10:25:20 +0200 From: Tony Rutkowski Organization: NetMagic Associates User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:5.0) Gecko/20110701 Thunderbird/5.0 MIME-version: 1.0 To: Art Botterell References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: atoca@ietf.org Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 08:23:26 -0000 Hi Art, As the chair of the group that produced the X.1303 version of CAP, including the ASN.1 module, my recollection at the time was that the ASN.1 representation was roughly one half the size. Where large numbers of emergency messages are sent in a burst and delivery delays are critical, the value proposition is obvious. Although clearly ASN.1 use has diminished, translations are readily accomplish, and the above factors make inclusion of the ASN.1 option rather desirable. --tony On 9/14/2011 6:07 PM, Art Botterell wrote: > Any particular reason, or just personal preference? I hold no personal brief for the ASN.1 serialization, but it is the standardized approach to compacting CAP without losing data. From hannes.tschofenig@gmx.net Thu Sep 15 07:17:00 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D1421F8A80 for ; Thu, 15 Sep 2011 07:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.056 X-Spam-Level: X-Spam-Status: No, score=-101.056 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L5SZUa8CDVv for ; Thu, 15 Sep 2011 07:16:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0D9AD21F8A55 for ; Thu, 15 Sep 2011 07:16:58 -0700 (PDT) Received: (qmail invoked by alias); 15 Sep 2011 14:19:05 -0000 Received: from unknown (EHLO [10.255.132.204]) [192.100.123.77] by mail.gmx.net (mp011) with SMTP; 15 Sep 2011 16:19:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3TNoTzB/37EREWlP+TatBKb3TrHoZmIwV7xX2Oe udelkq+/gv+fPZ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E71B670.1080104@netmagic.com> Date: Thu, 15 Sep 2011 17:19:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3AA0E52C-E14E-40FD-BE63-43A0FBE5F5CC@gmx.net> References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> <4E71B670.1080104@netmagic.com> To: trutkowski@netmagic.com X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 14:17:00 -0000 Hi Tony, Hi Art,=20 I am not so much concerned about the delivery bursts and delays in = sending alerts but rather whether they fit into a UDP datagram without = requiring fragmentation. The total size includes security related = payload as well.=20 Ciao Hannes On Sep 15, 2011, at 11:25 AM, Tony Rutkowski wrote: > Hi Art, >=20 > As the chair of the group that produced the X.1303 version of > CAP, including the ASN.1 module, my recollection at the time > was that the ASN.1 representation was roughly one half the > size. Where large numbers of emergency messages are sent in a > burst and delivery delays are critical, the value proposition is > obvious. Although clearly ASN.1 use has diminished, translations > are readily accomplish, and the above factors make inclusion of > the ASN.1 option rather desirable. >=20 > --tony >=20 > On 9/14/2011 6:07 PM, Art Botterell wrote: >> Any particular reason, or just personal preference? I hold no = personal brief for the ASN.1 serialization, but it is the standardized = approach to compacting CAP without losing data. >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From Hannes.Tschofenig@gmx.net Thu Sep 15 07:21:12 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4A721F8B34 for ; Thu, 15 Sep 2011 07:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMJhivfWDjKQ for ; Thu, 15 Sep 2011 07:21:12 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AF59721F8B26 for ; Thu, 15 Sep 2011 07:21:05 -0700 (PDT) Received: (qmail invoked by alias); 15 Sep 2011 14:23:16 -0000 Received: from unknown (EHLO [10.255.132.204]) [192.100.123.77] by mail.gmx.net (mp070) with SMTP; 15 Sep 2011 16:23:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/AMBqQyU/6DvdKj3aJdyOVHTxO/g0cQM0kmVCgr K0wLhK5CTFJg79 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> Date: Thu, 15 Sep 2011 17:23:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "atoca@ietf.org" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 14:21:12 -0000 On Sep 15, 2011, at 10:09 AM, Thomson, Martin wrote: > XMLDSIG is not a practically interoperable technology. We might find = that CAP in PER with CMS gives us the best size overall, but that it = doesn't get implemented at all because it sucks to implement. Or even = just because it looks hard. I wonder whether there are implementations for the ASN.1 encoding of = CAP.=20 You are right that the size considerations are difficult to deal with = since the content of the CAP message is essentially non-restricted. = Switching to JSON will not help with this issue. IP fragmentation will = cause problems with NATs and firewalls, which are unfortunately found in = almost every real network today.=20 From artbotterell@gmail.com Thu Sep 15 07:46:45 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F273821F863E for ; Thu, 15 Sep 2011 07:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GpFr7t8HYA4 for ; Thu, 15 Sep 2011 07:46:44 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED821F88A0 for ; Thu, 15 Sep 2011 07:46:44 -0700 (PDT) Received: by iaby26 with SMTP id y26so1558190iab.31 for ; Thu, 15 Sep 2011 07:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=lztWSgiHaEzhZmOEUJISZLFiuzzw1TSobmUvsrhoIVA=; b=JzghXWtx4ywxb63lyWZx8g33lEplR5+S6waC93PcuNCj1H8IBl7rDjy2xRdUmPga14 zd88USzx0OWApwB2tqtJFaQThCy+5mY6bDVSIo6DDbfbTCqJlOh5LJShpW1Saq8KyL1o 1Ivd256JbA+udd4mGreXwljzECSQqclfn9zUg= Received: by 10.231.83.135 with SMTP id f7mr1946905ibl.90.1316098134771; Thu, 15 Sep 2011 07:48:54 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id el2sm5067124ibb.10.2011.09.15.07.48.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 07:48:53 -0700 (PDT) Sender: Art Botterell Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Art Botterell In-Reply-To: <4E71B670.1080104@netmagic.com> Date: Thu, 15 Sep 2011 07:48:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37F0CFF6-8D6A-4381-96A1-A2D1779FEAB1@incident.com> References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> <4E71B670.1080104@netmagic.com> To: trutkowski@netmagic.com, Eliot Christian X-Mailer: Apple Mail (2.1084) Cc: atoca@ietf.org Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 14:46:45 -0000 Yes, I'm thinking that a lot of the issue here is that the ASN.1 = serialization "looks hard." The (XML-based) caplib did seem to create a = comfort zone for implementers in the early days. Is there, or would it = be hard to create, a comparable reference implementation for ASN.1? =20 I could probably get some Carnegie Mellon grad students to do the = programming if someone had a few bucks to throw at the problem... - Art On Sep 15, 2011, at 1:25 AM, Tony Rutkowski wrote: > Hi Art, >=20 > As the chair of the group that produced the X.1303 version of > CAP, including the ASN.1 module, my recollection at the time > was that the ASN.1 representation was roughly one half the > size. Where large numbers of emergency messages are sent in a > burst and delivery delays are critical, the value proposition is > obvious. Although clearly ASN.1 use has diminished, translations > are readily accomplish, and the above factors make inclusion of > the ASN.1 option rather desirable. >=20 > --tony >=20 > On 9/14/2011 6:07 PM, Art Botterell wrote: >> Any particular reason, or just personal preference? I hold no = personal brief for the ASN.1 serialization, but it is the standardized = approach to compacting CAP without losing data. >=20 From olivier.dubuisson@orange-ftgroup.com Thu Sep 15 08:00:01 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787BB21F8715 for ; Thu, 15 Sep 2011 08:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU5Q4zxdwLUK for ; Thu, 15 Sep 2011 08:00:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 00C6F21F867F for ; Thu, 15 Sep 2011 07:59:59 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 9F0C03B44D3; Thu, 15 Sep 2011 17:02:10 +0200 (CEST) Received: from p-mail3.rd.francetelecom.fr (unknown [10.192.128.50]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 841DFC805D; Thu, 15 Sep 2011 17:02:10 +0200 (CEST) Received: from p-mail3.rd.francetelecom.fr (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F3312378002; Thu, 15 Sep 2011 17:05:58 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (ftrdsmtp1.rd.francetelecom.fr [10.192.128.46]) by p-mail3.rd.francetelecom.fr (Postfix) with ESMTP id C8F58378001; Thu, 15 Sep 2011 17:05:58 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 17:02:09 +0200 Received: from [10.193.106.172] ([10.193.106.172]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Sep 2011 17:02:09 +0200 Message-ID: <23050_1316098930_4E721372_23050_105557_1_4E721370.50505@orange-ftgroup.com> Date: Thu, 15 Sep 2011 17:02:08 +0200 From: Organization: France Telecom Orange User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Art Botterell References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Sep 2011 15:02:09.0773 (UTC) FILETIME=[713A61D0:01CC73B8] X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.15.144814 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' SUPERLONG_LINE 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_XOAT 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NS , __USER_AGENT 0' X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.15.114514 Cc: atoca@ietf.org Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:00:01 -0000 Dear all, you may find some information in clause 8 of Recommendation ITU-T X.1303 which you can download from http://www.itu.int/rec/T-REC-X.1303-200709-I/en I am also checking with some ASN.1 experts if they could provide you with some material which would help answering to your questions. -- Olivier DUBUISSON, ITU-T ASN.1 & OID Project leader France Telecom - Orange OLNC/RD/DRS - BP 50702 - 22307 Lannion Cedex - France tel: +33 2 96 05 38 50 On 14/09/2011 16:48, Art Botterell wrote: > Just as a reminder... there's a packed ASN.1 serialization available for CAP as well as the XML format. Not sure how much of a payload size reduction that achieves, but it might be significant. > > Also, it may be useful to distinguish explicitly between the interoperable network-level format (CAP) and various technology-specific presentation-level formats (CMAS text, CAP headline, SAME, siren activation bit, etc.) My experience has been that those two situations sometimes get conflated in discussion, which can cause confusion. > > Usually the conversion from CAP to a presentation format is lossy and therefore essentially a one-way trip, although I suppose it's possible that some presentation schemes might actually involve adding information (e.g., visual styling) from which the full original CAP data could be retrieved later. > > - Art > > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > ******************************************************************************** IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ******************************************************************************** From artbotterell@gmail.com Thu Sep 15 08:01:36 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B5D21F84A3 for ; Thu, 15 Sep 2011 08:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaQvo2KFPW6U for ; Thu, 15 Sep 2011 08:01:36 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF8AC21F84A2 for ; Thu, 15 Sep 2011 08:01:35 -0700 (PDT) Received: by ywa6 with SMTP id 6so2565625ywa.31 for ; Thu, 15 Sep 2011 08:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=vUCSK1NwWV2gx9jKxE+usNbMRyJa3jZLLSne3YP0eYo=; b=do9abmFDeM1k4B1LLk/ji+QCBJIUl/4HpGsbCSKuVHVjvVG6T/ADbdtWqs5uDzP4XW jI+R3zKOYP2FlzQ8LypDwsxLraUPHnyLFt+xUDAhW2WlWyQnmt69KN9VxjIi10hTtAvj 2lb0RrNDePL1Ci/4p8rIoH9V0C87ZtzjkisMI= Received: by 10.42.96.72 with SMTP id i8mr1341229icn.60.1316099027684; Thu, 15 Sep 2011 08:03:47 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id v16sm5162322ibe.0.2011.09.15.08.03.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 08:03:46 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> Date: Thu, 15 Sep 2011 08:03:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:01:36 -0000 Yes, I suspect the requirement for non-fragmented packets may need to be = reconsidered, since it imposes an arbitrary constraint on message = content with no justification other than technological legacy. =20 That's the historic path toward fragmentation and non-interoperability = among warning systems. Once we start to adjust functionality to suit a = particular implementation, every system operator will want to start = optimizing for their particular technology. Plus we then create a = pressure to preserve the limits of current technologies into the future, = which can rapidly become a real obstacle to progress. - Art PS - I'm not sure I totally accept the claim that XMLDSIG isn't = "practically interoperable," at least without some specifics. On Sep 15, 2011, at 7:23 AM, Hannes Tschofenig wrote: >=20 > On Sep 15, 2011, at 10:09 AM, Thomson, Martin wrote: >=20 >> XMLDSIG is not a practically interoperable technology. We might find = that CAP in PER with CMS gives us the best size overall, but that it = doesn't get implemented at all because it sucks to implement. Or even = just because it looks hard. >=20 > I wonder whether there are implementations for the ASN.1 encoding of = CAP.=20 >=20 > You are right that the size considerations are difficult to deal with = since the content of the CAP message is essentially non-restricted. = Switching to JSON will not help with this issue. IP fragmentation will = cause problems with NATs and firewalls, which are unfortunately found in = almost every real network today.=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From keith.drage@alcatel-lucent.com Thu Sep 15 08:29:36 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0683C21F8AFC for ; Thu, 15 Sep 2011 08:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.93 X-Spam-Level: X-Spam-Status: No, score=-105.93 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X13ddwDGJ4hl for ; Thu, 15 Sep 2011 08:29:35 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAED21F8AFF for ; Thu, 15 Sep 2011 08:29:34 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8FFVdSi031667 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Sep 2011 17:31:45 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 15 Sep 2011 17:31:37 +0200 From: "DRAGE, Keith (Keith)" To: Art Botterell , "atoca@ietf.org" Date: Thu, 15 Sep 2011 17:31:37 +0200 Thread-Topic: [atoca] Alert signing Thread-Index: AcxzuK8/Agg4ViLaSwChhvLp5TOEKwAA1fug Message-ID: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> In-Reply-To: <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:29:36 -0000 I would argue that at least short messages does create a constraint on the = initiator to actually draft meaningful messages in a concise imperative for= m rather than finally getting around to the real message in page 5 of a sen= t document. I'd also rather not provide space for each message to be front-ended by leg= al disclaimers saying that the sender accepts no responsibility for the inf= ormation supplied, and is not responsible for any accident or damage accrui= ng on the recipient by acting on this message. Regards Keith > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Art Botterell > Sent: 15 September 2011 16:04 > To: atoca@ietf.org > Subject: Re: [atoca] Alert signing >=20 > Yes, I suspect the requirement for non-fragmented packets may need to be > reconsidered, since it imposes an arbitrary constraint on message content > with no justification other than technological legacy. >=20 > That's the historic path toward fragmentation and non-interoperability > among warning systems. Once we start to adjust functionality to suit a > particular implementation, every system operator will want to start > optimizing for their particular technology. Plus we then create a > pressure to preserve the limits of current technologies into the future, > which can rapidly become a real obstacle to progress. >=20 > - Art >=20 > PS - I'm not sure I totally accept the claim that XMLDSIG isn't > "practically interoperable," at least without some specifics. >=20 >=20 > On Sep 15, 2011, at 7:23 AM, Hannes Tschofenig wrote: >=20 > > > > On Sep 15, 2011, at 10:09 AM, Thomson, Martin wrote: > > > >> XMLDSIG is not a practically interoperable technology. We might find > that CAP in PER with CMS gives us the best size overall, but that it > doesn't get implemented at all because it sucks to implement. Or even > just because it looks hard. > > > > I wonder whether there are implementations for the ASN.1 encoding of > CAP. > > > > You are right that the size considerations are difficult to deal with > since the content of the CAP message is essentially non-restricted. > Switching to JSON will not help with this issue. IP fragmentation will > cause problems with NATs and firewalls, which are unfortunately found in > almost every real network today. > > > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Thu Sep 15 08:49:30 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4521F8B52 for ; Thu, 15 Sep 2011 08:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.542 X-Spam-Level: X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czAL-JactO8p for ; Thu, 15 Sep 2011 08:49:30 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7721F8B51 for ; Thu, 15 Sep 2011 08:49:29 -0700 (PDT) Received: by gxk9 with SMTP id 9so3190902gxk.40 for ; Thu, 15 Sep 2011 08:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=FNFBUisB2N0SDYIBk/n8BKjBn6lZ8V8gsP/r1MD7MZo=; b=MZwHUY8DXdVbqHY1Arr13+rk1eNdjZh6TqnOVsQgDSww2h6ZIMeiHBuY4wRSaLmRl0 z1xHOD6+pndat40hvaivF8xUVRQtezxXt2pN1huK33kjTw1nbkxgfOTfL5Euk8xkTi90 PMLdH0UCzeZI7hGHlomqiKgUDuNJJSNx19z8A= Received: by 10.42.155.66 with SMTP id t2mr385231icw.137.1316101901347; Thu, 15 Sep 2011 08:51:41 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id j2sm5259053ibx.11.2011.09.15.08.51.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 08:51:40 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: Date: Thu, 15 Sep 2011 08:51:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 15:49:30 -0000 On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: > I would argue that at least short messages does create a constraint on = the initiator to actually draft meaningful messages in a concise = imperative form rather than finally getting around to the real message = in page 5 of a sent document. The design of CAP was based on a considerable body of social science = research regarding warning effectiveness. While brevity is generally a = virtue, it turns out that it's possible to make a warning message too = brief, at least if actually eliciting protective action among the = recipients is the goal. In particular, a simple "imperative" message = without context will generally not result in action. (E.g., if I merely = shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? = In which direction? How far? And does this really apply to me?") Encouraging warning originators to write to the point is a worthy goal, = but arguably not something that can be enforced a-priori through = technology. The whole point of CAP was to create an interoperability = layer that was independent of technical constraints, in the awareness = that different delivery mechanisms will impose their own limitations. = (You can think of the CAP message as the Platonic ideal of the warning = message, one which casts different shadows on different walls of the = cave but has an essential nature common to them all.) > I'd also rather not provide space for each message to be front-ended = by legal disclaimers saying that the sender accepts no responsibility = for the information supplied, and is not responsible for any accident or = damage accruing on the recipient by acting on this message. Not sure technology can defeat bureaucracy, but I share your desire. = However, are we really talking about what size message will maximize = warning effectiveness? Sounds to me like our true concern is how to fit = standard messages into the constraints of a pre-existing technology. - Art= From creed@opengeospatial.org Thu Sep 15 09:05:22 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4D21F8B55 for ; Thu, 15 Sep 2011 09:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb+n+9IeueeR for ; Thu, 15 Sep 2011 09:05:22 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id E88B121F8B2D for ; Thu, 15 Sep 2011 09:05:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 6A81D5A21D; Thu, 15 Sep 2011 12:07:33 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMApIfPVsnvl; Thu, 15 Sep 2011 12:07:32 -0400 (EDT) Received: from CarlandSusieOf (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id A5C465A20B; Thu, 15 Sep 2011 11:59:21 -0400 (EDT) Message-ID: From: "Carl Reed" To: "Thomson, Martin" , "Richard L. Barnes" , "Hannes Tschofenig" References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> Date: Thu, 15 Sep 2011 09:45:05 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18416 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18645 Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 16:05:22 -0000 Interesting discussion. I understand the use of CAP in many alerting cases. However, there are many organizations already using SMS. And in Taiwan, there are more and more groups using Open GeoSMS (a new OGC standard) for a variety of alerting applications. Other alerting applications are using GeoRSS. I suspect I missed something in the conversation, like use CAP for authority to authority alerting. Going back to Taiwan, they have a deployed nationwide debris flow monitoring and alerting system. They are using multiple alerting mechanisms to insure all potentially impacted citizens receive alerts: SMS for mobile devices, traditional radio and TV broadcast mechanisms, and so forth. http://www.awareforum.org/2011/03/sensor-web-enablement-application-for-debris-flow-monitoring-system-in-taiwan/ for more information. In Europe, there are major EU framework projects (all related to INSPIRE) that have been completed or are in progress that address various aspects of alerting, risk management, public safety, and emergency services. Sorry, I just want to understand why CAP only. In the OGC community, current efforts have typically abstracted the alert service architecture such that the publish/subscribe function for alerts is independent of the alert format. In this way, CAP, SMS, GeoSMS, GeoRSS, or whatever format is required or desired can be accommodated. Thanks for any clarification! Carl ----- Original Message ----- From: "Thomson, Martin" To: "Richard L. Barnes" ; "Hannes Tschofenig" Cc: Sent: Thursday, September 15, 2011 1:09 AM Subject: [atoca] Alert signing > (moving this topic on-list to include a few more folks) > > (as individual) > > On 2011-09-15 at 13:38:33, Richard L. Barnes wrote: >> > * In slide 8 you talk about the secure alert format. In the Prague >> IETF presentation I spoke about security and there was a big outcry >> about using XML (and XMLDSIG) to protect the CAP message. Since we >> settled with CAP as a format I wonder where we are with this issue. >> The only alternative I see is to switch to JSON and use JSON based >> signing. >> This would deal with our problems, I believe. >> >> I think CMS is also viable, but I don't care that much. I hesitate a >> little to use the WOES/JOSE stuff, only because it's not there yet. > > I understand the reservations about JOSE, but the very fact that JOSE even > exists should tell you something about this. > > I think that the primary considerations are: > > - size > - practicality of implementation > > Smaller size will help us avoid some problems, such as alert > fragmentation. Smaller packets are less likely to cause congestion. But > once beyond some as-yet-undetermined threshold, size becomes a secondary > concern and we have to turn to the other. > > Once any hard limits are deal with, we need to optimize for adoption. > XMLDSIG is not a practically interoperable technology. We might find that > CAP in PER with CMS gives us the best size overall, but that it doesn't > get implemented at all because it sucks to implement. Or even just > because it looks hard. > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > From mark.wood@drcf.net Thu Sep 15 09:37:44 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04CD21F8B67 for ; Thu, 15 Sep 2011 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.832 X-Spam-Level: X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmfP+AhoiM1P for ; Thu, 15 Sep 2011 09:37:44 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF28021F8AFE for ; Thu, 15 Sep 2011 09:37:43 -0700 (PDT) X-Trace: 423495495/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABApck5RVitW/2dsb2JhbABCp1Z5gVoIMhweEgQBBiQ+GgYeAQEEHoduln+lL4EFBJhRh3iEKQ X-IronPort-AV: E=Sophos;i="4.68,388,1312153200"; d="scan'208";a="423495495" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 15 Sep 2011 17:39:52 +0100 From: Sender: "Mark" To: In-Reply-To: <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> Date: Thu, 15 Sep 2011 17:39:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: Acxzv2XBYLcFgNCHRp2O9L38czF5HQAAGsfQ Message-Id: <20110915163743.BF28021F8AFE@ietfa.amsl.com> Subject: [atoca] CAP message sizes. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 16:37:44 -0000 As a 'thought experiment'; e.g. In CellCast's EAGLE front end system, the CAP message is automatically created by the wizard, then 'launched' into the aggregator system for distribution, and may contain quite a lot of information that will not be used in the final distribution to the citizen. For example; a JPG picture of a missing child or a map of the shelter locations could be shown on plasma screens at gas stations but not on mobiles, while voice clips are routed to speakers and 'dial down' banks. The initial verbose version is however, required because the originating sender does not always control how many distribution methods will be used and where. In addition, the rate of progress in personal communications is so fast that new capabilities are emerging all the time, and what once seemed impractical is now 'a given'. It would be a burden to expect the Sheriff to remember all the new tech. EAGLE (for one example) assumes that the sender does not have time to make multiple manual entries into the UI, so it tries to get it all in one CAP (but obviously a sender can add as he goes). So the original proposal may be quite verbose with a lot of links to other resources or multimedia of its own embedded in the CAP message, intended for a wide variety of distribution systems. The Alert Gateway(s) (AGW) is driven by the local trust protocol, in which local decision makers (including the networks) have decided who can transmit what and where and how. So AGW determines if a particular proposal will be transmitted by a specific "instance of participating network", and therefore what degree of filtering will be applied before it becomes a 'submission' to that "specific instance of participating network" in accord with the trust protocol agreement with network operating authority (e.g. AT&T or a campus enterprise network). [I think that in the CMAS model the network does this at its 'gateway' unit, maybe Brian can explain that]. For example, an emergency manager may create a quite elaborate message on the front end, containing images or even script for apps, which is then packaged by front end in CAP and then parsed and trafficked to other AGWs. A phone company may have concurrent 2G, 3G and 4G networks covering the same area, so need different versions of the same message trafficked to each (This is why each 'system technology' is treated as a different "participating network" even if it is owned by the same company). For example, it may be possible to 'cell broadcast' the image of the missing child in 4G, but not in 2G. If one of the participating networks is a second generation cell broadcast system, for example, then bearer incapable parts will be stripped off except for the polygon and the text (and some other control info such as the channel number) before sending on to the CBC of the network. So, some CAP messages will be quite verbose at some early stages, more than one UPD packet, while others will be sparse, depending on where in the chain they are. I suspect that something like Google Alert Hub will probably take the whole CAP packet (minus security sensitive bits that the AGW strips off) and then let subscribers filter what they want. This implies best effort push technology, of course! IMHO I think this means that a CAP message may indeed be bigger than one UDP packet. Any comments/clarifications? Mark From keith.drage@alcatel-lucent.com Thu Sep 15 09:38:20 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4021F8B46 for ; Thu, 15 Sep 2011 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.936 X-Spam-Level: X-Spam-Status: No, score=-105.936 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+4e8HQvwAwr for ; Thu, 15 Sep 2011 09:38:19 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1A33521F8B31 for ; Thu, 15 Sep 2011 09:38:18 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8FGeTW1009571 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Sep 2011 18:40:30 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 15 Sep 2011 18:40:29 +0200 From: "DRAGE, Keith (Keith)" To: Art Botterell , "atoca@ietf.org" Date: Thu, 15 Sep 2011 18:40:27 +0200 Thread-Topic: [atoca] Alert signing Thread-Index: Acxzv2f9RdopWrXsQ56/vCQVcanMCgAAyLow Message-ID: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> In-Reply-To: <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 16:38:20 -0000 See below > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Art Botterell > Sent: 15 September 2011 16:52 > To: atoca@ietf.org > Subject: Re: [atoca] Alert signing >=20 > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: >=20 > > I would argue that at least short messages does create a constraint on > the initiator to actually draft meaningful messages in a concise > imperative form rather than finally getting around to the real message in > page 5 of a sent document. >=20 > The design of CAP was based on a considerable body of social science > research regarding warning effectiveness. While brevity is generally a > virtue, it turns out that it's possible to make a warning message too > brief, at least if actually eliciting protective action among the > recipients is the goal. In particular, a simple "imperative" message > without context will generally not result in action. (E.g., if I merely > shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? > In which direction? How far? And does this really apply to me?") >=20 Agreed.=20 Did the research come up with any input as to what was enough, before peopl= e ignored it. People are talking about fragmentation, which doesn't even be= come an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast= survives on the order of a hundred bytes.=20 At what point do these discussions become irrelevant because the messages s= hould be shorter than that. Keith > Encouraging warning originators to write to the point is a worthy goal, > but arguably not something that can be enforced a-priori through > technology. The whole point of CAP was to create an interoperability > layer that was independent of technical constraints, in the awareness tha= t > different delivery mechanisms will impose their own limitations. (You ca= n > think of the CAP message as the Platonic ideal of the warning message, on= e > which casts different shadows on different walls of the cave but has an > essential nature common to them all.) >=20 > > I'd also rather not provide space for each message to be front-ended by > legal disclaimers saying that the sender accepts no responsibility for th= e > information supplied, and is not responsible for any accident or damage > accruing on the recipient by acting on this message. >=20 > Not sure technology can defeat bureaucracy, but I share your desire. > However, are we really talking about what size message will maximize > warning effectiveness? Sounds to me like our true concern is how to fit > standard messages into the constraints of a pre-existing technology. >=20 > - Art > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Thu Sep 15 09:52:29 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB2721F8B8C for ; Thu, 15 Sep 2011 09:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXihWVMwcXwY for ; Thu, 15 Sep 2011 09:52:29 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5246321F8B51 for ; Thu, 15 Sep 2011 09:52:29 -0700 (PDT) Received: by gxk9 with SMTP id 9so3267765gxk.40 for ; Thu, 15 Sep 2011 09:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=r00JkHFKbGlZFePQD6IIjKvUfJAQ3PstpSMBTT5c+i0=; b=feOyDtZOiiKGBXBf5Q1IlTUJTZ2UrjY8EQG56v7w8mALWGOt9tGFzvZQAI69vP8RFr I5J00PIK3bWMLDgg5RWCv6F4w3MRhMafHyjtjQXcifDQShulzHmuJdlKmYK9Qszwd79m +yYLrbEHUGwC85k6QtmpmB3Hp47q4XR/SboFs= Received: by 10.42.162.74 with SMTP id w10mr471132icx.163.1316105681226; Thu, 15 Sep 2011 09:54:41 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id gs23sm5495901ibb.1.2011.09.15.09.54.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 09:54:40 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: Date: Thu, 15 Sep 2011 09:54:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 16:52:30 -0000 On Sep 15, 2011, at 9:40 AM, DRAGE, Keith (Keith) wrote: > Did the research come up with any input as to what was enough, before = people ignored it.=20 No, I'm not sure there's any strong indication that people have a = maximum message size as such. What matters most are, a) establishing = personal relevance to the recipient, b) providing actionable = protective-action recommendations, and c) repetition and corroboration = via multiple channels (which is why we need a channel-independent = meta-standard like CAP.) The social scientists don't count bytes, of course... their results have = mainly to do with what essential items of content were present. Those = elements can be expressed at different lengths depending on both level = of detail and writer style. In practice the uncompressed XML of a CAP message is typically in the = range of 0.5 to about 3 KB. "Attachments" in the resource elements... = images and such... can of course, be much larger, but the preferred = practice is to provide a URL for as-needed retrieval of resources rather = than encoding them in-line. - Art= From rbarnes@bbn.com Thu Sep 15 12:17:39 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889C421F8BE7 for ; Thu, 15 Sep 2011 12:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.563 X-Spam-Level: X-Spam-Status: No, score=-106.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzJmkMQ-Kb92 for ; Thu, 15 Sep 2011 12:17:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F169D21F8BE5 for ; Thu, 15 Sep 2011 12:17:38 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:56235) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R4HTS-0005QS-1F; Thu, 15 Sep 2011 15:19:50 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> Date: Thu, 15 Sep 2011 15:19:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1084) Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 19:17:39 -0000 Yeah, I think that all this really argues for is having a fragmentation = layer over UDP, plus maybe using GZIPped CAP. --Richard On Sep 15, 2011, at 11:03 AM, Art Botterell wrote: > Yes, I suspect the requirement for non-fragmented packets may need to = be reconsidered, since it imposes an arbitrary constraint on message = content with no justification other than technological legacy. =20 >=20 > That's the historic path toward fragmentation and non-interoperability = among warning systems. Once we start to adjust functionality to suit a = particular implementation, every system operator will want to start = optimizing for their particular technology. Plus we then create a = pressure to preserve the limits of current technologies into the future, = which can rapidly become a real obstacle to progress. >=20 > - Art >=20 > PS - I'm not sure I totally accept the claim that XMLDSIG isn't = "practically interoperable," at least without some specifics. >=20 >=20 > On Sep 15, 2011, at 7:23 AM, Hannes Tschofenig wrote: >=20 >>=20 >> On Sep 15, 2011, at 10:09 AM, Thomson, Martin wrote: >>=20 >>> XMLDSIG is not a practically interoperable technology. We might = find that CAP in PER with CMS gives us the best size overall, but that = it doesn't get implemented at all because it sucks to implement. Or = even just because it looks hard. >>=20 >> I wonder whether there are implementations for the ASN.1 encoding of = CAP.=20 >>=20 >> You are right that the size considerations are difficult to deal with = since the content of the CAP message is essentially non-restricted. = Switching to JSON will not help with this issue. IP fragmentation will = cause problems with NATs and firewalls, which are unfortunately found in = almost every real network today.=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From Martin.Thomson@commscope.com Thu Sep 15 16:13:26 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E1021F85F2 for ; Thu, 15 Sep 2011 16:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTlUtO+kr5L5 for ; Thu, 15 Sep 2011 16:13:26 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 66C1421F85AE for ; Thu, 15 Sep 2011 16:13:26 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-18-4e7287174264 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 68.74.19263.717827E4; Thu, 15 Sep 2011 18:15:35 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 15 Sep 2011 18:15:35 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 15 Sep 2011 18:15:34 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 16 Sep 2011 07:15:30 +0800 From: "Thomson, Martin" To: Art Botterell , "trutkowski@netmagic.com" , Eliot Christian Date: Fri, 16 Sep 2011 07:15:28 +0800 Thread-Topic: [atoca] Broadcast Reqs Thread-Index: AcxztpssfYZ01U6oSFqeOoFr09rBJwAROvug Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094D8@SISPE7MB1.commscope.com> References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> <4E71B670.1080104@netmagic.com> <37F0CFF6-8D6A-4381-96A1-A2D1779FEAB1@incident.com> In-Reply-To: <37F0CFF6-8D6A-4381-96A1-A2D1779FEAB1@incident.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "atoca@ietf.org" Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 23:13:27 -0000 On 2011-09-16 at 00:48:52, Art Botterell wrote: > Yes, I'm thinking that a lot of the issue here is that the ASN.1=20 > serialization "looks hard". It's difficult to underestimate how powerful an effect "looks hard" actuall= y is. ASN.1 + DER as used in CMS isn't actually all that hard to implement= when you get down to it, but in practice very few people get past the init= ial shock to the point of producing a real implementation. ASN.1 + PER is = hard. Good libraries do help in this, but they aren't a perfect solution. Out of interest, has anyone looked at CAP compression instead? There's bee= n a lot of work recently in the web world in optimizing compression for use= there and that can be very highly effective. --Martin From Martin.Thomson@commscope.com Thu Sep 15 16:27:23 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172E21F85AE for ; Thu, 15 Sep 2011 16:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrjZqIXsQw9K for ; Thu, 15 Sep 2011 16:27:22 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 996E421F84B4 for ; Thu, 15 Sep 2011 16:27:16 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-0f-4e728a5972a1 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 86.A4.19263.95A827E4; Thu, 15 Sep 2011 18:29:29 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 15 Sep 2011 18:29:29 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 16 Sep 2011 07:29:25 +0800 From: "Thomson, Martin" To: Hannes Tschofenig Date: Fri, 16 Sep 2011 07:29:24 +0800 Thread-Topic: Alert signing Thread-Index: AcxzswTRL0lrGFmrSlG6bdJvMDn3LAAR23WQ Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094D9@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> In-Reply-To: <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "atoca@ietf.org" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 23:27:23 -0000 On 2011-09-16 at 00:23:14, Hannes Tschofenig wrote: > You are right that the size considerations are difficult to deal with=20 > since the content of the CAP message is essentially non-restricted. > Switching to JSON will not help with this issue. IP fragmentation will=20 > cause problems with NATs and firewalls, which are unfortunately found=20 > in almost every real network today. It's quite possible that there is nothing we can do about this, and that it= will always be in the hands of those who generate the alerts. What we can= do is identify how much space will be left for the real content after all = the packaging and signing is added. Maximizing the space for content will be a goal, with all the accompanying = trade-offs. --Martin From Martin.Thomson@commscope.com Thu Sep 15 16:35:29 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF5411E8080 for ; Thu, 15 Sep 2011 16:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaD774S6NwwM for ; Thu, 15 Sep 2011 16:35:28 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 89E4811E807F for ; Thu, 15 Sep 2011 16:35:28 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-9b-4e728c45d206 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id F1.30.08855.54C827E4; Thu, 15 Sep 2011 18:37:41 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 15 Sep 2011 18:37:41 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 16 Sep 2011 07:37:30 +0800 From: "Thomson, Martin" To: Carl Reed , "Richard L. Barnes" , Hannes Tschofenig Date: Fri, 16 Sep 2011 07:37:28 +0800 Thread-Topic: [atoca] Alert signing Thread-Index: AcxzwZZjcnf9YubHQOCpW//O49hqnAAPk8OA Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "atoca@ietf.org" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 23:35:29 -0000 On 2011-09-16 at 01:45:05, Carl Reed wrote: > Sorry, I just want to understand why CAP only. In the OGC community,=20 > current efforts have typically abstracted the alert service=20 > architecture such that the publish/subscribe function for alerts is=20 > independent of the alert format. In this way, CAP, SMS, GeoSMS,=20 > GeoRSS, or whatever format is required or desired can be accommodated. CAP serves a useful purpose as the canonical or lowest-common-denominator f= orm. That shouldn't preclude other representations for domains where anoth= er form is better suited. For instance, cell broadcast doesn't convey CAP; it uses a different repres= entation of information that might have originated as a CAP message. --Martin From artbotterell@gmail.com Thu Sep 15 16:46:39 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C47121F8488 for ; Thu, 15 Sep 2011 16:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRlOoa67-TTa for ; Thu, 15 Sep 2011 16:46:38 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E44321F8487 for ; Thu, 15 Sep 2011 16:46:38 -0700 (PDT) Received: by ywa6 with SMTP id 6so2983852ywa.31 for ; Thu, 15 Sep 2011 16:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=X6pRhVNwCr+QzMSLUi7oD2ev8haxIZK96/QLi2PAjKw=; b=m3qtIu3HvjcleHXQdXb+WmAwbaOrThx/pp4Y6pGhnqalk/RL9oLYn4llbFGK+2ii1R tCD8XNXnyoZq82AAK2Agj0jfu1XNp5i8VETzKgWiO9FsFZ0gybcAXxr4mkD48aAcx/CJ YjnD1cGQzpUiyZ7jKJAIAB7vYLA+fYTdUetbM= Received: by 10.68.64.196 with SMTP id q4mr632972pbs.135.1316130531198; Thu, 15 Sep 2011 16:48:51 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id i8sm5926328pbl.2.2011.09.15.16.48.48 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 16:48:49 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094D8@SISPE7MB1.commscope.com> Date: Thu, 15 Sep 2011 16:48:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44E38D96-89DB-4EE5-A9A7-C135A2841AB9@incident.com> References: <20110914142947.E28D821F8CBB@ietfa.amsl.com> <4E71B670.1080104@netmagic.com> <37F0CFF6-8D6A-4381-96A1-A2D1779FEAB1@incident.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094D8@SISPE7MB1.commscope.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 23:46:39 -0000 On Sep 15, 2011, at 4:15 PM, Thomson, Martin wrote: > It's difficult to underestimate how powerful an effect "looks hard" = actually is. ASN.1 + DER as used in CMS isn't actually all that hard to = implement when you get down to it, but in practice very few people get = past the initial shock to the point of producing a real implementation. = ASN.1 + PER is hard. Of course CAP geospatial geometries looked hard at first too, at least = to non-GIS folks. But if the benefits are sufficient, it's amazing what = programmers can learn how to do. > Good libraries do help in this, but they aren't a perfect solution. Then again, is there ever such a thing as a perfect solution? ;-) > Out of interest, has anyone looked at CAP compression instead? =20 Some web servers will already compress content by default if both ends = support it, so I suppose that could be made a requirement for a = specified transport layer. Again, CAP is really a data-structure = specification more than an XML or an ASN.1 thing per-se. Still, = serialization standards are necessary at the transport level to maximize = interoperability, so I'd think there'd be some preference for existing = standards where possible. - Art From artbotterell@gmail.com Thu Sep 15 16:54:40 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34A21F0C3C for ; Thu, 15 Sep 2011 16:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3saZmyGq3VW7 for ; Thu, 15 Sep 2011 16:54:40 -0700 (PDT) Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD201F0C3B for ; Thu, 15 Sep 2011 16:54:40 -0700 (PDT) Received: by gwb17 with SMTP id 17so3694214gwb.15 for ; Thu, 15 Sep 2011 16:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=6qvkN5zL0r83y7ufe9qL4gCcCtZ8VRLucdUVpFT0NA0=; b=JnG5L9C658bTSuq4IH0Wqepz//0SKbS6cHF19xKPCt5bUTpGL4T1iFL43mxQQd93pA fyVD7sdmdT/5KA9Sp7bkEWL16QGsFKmFrXXOoyuRdz07nOhFwwsKF1NLqL273NeTdeh0 2MhOw+L3+FEoO9l5AY1S8EKMHMiTqS56zCsAg= Received: by 10.68.33.197 with SMTP id t5mr1358302pbi.110.1316131012829; Thu, 15 Sep 2011 16:56:52 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id 4sm27468162pbk.5.2011.09.15.16.56.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 16:56:51 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> Date: Thu, 15 Sep 2011 16:56:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 23:54:40 -0000 On Sep 15, 2011, at 4:37 PM, Thomson, Martin wrote: > For instance, cell broadcast doesn't convey CAP; it uses a different = representation of information that might have originated as a CAP = message. This is what I meant earlier about the distinction between = technology-specific delivery formats and the technology-agnostic = interoperability format. Once we down-convert from the general standard = to some transport-specific representation it's rarely possible to = recover all the original information; thus it's generally wisest to = defer such translation until the last mile, if only to keep our = interoperability options open for the future. Personally I like to think of CAP as a higher level of abstraction = rather than a lesser denominator... since the content of a CAP alert is = almost always richer than that of derived products... but that's = probably just pride of authorship speaking. ;-) - Art From bd2985@att.com Thu Sep 15 18:08:26 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7075221F846B for ; Thu, 15 Sep 2011 18:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsGaLgvgnJjo for ; Thu, 15 Sep 2011 18:08:25 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id D6EBA21F8464 for ; Thu, 15 Sep 2011 18:08:25 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1316135437!38454187!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29448 invoked from network); 16 Sep 2011 01:10:37 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 01:10:37 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G1AbTq032196; Thu, 15 Sep 2011 20:10:37 -0500 Received: from WABOTH9MSGHUB8A.ITServices.sbc.com (waboth9msghub8a.itservices.sbc.com [135.163.35.61]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G1AVLo032165; Thu, 15 Sep 2011 20:10:32 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8A.ITServices.sbc.com ([135.163.35.61]) with mapi id 14.01.0289.001; Thu, 15 Sep 2011 18:10:31 -0700 From: "DALY, BRIAN K" To: "Thomson, Martin" , Carl Reed , "Richard L. Barnes" , Hannes Tschofenig Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc75wPl9Z5lcp/kmE0Yrq8zh6zpVPjrcA//+kMsA= Date: Fri, 16 Sep 2011 01:10:30 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F962368C9@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "atoca@ietf.org" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 01:08:26 -0000 " it uses a different representation of information that might have origina= ted as a CAP message." For CMAS the original alert message was originated as a CAP message, and th= e Federal Alert Gateway (within the iPAWS architecture) renders the informa= tion into a format suitable for CMAS. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of T= homson, Martin Sent: Thursday, September 15, 2011 4:37 PM To: Carl Reed; Richard L. Barnes; Hannes Tschofenig Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing On 2011-09-16 at 01:45:05, Carl Reed wrote: > Sorry, I just want to understand why CAP only. In the OGC community,=20 > current efforts have typically abstracted the alert service=20 > architecture such that the publish/subscribe function for alerts is=20 > independent of the alert format. In this way, CAP, SMS, GeoSMS,=20 > GeoRSS, or whatever format is required or desired can be accommodated. CAP serves a useful purpose as the canonical or lowest-common-denominator f= orm. That shouldn't preclude other representations for domains where anoth= er form is better suited. For instance, cell broadcast doesn't convey CAP; it uses a different repres= entation of information that might have originated as a CAP message. --Martin _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From bd2985@att.com Thu Sep 15 18:23:39 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EED11E809F for ; Thu, 15 Sep 2011 18:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeLPPtAmCeo7 for ; Thu, 15 Sep 2011 18:23:38 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9BF11E808D for ; Thu, 15 Sep 2011 18:23:38 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1316136349!39454793!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23918 invoked from network); 16 Sep 2011 01:25:49 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-8.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 01:25:49 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G1PnId005409; Thu, 15 Sep 2011 20:25:49 -0500 Received: from WABOTH9MSGHUB8F.ITServices.sbc.com (waboth9msghub8f.itservices.sbc.com [135.163.35.68]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G1PiS2005381; Thu, 15 Sep 2011 20:25:44 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8F.ITServices.sbc.com ([135.163.35.68]) with mapi id 14.01.0289.001; Thu, 15 Sep 2011 18:25:43 -0700 From: "DALY, BRIAN K" To: "DRAGE, Keith (Keith)" , Art Botterell , "atoca@ietf.org" Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc7MNPl9Z5lcp/kmE0Yrq8zh6zpVO/0aAgAAHyYCAAAWZgIAADaOAgAAbFXA= Date: Fri, 16 Sep 2011 01:25:43 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 01:23:39 -0000 " Did the research come up with any input as to what was enough, before peo= ple ignored it. People are talking about fragmentation, which doesn't even = become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadca= st survives on the order of a hundred bytes." Actually the FCC's Commercial Mobile System Alert Advisory Committee spend = considerable time looking at the issue of "how long should a message be" es= pecially when rendered on a mobile device screen AND accounted for the need= s of individuals with disabilities. Bottom line - people don't want to have to scroll through multiple screens = to read information - they want to be told "to the point" with a minimal am= ount of scrolling through pages of text. The input obtained from that study is one of the drivers that limited a CMA= S alert message to 90 characters (although there was technical consideratio= n as well), PLUS there was research that stated to be most effective the al= ert message needs to contain the following information, in this order: 1. What's happening (e.g. Tornado Warning) 2. Where it is happening (e.g. "in your/this area") 3. What action to take (e.g., "take shelter now") 4. How long it will be happening (e.g. "until 7pm") 5. Who authorized this/sent this (e.g., "NWS") -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of D= RAGE, Keith (Keith) Sent: Thursday, September 15, 2011 9:40 AM To: Art Botterell; atoca@ietf.org Subject: Re: [atoca] Alert signing See below > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Art Botterell > Sent: 15 September 2011 16:52 > To: atoca@ietf.org > Subject: Re: [atoca] Alert signing >=20 > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: >=20 > > I would argue that at least short messages does create a constraint on > the initiator to actually draft meaningful messages in a concise > imperative form rather than finally getting around to the real message in > page 5 of a sent document. >=20 > The design of CAP was based on a considerable body of social science > research regarding warning effectiveness. While brevity is generally a > virtue, it turns out that it's possible to make a warning message too > brief, at least if actually eliciting protective action among the > recipients is the goal. In particular, a simple "imperative" message > without context will generally not result in action. (E.g., if I merely > shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? > In which direction? How far? And does this really apply to me?") >=20 Agreed.=20 Did the research come up with any input as to what was enough, before peopl= e ignored it. People are talking about fragmentation, which doesn't even be= come an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast= survives on the order of a hundred bytes.=20 At what point do these discussions become irrelevant because the messages s= hould be shorter than that. Keith > Encouraging warning originators to write to the point is a worthy goal, > but arguably not something that can be enforced a-priori through > technology. The whole point of CAP was to create an interoperability > layer that was independent of technical constraints, in the awareness tha= t > different delivery mechanisms will impose their own limitations. (You ca= n > think of the CAP message as the Platonic ideal of the warning message, on= e > which casts different shadows on different walls of the cave but has an > essential nature common to them all.) >=20 > > I'd also rather not provide space for each message to be front-ended by > legal disclaimers saying that the sender accepts no responsibility for th= e > information supplied, and is not responsible for any accident or damage > accruing on the recipient by acting on this message. >=20 > Not sure technology can defeat bureaucracy, but I share your desire. > However, are we really talking about what size message will maximize > warning effectiveness? Sounds to me like our true concern is how to fit > standard messages into the constraints of a pre-existing technology. >=20 > - Art > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From bd2985@att.com Thu Sep 15 18:32:53 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0611E80A2 for ; Thu, 15 Sep 2011 18:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hm3m9B9lD5nb for ; Thu, 15 Sep 2011 18:32:53 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3B11E808D for ; Thu, 15 Sep 2011 18:32:52 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1316136905!39459955!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31207 invoked from network); 16 Sep 2011 01:35:05 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-4.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 01:35:05 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G1Z5pQ009224; Thu, 15 Sep 2011 20:35:05 -0500 Received: from WABOTH9MSGHUB8D.ITServices.sbc.com (waboth9msghub8d.itservices.sbc.com [135.163.35.93]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G1Z2Tk009210; Thu, 15 Sep 2011 20:35:02 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8D.ITServices.sbc.com ([135.163.35.93]) with mapi id 14.01.0289.001; Thu, 15 Sep 2011 18:35:02 -0700 From: "DALY, BRIAN K" To: Art Botterell , "atoca@ietf.org" Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc7MNPl9Z5lcp/kmE0Yrq8zh6zpVO/0aAgAAHyYCAAAWZgIAALLow Date: Fri, 16 Sep 2011 01:35:01 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F962369DF@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> In-Reply-To: <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 01:32:53 -0000 " The design of CAP was based on a considerable body of social science rese= arch regarding warning effectiveness. " But I am not sure that social science research accounted for mobile devices= /device screens/etc. This is where I think the CMSAAC research came into pl= ay. I will be interested in seeing what happens when CMAS is deployed widely an= d we have some real life experience to analyze - especially on the use case= where everyone on a at rush hou= r gets an alert at the same time to "take cover now". -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of A= rt Botterell Sent: Thursday, September 15, 2011 8:52 AM To: atoca@ietf.org Subject: Re: [atoca] Alert signing On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: > I would argue that at least short messages does create a constraint on th= e initiator to actually draft meaningful messages in a concise imperative f= orm rather than finally getting around to the real message in page 5 of a s= ent document. The design of CAP was based on a considerable body of social science resear= ch regarding warning effectiveness. While brevity is generally a virtue, i= t turns out that it's possible to make a warning message too brief, at leas= t if actually eliciting protective action among the recipients is the goal.= In particular, a simple "imperative" message without context will general= ly not result in action. (E.g., if I merely shouted "RUN, NOW!" would you = run immediately, or would you ask me "Why? In which direction? How far? An= d does this really apply to me?") Encouraging warning originators to write to the point is a worthy goal, but= arguably not something that can be enforced a-priori through technology. = The whole point of CAP was to create an interoperability layer that was ind= ependent of technical constraints, in the awareness that different delivery= mechanisms will impose their own limitations. (You can think of the CAP m= essage as the Platonic ideal of the warning message, one which casts differ= ent shadows on different walls of the cave but has an essential nature comm= on to them all.) > I'd also rather not provide space for each message to be front-ended by l= egal disclaimers saying that the sender accepts no responsibility for the i= nformation supplied, and is not responsible for any accident or damage accr= uing on the recipient by acting on this message. Not sure technology can defeat bureaucracy, but I share your desire. Howev= er, are we really talking about what size message will maximize warning eff= ectiveness? Sounds to me like our true concern is how to fit standard mess= ages into the constraints of a pre-existing technology. - Art _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From artbotterell@gmail.com Thu Sep 15 19:30:47 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FA211E80B2 for ; Thu, 15 Sep 2011 19:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xckYhZVFltp for ; Thu, 15 Sep 2011 19:30:46 -0700 (PDT) Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7A71611E8086 for ; Thu, 15 Sep 2011 19:30:46 -0700 (PDT) Received: by gxk9 with SMTP id 9so3737511gxk.40 for ; Thu, 15 Sep 2011 19:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=3VScc+vZu1o3sihZ9vL+Jr+6IqdReznHALQUfGKgoAE=; b=X3AuIfz0zYeflH/T4HWWmm/8aBrVmFzXlJ5fXF5yNVWM+xFr4Hhh9111IXfidHu3Kv x22MfnkE87rinvJfmvzb9iKEZ7htiIQjcj27oB76Wdwn+yyj/ojuG7krmuPH4ZxY3Jp3 FwpMRdWh4JAxvJj/xgiJEjiPUOsFeiIX0hsQg= Received: by 10.150.32.4 with SMTP id f4mr1891949ybf.204.1316140379789; Thu, 15 Sep 2011 19:32:59 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net [99.182.125.96]) by mx.google.com with ESMTPS id f20sm19802823anf.23.2011.09.15.19.32.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Sep 2011 19:32:58 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <95C5C7A891135E4685CCFAE997351F962369DF@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Thu, 15 Sep 2011 19:32:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369DF@WABOTH9MSGUSR8B.ITServices.sbc.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 02:30:47 -0000 On Sep 15, 2011, at 6:35 PM, DALY, BRIAN K wrote: > " The design of CAP was based on a considerable body of social science = research regarding warning effectiveness. " >=20 > But I am not sure that social science research accounted for mobile = devices/device screens/etc. This is where I think the CMSAAC research = came into play. Not sure to what extent mobile devices and other small screens have = changed human psychology and sociology; evolution doesn't generally work = all that fast. As I mentioned before, the science hasn't generally been = cast in terms of bytes or pixels. But if there's research out there = that suggests the 90 character CMAS limit (in English, that is, = potentially less in some other languages) is anywhere near optimal from = a warning effectiveness perspective, I'd love to see a citation. As you know, Brian, I was one of the first and strongest advocates on = the CMSAAC for the automatic construction of a concise string from the = CAP enumerated values as a way to accommodate the technical 90-character = constraint. There were folks who wanted the originating officials to = construct the 90-character string "freehand," but I was concerned that = they didn't appreciate how difficult it can be to write a good = headline-sized message, especially under stress and time pressure... and = also that it would force time-pressed alert originators to duplicate = work by having to write multiple versions of the same message, which was = another of the things CAP was invented to avoid. I should also point out that CMAS isn't the first or even the worst = instance of this problem. Variable message signs on freeways and in = transit stations tend to permit even fewer characters and are even more = challenging if we want not to wrap words around line breaks . But my real point is that we should be intellectually honest about this. = We each may have personal opinions about message length, and in any = event each delivery medium will impose its own constraints one way or = another... but what's really at the heart of this conversation are = technological constraints and to what extend we should let them wag the = messaging dog. Fortunately, using CAP on the backbone allows us to = compartmentalize such constraints so they don't metastasize beyond their = own technical and temporal context. > I will be interested in seeing what happens when CMAS is deployed = widely and we have some real life experience to analyze - especially on = the use case where everyone on a at rush hour gets an alert at the same time to "take cover = now". Yes, that's a potential problem, and the best way I know of to mitigate = it is to target alert delivery as precisely as possible to the folks = actually at risk. This is another area where the technical limitations = of particular delivery systems sometimes get confused with best warning = practice. - Art= From creed@opengeospatial.org Thu Sep 15 19:35:27 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBBB11E80AF for ; Thu, 15 Sep 2011 19:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfH7W8vlh9IN for ; Thu, 15 Sep 2011 19:35:27 -0700 (PDT) Received: from mail.opengeospatial.org (scale.ogcinc.net [66.244.86.102]) by ietfa.amsl.com (Postfix) with ESMTP id 862DE11E8086 for ; Thu, 15 Sep 2011 19:35:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.opengeospatial.org (Postfix) with ESMTP id 7487C5A242; Thu, 15 Sep 2011 22:37:40 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mail.ogcinc.net Received: from mail.opengeospatial.org ([127.0.0.1]) by localhost (mail.opengeospatial.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMX9mgiMu7C1; Thu, 15 Sep 2011 22:37:40 -0400 (EDT) Received: from CarlandSusieOf (c-98-245-174-99.hsd1.co.comcast.net [98.245.174.99]) by mail.opengeospatial.org (Postfix) with ESMTPSA id BD2315A220; Thu, 15 Sep 2011 22:37:39 -0400 (EDT) Message-ID: <24A07AFD3937440698E103DC61613B90@CarlandSusieOf> From: "Carl Reed" To: "Thomson, Martin" , "Richard L. Barnes" , "Hannes Tschofenig" References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> Date: Thu, 15 Sep 2011 20:37:49 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18416 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18645 Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 02:35:28 -0000 Martin - Thanks for the feedback. Regards Carl ----- Original Message ----- From: "Thomson, Martin" To: "Carl Reed" ; "Richard L. Barnes" ; "Hannes Tschofenig" Cc: Sent: Thursday, September 15, 2011 5:37 PM Subject: RE: [atoca] Alert signing On 2011-09-16 at 01:45:05, Carl Reed wrote: > Sorry, I just want to understand why CAP only. In the OGC community, > current efforts have typically abstracted the alert service > architecture such that the publish/subscribe function for alerts is > independent of the alert format. In this way, CAP, SMS, GeoSMS, > GeoRSS, or whatever format is required or desired can be accommodated. CAP serves a useful purpose as the canonical or lowest-common-denominator form. That shouldn't preclude other representations for domains where another form is better suited. For instance, cell broadcast doesn't convey CAP; it uses a different representation of information that might have originated as a CAP message. --Martin From bd2985@att.com Thu Sep 15 19:38:00 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C75111E80B1 for ; Thu, 15 Sep 2011 19:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Uov5ydUZb0Z for ; Thu, 15 Sep 2011 19:38:00 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B82DE11E80B0 for ; Thu, 15 Sep 2011 19:37:59 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1316140811!37267541!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27395 invoked from network); 16 Sep 2011 02:40:11 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 02:40:11 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G2eBBK006216; Thu, 15 Sep 2011 21:40:11 -0500 Received: from WABOTH9MSGHUB8E.ITServices.sbc.com (waboth9msghub8e.itservices.sbc.com [135.163.35.85]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8G2e6kw006169; Thu, 15 Sep 2011 21:40:06 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8E.ITServices.sbc.com ([135.163.35.85]) with mapi id 14.01.0289.001; Thu, 15 Sep 2011 19:40:06 -0700 From: "DALY, BRIAN K" To: Art Botterell , "atoca@ietf.org" Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc7MNPl9Z5lcp/kmE0Yrq8zh6zpVO/0aAgAAHyYCAAAWZgIAALLowgACGcgD//4vygA== Date: Fri, 16 Sep 2011 02:40:05 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F96236CC7@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369DF@WABOTH9MSGUSR8B.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 02:38:00 -0000 " Not sure to what extent mobile devices and other small screens have chang= ed human psychology and sociology; evolution doesn't generally work all tha= t fast" Oh but I think it has ... especially with text and social networking. Every= thing from new "languages" to reliance on their social networks for "inform= ation" to the lack of social skills needed for verbal communication.... But that is a discussion for another time :-) -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of A= rt Botterell Sent: Thursday, September 15, 2011 7:33 PM To: atoca@ietf.org Subject: Re: [atoca] Alert signing On Sep 15, 2011, at 6:35 PM, DALY, BRIAN K wrote: > " The design of CAP was based on a considerable body of social science re= search regarding warning effectiveness. " >=20 > But I am not sure that social science research accounted for mobile devic= es/device screens/etc. This is where I think the CMSAAC research came into = play. Not sure to what extent mobile devices and other small screens have changed= human psychology and sociology; evolution doesn't generally work all that = fast. As I mentioned before, the science hasn't generally been cast in ter= ms of bytes or pixels. But if there's research out there that suggests the= 90 character CMAS limit (in English, that is, potentially less in some oth= er languages) is anywhere near optimal from a warning effectiveness perspec= tive, I'd love to see a citation. As you know, Brian, I was one of the first and strongest advocates on the C= MSAAC for the automatic construction of a concise string from the CAP enume= rated values as a way to accommodate the technical 90-character constraint.= There were folks who wanted the originating officials to construct the 90= -character string "freehand," but I was concerned that they didn't apprecia= te how difficult it can be to write a good headline-sized message, especial= ly under stress and time pressure... and also that it would force time-pres= sed alert originators to duplicate work by having to write multiple version= s of the same message, which was another of the things CAP was invented to = avoid. I should also point out that CMAS isn't the first or even the worst instanc= e of this problem. Variable message signs on freeways and in transit stati= ons tend to permit even fewer characters and are even more challenging if w= e want not to wrap words around line breaks . But my real point is that we should be intellectually honest about this. W= e each may have personal opinions about message length, and in any event ea= ch delivery medium will impose its own constraints one way or another... bu= t what's really at the heart of this conversation are technological constra= ints and to what extend we should let them wag the messaging dog. Fortunat= ely, using CAP on the backbone allows us to compartmentalize such constrain= ts so they don't metastasize beyond their own technical and temporal contex= t. > I will be interested in seeing what happens when CMAS is deployed widely = and we have some real life experience to analyze - especially on the use ca= se where everyone on a at rush h= our gets an alert at the same time to "take cover now". Yes, that's a potential problem, and the best way I know of to mitigate it = is to target alert delivery as precisely as possible to the folks actually = at risk. This is another area where the technical limitations of particula= r delivery systems sometimes get confused with best warning practice. - Art _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From Martin.Thomson@commscope.com Thu Sep 15 21:10:02 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348811E80B1 for ; Thu, 15 Sep 2011 21:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOdaXCdLqwv7 for ; Thu, 15 Sep 2011 21:10:02 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 5D20B11E8086 for ; Thu, 15 Sep 2011 21:10:01 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-53-4e72cc9bcb9a Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 4D.49.19263.B9CC27E4; Thu, 15 Sep 2011 23:12:11 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 15 Sep 2011 23:12:11 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 15 Sep 2011 23:12:10 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 16 Sep 2011 12:11:45 +0800 From: "Thomson, Martin" To: Art Botterell , "atoca@ietf.org" Date: Fri, 16 Sep 2011 12:11:43 +0800 Thread-Topic: [atoca] Alert signing Thread-Index: Acx0Ayeuk9uejk4ZRsGwId5zsjYQpgAAFcRw Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609526@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE6094DA@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 04:10:03 -0000 On 2011-09-16 at 09:56:47, Art Botterell wrote: > Personally I like to think of CAP as a higher level of abstraction=20 > rather than a lesser denominator... since the content of a CAP alert=20 > is almost always richer than that of derived products... but that's=20 > probably just pride of authorship speaking. ;-) Well, if I didn't already know that names matter, I'd say that there's no d= ifference. But I suspect that both viewpoints are right to some extent. > Once we down-convert from the general standard to some transport-specific > representation it's rarely possible to recover all the original informati= on [...] This is an important point. To say that CAP is a baseline misrepresents it= , because it is usually something _more_ than what is ultimately delivered.= That is the key point that Mark made with his example. I don't know if the decision has been explicit, but I get the impression th= at the general desire from the group is to try to deliver CAP as far as pos= sible due to this effect. The point not being to preclude the sorts of opt= imizations Mark was talking about, but just to avoid being responsible for = any degradation. That should mean better transport-specific downgrades. --Martin From mark.wood@drcf.net Fri Sep 16 01:57:47 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2554421F8BB9 for ; Fri, 16 Sep 2011 01:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgm1OmPRM5tq for ; Fri, 16 Sep 2011 01:57:46 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBD121F85AA for ; Fri, 16 Sep 2011 01:57:45 -0700 (PDT) X-Trace: 514821429/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoHAJEPc05RVitW/2dsb2JhbABBmRmOQXiBWggyHBwUBQYkDDIaBh4BAQQeh26UdqMggg+BBQSMTYwHh3mEKQ X-IronPort-AV: E=Sophos;i="4.68,392,1312153200"; d="scan'208";a="514821429" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 16 Sep 2011 09:59:51 +0100 From: "Mark" To: In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609526@SISPE7MB1.commscope.com> Date: Fri, 16 Sep 2011 09:59:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acx0Ayeuk9uejk4ZRsGwId5zsjYQpgAAFcRwABHNZSA= X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20110916085746.2EBD121F85AA@ietfa.amsl.com> Subject: [atoca] Content Responsibility. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 08:57:47 -0000 Friends; - -MT- "The point not being to preclude the sorts of optimizations Mark was talking about, but just to avoid being responsible for any degradation. That should mean better transport-specific downgrades." - -MW- There is another 'legal liability' aspect to this that we need to bear in mind. As techno-geeks we don't have the lawful authority to create or in any way modify the *content* of the message. If the message turns out to be wrong, or only partially correct, then liability for decisions about this must lie with the authorised originating sender (e.g. the police chief), who does have the appropriate indemnity under local law, and under the trust protocol which applies to this relationship with this network. This is done because, quite rightly, the "participating network" should on no account be held liable for the content of the message, otherwise they would be crazy to participate in the first place. (If I was an AT&T lawyer I would run a mile from any deal that did not fully indemnify my company from liability for content). Clearly the 'trust protocol' lays out who is liable for what, and the AGWs make sure that everyone's conditions for participating have been faithfully followed [well, at least mine do]. IMHO, As soon as we mess with the content in any way, we may make ourselves liable to litigation. So it makes sense to transmit the whole original message 'verbatim' until the last possible inch unless there is compelling reason to alter it. - Mark - From keith.drage@alcatel-lucent.com Fri Sep 16 03:58:03 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24421F8BB8 for ; Fri, 16 Sep 2011 03:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+o7J+i8rGhU for ; Fri, 16 Sep 2011 03:58:02 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7EC21F8BA6 for ; Fri, 16 Sep 2011 03:58:01 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8GB09pi013867 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Sep 2011 13:00:12 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 16 Sep 2011 13:00:09 +0200 From: "DRAGE, Keith (Keith)" To: "DALY, BRIAN K" , Art Botterell , "atoca@ietf.org" Date: Fri, 16 Sep 2011 13:00:06 +0200 Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc7MNPl9Z5lcp/kmE0Yrq8zh6zpVO/0aAgAAHyYCAAAWZgIAADaOAgAAbFXCAAKKPYA== Message-ID: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> In-Reply-To: <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 10:58:03 -0000 I suggest that in some descriptive part of some potential ATOCA document we= capture some of this.=20 Keith > -----Original Message----- > From: DALY, BRIAN K [mailto:bd2985@att.com] > Sent: 16 September 2011 02:26 > To: DRAGE, Keith (Keith); Art Botterell; atoca@ietf.org > Subject: RE: [atoca] Alert signing >=20 > " Did the research come up with any input as to what was enough, before > people ignored it. People are talking about fragmentation, which doesn't > even become an issue until MTU size is exceeded in IP (1500 bytes). Cell > broadcast survives on the order of a hundred bytes." >=20 > Actually the FCC's Commercial Mobile System Alert Advisory Committee spen= d > considerable time looking at the issue of "how long should a message be" > especially when rendered on a mobile device screen AND accounted for the > needs of individuals with disabilities. >=20 > Bottom line - people don't want to have to scroll through multiple screen= s > to read information - they want to be told "to the point" with a minimal > amount of scrolling through pages of text. >=20 > The input obtained from that study is one of the drivers that limited a > CMAS alert message to 90 characters (although there was technical > consideration as well), PLUS there was research that stated to be most > effective the alert message needs to contain the following information, i= n > this order: >=20 > 1. What's happening (e.g. Tornado Warning) > 2. Where it is happening (e.g. "in your/this area") > 3. What action to take (e.g., "take shelter now") > 4. How long it will be happening (e.g. "until 7pm") > 5. Who authorized this/sent this (e.g., "NWS") >=20 > -------- > Brian K. Daly > Director, Core Network & Govn't/Regulatory Standards > AT&T Services, Inc. > +1.425.580.6873 > brian.k.daly@att.com >=20 > Rethink Possible >=20 >=20 > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > DRAGE, Keith (Keith) > Sent: Thursday, September 15, 2011 9:40 AM > To: Art Botterell; atoca@ietf.org > Subject: Re: [atoca] Alert signing >=20 > See below >=20 > > -----Original Message----- > > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf > Of > > Art Botterell > > Sent: 15 September 2011 16:52 > > To: atoca@ietf.org > > Subject: Re: [atoca] Alert signing > > > > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: > > > > > I would argue that at least short messages does create a constraint o= n > > the initiator to actually draft meaningful messages in a concise > > imperative form rather than finally getting around to the real message > in > > page 5 of a sent document. > > > > The design of CAP was based on a considerable body of social science > > research regarding warning effectiveness. While brevity is generally a > > virtue, it turns out that it's possible to make a warning message too > > brief, at least if actually eliciting protective action among the > > recipients is the goal. In particular, a simple "imperative" message > > without context will generally not result in action. (E.g., if I merel= y > > shouted "RUN, NOW!" would you run immediately, or would you ask me "Why= ? > > In which direction? How far? And does this really apply to me?") > > > Agreed. >=20 > Did the research come up with any input as to what was enough, before > people ignored it. People are talking about fragmentation, which doesn't > even become an issue until MTU size is exceeded in IP (1500 bytes). Cell > broadcast survives on the order of a hundred bytes. >=20 > At what point do these discussions become irrelevant because the messages > should be shorter than that. >=20 > Keith >=20 >=20 > > Encouraging warning originators to write to the point is a worthy goal, > > but arguably not something that can be enforced a-priori through > > technology. The whole point of CAP was to create an interoperability > > layer that was independent of technical constraints, in the awareness > that > > different delivery mechanisms will impose their own limitations. (You > can > > think of the CAP message as the Platonic ideal of the warning message, > one > > which casts different shadows on different walls of the cave but has an > > essential nature common to them all.) > > > > > I'd also rather not provide space for each message to be front-ended > by > > legal disclaimers saying that the sender accepts no responsibility for > the > > information supplied, and is not responsible for any accident or damage > > accruing on the recipient by acting on this message. > > > > Not sure technology can defeat bureaucracy, but I share your desire. > > However, are we really talking about what size message will maximize > > warning effectiveness? Sounds to me like our true concern is how to fi= t > > standard messages into the constraints of a pre-existing technology. > > > > - Art > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From bd2985@att.com Fri Sep 16 04:48:35 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66021F8B7B for ; Fri, 16 Sep 2011 04:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.586 X-Spam-Level: X-Spam-Status: No, score=-106.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4cssssjYLOP for ; Fri, 16 Sep 2011 04:48:34 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id BA86421F8B72 for ; Fri, 16 Sep 2011 04:48:34 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1316173847!38545390!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10785 invoked from network); 16 Sep 2011 11:50:47 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 11:50:47 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GBolbh001245; Fri, 16 Sep 2011 06:50:47 -0500 Received: from WABOTH9MSGHUB8D.ITServices.sbc.com (waboth9msghub8d.itservices.sbc.com [135.163.35.93]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GBobjW001185; Fri, 16 Sep 2011 06:50:37 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8D.ITServices.sbc.com ([135.163.35.93]) with mapi id 14.01.0289.001; Fri, 16 Sep 2011 04:50:37 -0700 From: "DALY, BRIAN K" To: Mark , "atoca@ietf.org" Thread-Topic: [atoca] Content Responsibility. Thread-Index: AQHMdE8K0L1Zxo+Eg0mPRNunNOpf0pVP4zsg Date: Fri, 16 Sep 2011 11:50:36 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F9623C5BF@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910CE609526@SISPE7MB1.commscope.com> <20110916085746.2EBD121F85AA@ietfa.amsl.com> In-Reply-To: <20110916085746.2EBD121F85AA@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Content Responsibility. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 11:48:35 -0000 Mark - Excellent points! And you described the reason why the CMSAAC developed the= concept of the Federal Alert Aggregator and Alert Gateway concept in CMAS. There are upwards of 9000 agencies that have authority to initiate alerts, = and the potential for 50,000+ alert originators. As a "broadcaster" of the = alerts in commercial mobile networks, we cannot and must not be responsible= to determine if an agency or particular alert originator has the authority= to generate an alert and send it to the public. That is why the FEMA iPAWS= architecture is critical as they have the responsibility for credentialing= , authorizing of alert initiators, and ultimately take the responsibility o= ff the "broadcaster" of the alert. The trusted interface to the Federal Ale= rt Gateway (part of the iPAWS architecture) is the CMSPs guarantee that the= liability rests with FEMA, as long as we broadcast the CMAS alert verbatim= and do not change or interfere with the message. This is the only model commercial mobile operators will follow to solve the= issue you clearly highlight below. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of M= ark Sent: Friday, September 16, 2011 2:00 AM To: atoca@ietf.org Subject: [atoca] Content Responsibility. Friends; - -MT- "The point not being to preclude the sorts of optimizations Mark was talking about, but just to avoid being responsible for any degradation. That should mean better transport-specific downgrades." - -MW- There is another 'legal liability' aspect to this that we need to bear in mind. As techno-geeks we don't have the lawful authority to create or in any way modify the *content* of the message.=20 If the message turns out to be wrong, or only partially correct, then liability for decisions about this must lie with the authorised originating sender (e.g. the police chief), who does have the appropriate indemnity under local law, and under the trust protocol which applies to this relationship with this network.=20 This is done because, quite rightly, the "participating network" should on no account be held liable for the content of the message, otherwise they would be crazy to participate in the first place. (If I was an AT&T lawyer = I would run a mile from any deal that did not fully indemnify my company from liability for content). =20 Clearly the 'trust protocol' lays out who is liable for what, and the AGWs make sure that everyone's conditions for participating have been faithfully followed [well, at least mine do]. =20 IMHO, As soon as we mess with the content in any way, we may make ourselves liable to litigation. So it makes sense to transmit the whole original message 'verbatim' until the last possible inch unless there is compelling reason to alter it.=20 - Mark - _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From john.tacken@gmail.com Fri Sep 16 06:15:02 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1427F21F8BE7 for ; Fri, 16 Sep 2011 06:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuTks5o5f3qs for ; Fri, 16 Sep 2011 06:15:00 -0700 (PDT) Received: from mail-ew0-f43.google.com (mail-ew0-f43.google.com [209.85.215.43]) by ietfa.amsl.com (Postfix) with ESMTP id D780D21F8B8E for ; Fri, 16 Sep 2011 06:14:59 -0700 (PDT) Received: by ewy20 with SMTP id 20so2259346ewy.16 for ; Fri, 16 Sep 2011 06:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:reply-to:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type; bh=NSzCE519rVDVQwPymoPklregJRsCXjE2hSwSzGPmiIo=; b=N6C9qdviik9GXO244oTTsUc6YLccouRCrySWPANbWqOEEBWvoMKzfxZXt39oAnG9g8 FyjUz/T0UqlkcP6aGSsw49eL+L7YdasVoPp8j5OioQ8cFVIcUMX9xvS961MCNoKm/uY4 QwmcDBOzKemsxw2JgTn3036W3liHyIjHcLEYc= Received: by 10.14.19.136 with SMTP id n8mr806261een.162.1316179032664; Fri, 16 Sep 2011 06:17:12 -0700 (PDT) Received: from ?IPv6:2001:980:4f1c:1:799b:75b8:763b:cc06? ([2001:980:4f1c:1:799b:75b8:763b:cc06]) by mx.google.com with ESMTPS id u14sm18407319eeh.1.2011.09.16.06.17.10 (version=SSLv3 cipher=OTHER); Fri, 16 Sep 2011 06:17:11 -0700 (PDT) Sender: John Tacken Message-ID: <4E734C23.5020800@conict.com> Date: Fri, 16 Sep 2011 15:16:19 +0200 From: John Tacken Organization: Conict Consultants B.V. User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: atoca@ietf.org References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> In-Reply-To: <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> Content-Type: multipart/alternative; boundary="------------050601030209030300090105" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: john.tacken@conict.com List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 13:16:19 -0000 This is a multi-part message in MIME format. --------------050601030209030300090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit May I add some comments based on experience in The Netherlands with NL-ALert (CB based public warning system, to be launched very soon): *Message size *For NL-Alert we have a comparable message content structure as described in Brian's email below. Additionally, we have added a date/timestamp and a link to follow-up information on the crisis. We have done several crisiscomm workshops with PSAPs, police and fire department. It has proven to be very difficult during these workshops to squeeze the required information (i.e. the 5 points mentioned below) in 90 characters. Try it yourself and you will be convinced. The First Responders have urged us to remove the (typical CB) limit of 93 characters. For them, a 200 or 300 characters max would be more appropriate. I agree that civilians should not be overloaded with text during a crisis. But we should look at the future of mobile phones and not to the past. Older phones may have a maximum capacity of 60 characters to display before there is a need for scrolling. Newer CMAS compatible smartphones that we have tested very neatly display the whole message also if it has 200 characters or more. To understand how much information people can process during a crisis, The University of Delft is currently performing additional research on the message content via a webexperiment where people are asked to provide feedback on specific messages they receive. In Dutch: www.waarschuwingsberichten.nl *Use case *During the workshops we did with the police and fire department, we have noted that not all the required information for sending a complete alert message is available from the start. "What's happening" and "where is it happening" is information that is available from the start of a crisis. But it can take some time before you can advise civilians what action to take?. E.g. during a fire in a chemical plant, it takes time for the fire department to analyse the content of the chemicals and come up with an advise what to do. Crisisicommunication experts that I have spoken with prefer to send the available information immediately after it has become available and add additional information later. As a government, you are never quicker than Twitter, but you should not wait too long providing info to the public. So there is a clear need to be able to update existing alert messages. John Tacken projectmanager implementation NL-Alert Op 16-9-2011 3:25, DALY, BRIAN K schreef: > " Did the research come up with any input as to what was enough, before people ignored it. People are talking about fragmentation, which doesn't even become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast survives on the order of a hundred bytes." > > Actually the FCC's Commercial Mobile System Alert Advisory Committee spend considerable time looking at the issue of "how long should a message be" especially when rendered on a mobile device screen AND accounted for the needs of individuals with disabilities. > > Bottom line - people don't want to have to scroll through multiple screens to read information - they want to be told "to the point" with a minimal amount of scrolling through pages of text. > > The input obtained from that study is one of the drivers that limited a CMAS alert message to 90 characters (although there was technical consideration as well), PLUS there was research that stated to be most effective the alert message needs to contain the following information, in this order: > > 1. What's happening (e.g. Tornado Warning) > 2. Where it is happening (e.g. "in your/this area") > 3. What action to take (e.g., "take shelter now") > 4. How long it will be happening (e.g. "until 7pm") > 5. Who authorized this/sent this (e.g., "NWS") > > -------- > Brian K. Daly > Director, Core Network& Govn't/Regulatory Standards > AT&T Services, Inc. > +1.425.580.6873 > brian.k.daly@att.com > > Rethink Possible > > > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: Thursday, September 15, 2011 9:40 AM > To: Art Botterell; atoca@ietf.org > Subject: Re: [atoca] Alert signing > > See below > >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of >> Art Botterell >> Sent: 15 September 2011 16:52 >> To: atoca@ietf.org >> Subject: Re: [atoca] Alert signing >> >> On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: >> >>> I would argue that at least short messages does create a constraint on >> the initiator to actually draft meaningful messages in a concise >> imperative form rather than finally getting around to the real message in >> page 5 of a sent document. >> >> The design of CAP was based on a considerable body of social science >> research regarding warning effectiveness. While brevity is generally a >> virtue, it turns out that it's possible to make a warning message too >> brief, at least if actually eliciting protective action among the >> recipients is the goal. In particular, a simple "imperative" message >> without context will generally not result in action. (E.g., if I merely >> shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? >> In which direction? How far? And does this really apply to me?") >> > Agreed. > > Did the research come up with any input as to what was enough, before people ignored it. People are talking about fragmentation, which doesn't even become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast survives on the order of a hundred bytes. > > At what point do these discussions become irrelevant because the messages should be shorter than that. > > Keith > > >> Encouraging warning originators to write to the point is a worthy goal, >> but arguably not something that can be enforced a-priori through >> technology. The whole point of CAP was to create an interoperability >> layer that was independent of technical constraints, in the awareness that >> different delivery mechanisms will impose their own limitations. (You can >> think of the CAP message as the Platonic ideal of the warning message, one >> which casts different shadows on different walls of the cave but has an >> essential nature common to them all.) >> >>> I'd also rather not provide space for each message to be front-ended by >> legal disclaimers saying that the sender accepts no responsibility for the >> information supplied, and is not responsible for any accident or damage >> accruing on the recipient by acting on this message. >> >> Not sure technology can defeat bureaucracy, but I share your desire. >> However, are we really talking about what size message will maximize >> warning effectiveness? Sounds to me like our true concern is how to fit >> standard messages into the constraints of a pre-existing technology. >> >> - Art >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca > > -- > > *___________________________________________* > > *John Tacken | Conict Consultants BV* > Hengeveldstraat 42, 3572 KJ Utrecht, The Netherlands > > *M**+31 6 28525280 > E*john.tacken@conict.com > *W *www.conict.com* > * --------------050601030209030300090105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit May I add some comments based on experience in The Netherlands with NL-ALert (CB based public warning system, to be launched very soon):

Message size
For NL-Alert we have a comparable message content structure as described in Brian's email below. Additionally, we have added a date/timestamp and a link to follow-up information on the crisis. We have done several crisiscomm workshops with PSAPs, police and fire department. It has proven to be very difficult during these workshops to squeeze the required information (i.e. the 5 points mentioned below) in 90 characters. Try it yourself and you will be convinced. The First Responders have urged us to remove the (typical CB) limit of 93 characters. For them, a 200 or 300 characters max would be more appropriate.

I agree that civilians should not be overloaded with text during a crisis. But we should look at the future of mobile phones and not to the past. Older phones may have a maximum capacity of 60 characters to display before there is a need for scrolling. Newer CMAS compatible smartphones that we have tested very neatly display the whole message also if it has 200 characters or more.

To understand how much information people can process during a crisis, The University of Delft is currently performing additional research on the message content via a webexperiment where people are asked to provide feedback on specific messages they receive. In Dutch: www.waarschuwingsberichten.nl

Use case
During the workshops we did with the police and fire department, we have noted that not all the required information for sending a complete alert message is available from the start. "What's happening" and "where is it happening" is information that is available from the start of a crisis. But it can take some time before you can advise civilians what action to take?. E.g. during a fire in a chemical plant, it takes time for the fire department to analyse the content of the chemicals and come up with an advise what to do. Crisisicommunication experts that I have spoken with prefer to send the available information immediately after it has become available and add additional information later. As a government, you are never quicker than Twitter, but you should not wait too long providing info to the public. So there is a clear need to be able to update existing alert messages.

John Tacken
projectmanager implementation NL-Alert

Op 16-9-2011 3:25, DALY, BRIAN K schreef:

" Did the research come up with any input as to what was enough, before people ignored it. People are talking about fragmentation, which doesn't even become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast survives on the order of a hundred bytes." Actually the FCC's Commercial Mobile System Alert Advisory Committee spend considerable time looking at the issue of "how long should a message be" especially when rendered on a mobile device screen AND accounted for the needs of individuals with disabilities. Bottom line - people don't want to have to scroll through multiple screens to read information - they want to be told "to the point" with a minimal amount of scrolling through pages of text. The input obtained from that study is one of the drivers that limited a CMAS alert message to 90 characters (although there was technical consideration as well), PLUS there was research that stated to be most effective the alert message needs to contain the following information, in this order: 1. What's happening (e.g. Tornado Warning) 2. Where it is happening (e.g. "in your/this area") 3. What action to take (e.g., "take shelter now") 4. How long it will be happening (e.g. "until 7pm") 5. Who authorized this/sent this (e.g., "NWS") -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, September 15, 2011 9:40 AM To: Art Botterell; atoca@ietf.org Subject: Re: [atoca] Alert signing See below

-----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Art Botterell Sent: 15 September 2011 16:52 To: atoca@ietf.org Subject: Re: [atoca] Alert signing On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote:

I would argue that at least short messages does create a constraint on

the initiator to actually draft meaningful messages in a concise imperative form rather than finally getting around to the real message in page 5 of a sent document. The design of CAP was based on a considerable body of social science research regarding warning effectiveness. While brevity is generally a virtue, it turns out that it's possible to make a warning message too brief, at least if actually eliciting protective action among the recipients is the goal. In particular, a simple "imperative" message without context will generally not result in action. (E.g., if I merely shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? In which direction? How far? And does this really apply to me?")

Agreed. Did the research come up with any input as to what was enough, before people ignored it. People are talking about fragmentation, which doesn't even become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast survives on the order of a hundred bytes. At what point do these discussions become irrelevant because the messages should be shorter than that. Keith

Encouraging warning originators to write to the point is a worthy goal, but arguably not something that can be enforced a-priori through technology. The whole point of CAP was to create an interoperability layer that was independent of technical constraints, in the awareness that different delivery mechanisms will impose their own limitations. (You can think of the CAP message as the Platonic ideal of the warning message, one which casts different shadows on different walls of the cave but has an essential nature common to them all.)

I'd also rather not provide space for each message to be front-ended by

legal disclaimers saying that the sender accepts no responsibility for the information supplied, and is not responsible for any accident or damage accruing on the recipient by acting on this message. Not sure technology can defeat bureaucracy, but I share your desire. However, are we really talking about what size message will maximize warning effectiveness? Sounds to me like our true concern is how to fit standard messages into the constraints of a pre-existing technology. - Art _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca

_______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca

--

___________________________________________

John Tacken | Conict Consultants BV
Hengeveldstraat 42, 3572 KJ Utrecht, The Netherlands
M +31 6 28525280
E    john.tacken@conict.com
W www.conict.com

--------------050601030209030300090105-- From bd2985@att.com Fri Sep 16 06:48:53 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF81221F8C3C for ; Fri, 16 Sep 2011 06:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvOiW9YT4XY2 for ; Fri, 16 Sep 2011 06:48:48 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2C45221F8C3D for ; Fri, 16 Sep 2011 06:48:48 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1316181060!39536402!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21034 invoked from network); 16 Sep 2011 13:51:01 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 13:51:01 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GDp0ei000887; Fri, 16 Sep 2011 08:51:00 -0500 Received: from WABOTH9MSGHUB8F.ITServices.sbc.com (waboth9msghub8f.itservices.sbc.com [135.163.35.68]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GDorMa000821; Fri, 16 Sep 2011 08:50:53 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8F.ITServices.sbc.com ([135.163.35.68]) with mapi id 14.01.0289.001; Fri, 16 Sep 2011 06:50:52 -0700 From: "DALY, BRIAN K" To: "john.tacken@conict.com" , "atoca@ietf.org" Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc7MNPl9Z5lcp/kmE0Yrq8zh6zpVO/0aAgAAHyYCAAAWZgIAADaOAgAAbFXCAAT43gP//k08w Date: Fri, 16 Sep 2011 13:50:51 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F9623C86F@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> <4E734C23.5020800@conict.com> In-Reply-To: <4E734C23.5020800@conict.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: multipart/alternative; boundary="_000_95C5C7A891135E4685CCFAE997351F9623C86FWABOTH9MSGUSR8BIT_" MIME-Version: 1.0 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 13:48:53 -0000 --_000_95C5C7A891135E4685CCFAE997351F9623C86FWABOTH9MSGUSR8BIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See below ... -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of J= ohn Tacken Sent: Friday, September 16, 2011 6:16 AM To: atoca@ietf.org Subject: Re: [atoca] Alert signing May I add some comments based on experience in The Netherlands with NL-ALer= t (CB based public warning system, to be launched very soon): Message size For NL-Alert we have a comparable message content structure as described in= Brian's email below. Additionally, we have added a date/timestamp and a li= nk to follow-up information on the crisis. We have done several crisiscomm = workshops with PSAPs, police and fire department. It has proven to be very = difficult during these workshops to squeeze the required information (i.e. = the 5 points mentioned below) in 90 characters. Try it yourself and you wil= l be convinced. The First Responders have urged us to remove the (typical C= B) limit of 93 characters. For them, a 200 or 300 characters max would be m= ore appropriate. Actually GSM/UMTS cell broadcast is not limited to 93 characters, but= can handle upwards of 1000 characters. Other technologies have a limit, an= d thus the 90 character CMAS constraint. The problem is because of multiple= technologies in the U.S. and the desire to send a consistent message to al= l users, the 90 characters were chosen. Do it limit? Certainly, but CMAS is= a "bell ringer" only and not a full information service such as NOAA Weath= er Radio. I agree that civilians should not be overloaded with text during a crisis. = But we should look at the future of mobile phones and not to the past. Olde= r phones may have a maximum capacity of 60 characters to display before the= re is a need for scrolling. Newer CMAS compatible smartphones that we have = tested very neatly display the whole message also if it has 200 characters = or more. However, not everyone will have a newer smartphone. There is - and al= ways will be - a large number of basic feature phones out there that must b= e accommodated. Thus the lowest common denominator. To understand how much information people can process during a crisis, The = University of Delft is currently performing additional research on the mess= age content via a webexperiment where people are asked to provide feedback = on specific messages they receive. In Dutch: www.waarschuwingsberichten.nl<= http://www.waarschuwingsberichten.nl> Use case During the workshops we did with the police and fire department, we have no= ted that not all the required information for sending a complete alert mess= age is available from the start. "What's happening" and "where is it happen= ing" is information that is available from the start of a crisis. But it ca= n take some time before you can advise civilians what action to take?. E.g.= during a fire in a chemical plant, it takes time for the fire department t= o analyse the content of the chemicals and come up with an advise what to d= o. Crisisicommunication experts that I have spoken with prefer to send the = available information immediately after it has become available and add add= itional information later. As a government, you are never quicker than Twit= ter, but you should not wait too long providing info to the public. So ther= e is a clear need to be able to update existing alert messages. John Tacken projectmanager implementation NL-Alert Op 16-9-2011 3:25, DALY, BRIAN K schreef: " Did the research come up with any input as to what was enough, before peo= ple ignored it. People are talking about fragmentation, which doesn't even = become an issue until MTU size is exceeded in IP (1500 bytes). Cell broadca= st survives on the order of a hundred bytes." Actually the FCC's Commercial Mobile System Alert Advisory Committee spend = considerable time looking at the issue of "how long should a message be" es= pecially when rendered on a mobile device screen AND accounted for the need= s of individuals with disabilities. Bottom line - people don't want to have to scroll through multiple screens = to read information - they want to be told "to the point" with a minimal am= ount of scrolling through pages of text. The input obtained from that study is one of the drivers that limited a CMA= S alert message to 90 characters (although there was technical consideratio= n as well), PLUS there was research that stated to be most effective the al= ert message needs to contain the following information, in this order: 1. What's happening (e.g. Tornado Warning) 2. Where it is happening (e.g. "in your/this area") 3. What action to take (e.g., "take shelter now") 4. How long it will be happening (e.g. "until 7pm") 5. Who authorized this/sent this (e.g., "NWS") -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-b= ounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, September 15, 2011 9:40 AM To: Art Botterell; atoca@ietf.org Subject: Re: [atoca] Alert signing See below -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-b= ounces@ietf.org] On Behalf Of Art Botterell Sent: 15 September 2011 16:52 To: atoca@ietf.org Subject: Re: [atoca] Alert signing On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: I would argue that at least short messages does create a constraint on the initiator to actually draft meaningful messages in a concise imperative form rather than finally getting around to the real message in page 5 of a sent document. The design of CAP was based on a considerable body of social science research regarding warning effectiveness. While brevity is generally a virtue, it turns out that it's possible to make a warning message too brief, at least if actually eliciting protective action among the recipients is the goal. In particular, a simple "imperative" message without context will generally not result in action. (E.g., if I merely shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? In which direction? How far? And does this really apply to me?") Agreed. Did the research come up with any input as to what was enough, before peopl= e ignored it. People are talking about fragmentation, which doesn't even be= come an issue until MTU size is exceeded in IP (1500 bytes). Cell broadcast= survives on the order of a hundred bytes. At what point do these discussions become irrelevant because the messages s= hould be shorter than that. Keith Encouraging warning originators to write to the point is a worthy goal, but arguably not something that can be enforced a-priori through technology. The whole point of CAP was to create an interoperability layer that was independent of technical constraints, in the awareness that different delivery mechanisms will impose their own limitations. (You can think of the CAP message as the Platonic ideal of the warning message, one which casts different shadows on different walls of the cave but has an essential nature common to them all.) I'd also rather not provide space for each message to be front-ended by legal disclaimers saying that the sender accepts no responsibility for the information supplied, and is not responsible for any accident or damage accruing on the recipient by acting on this message. Not sure technology can defeat bureaucracy, but I share your desire. However, are we really talking about what size message will maximize warning effectiveness? Sounds to me like our true concern is how to fit standard messages into the constraints of a pre-existing technology. - Art _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca -- ___________________________________________ John Tacken | Conict Consultants BV Hengeveldstraat 42, 3572 KJ Utrecht, The Netherlands M +31 6 28525280 E john.tacken@conict.com W www.conict.com --_000_95C5C7A891135E4685CCFAE997351F9623C86FWABOTH9MSGUSR8BIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See below …

<= /p>

--------

Brian K. Daly<= /span>

Director, Core Network &a= mp; Govn't/Regulatory Standards

AT&T Services, Inc.

+1.425.580.6873<= /o:p>

brian.k.daly@att.com

<= /p>
Rethink Possible<= /o:p>

<= /p>

From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf= .org] On Behalf Of John Tacken
Sent: Friday, September 16, 2011 6:16 AM
To: atoca@ietf.org
Subject: Re: [atoca] Alert signing

May I add some comments based on experience in The N= etherlands with NL-ALert (CB based public warning system, to be launched ve= ry soon):

Message size
For NL-Alert we have a comparable message content structure as describe= d in Brian's email below. Additionally, we have added a date/timestamp and = a link to follow-up information on the crisis. We have done several crisisc= omm workshops with PSAPs, police and fire department. It has proven to be very difficult during these works= hops to squeeze the required information (i.e. the 5 points mentioned below= ) in 90 characters. Try it yourself and you will be convinced. The First Re= sponders have urged us to remove the (typical CB) limit of 93 characters. For them, a 200 or 300 characters= max would be more appropriate.

<= /p>
<bkd> Actually GSM/= UMTS cell broadcast is not limited to 93 characters, but can handle upwards= of 1000 characters. Other technologies have a limit, and thus the 90 character CMAS constraint. The problem is because of multiple techn= ologies in the U.S. and the desire to send a consistent message to all user= s, the 90 characters were chosen. Do it limit? Certainly, but CMAS is a = 220;bell ringer” only and not a full information service such as NOAA Weather Radio.

I agree that civilians should not be overloaded with text during a crisis. = But we should look at the future of mobile phones and not to the past. Olde= r phones may have a maximum capacity of 60 characters to display before the= re is a need for scrolling. Newer CMAS compatible smartphones that we have tested very neatly display the wh= ole message also if it has 200 characters or more.

<= /p>
<bkd> However, not = everyone will have a newer smartphone. There is – and always will be = – a large number of basic feature phones out there that must be accom= modated. Thus the lowest common denominator.

To understand how much information people can process during a crisis, The = University of Delft is currently performing additional research on the mess= age content via a webexperiment where people are asked to provide feedback = on specific messages they receive. In Dutch: www.waarschuwin= gsberichten.nl

Use case
During the workshops we did with the police and fire department, we hav= e noted that not all the required information for sending a complete alert = message is available from the start. "What's happening" and "= ;where is it happening" is information that is available from the start of a crisis. But it can take some time before you= can advise civilians what action to take?. E.g. during a fire in a chemica= l plant, it takes time for the fire department to analyse the content of th= e chemicals and come up with an advise what to do. Crisisicommunication experts that I have spoken with pr= efer to send the available information immediately after it has become avai= lable and add additional information later. As a government, you are never = quicker than Twitter, but you should not wait too long providing info to the public. So there is a clear need t= o be able to update existing alert messages.

John Tacken
projectmanager implementation NL-Alert

Op 16-9-2011 3:25, DALY, BRIAN K schreef:

" Did the research come up with any input as to what was enough, = before people ignored it. People are talking about fragmentation, which doe= sn't even become an issue until MTU size is exceeded in IP (1500 bytes). Ce= ll broadcast survives on the order of a hundred bytes."

Actually the FCC's Commercial Mobile System Alert Advisory Committee s= pend considerable time looking at the issue of "how long should a mess= age be" especially when rendered on a mobile device screen AND account= ed for the needs of individuals with disabilities.

Bottom line - people don't want to have to scroll through multiple scr= eens to read information - they want to be told "to the point" wi= th a minimal amount of scrolling through pages of text.

The input obtained from that study is one of the drivers that limited = a CMAS alert message to 90 characters (although there was technical conside= ration as well), PLUS there was research that stated to be most effective t= he alert message needs to contain the following information, in this order:=

1. What's happening (e.g. Tornado Warning)

2. Where it is happening (e.g. "in your/this area")

3. What action to take (e.g., "take shelter now")=

4. How long it will be happening (e.g. "until 7pm")

5. Who authorized this/sent this (e.g., "NWS")

--------

Brian K. Daly

Director, Core Network & Govn't/Regulatory Standards
AT&T Services, Inc.

+1.425.580.6873

brian.k.daly@att.com<= /o:p>

Rethink Possible

-----Original Message-----

From: atoca-bounces@ietf.org= [mailto:atoca-bounces@ietf.o= rg] On Behalf Of DRAGE, Keith (Keith)

Sent: Thursday, September 15, 2011 9:40 AM

To: Art Botterell; atoca@ietf.org

Subject: Re: [atoca] Alert signing

See below

-----Original Message-----

From: atoca-bounces@ietf.org= [mailto:atoca-bounces@ietf.o= rg] On Behalf Of

Art Botterell

Sent: 15 September 2011 16:52

To: atoca@ietf.org
Subject: Re: [atoca] Alert signing

On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote:

I would argue that at least short messages does create a constraint on=

the initiator to actually draft meaningful messages in a concise<= /o:p>

imperative form rather than finally getting around to the real message= in

page 5 of a sent document.

The design of CAP was based on a considerable body of social science

research regarding warning effectiveness. While brevity is gener= ally a

virtue, it turns out that it's possible to make a warning message too<= o:p>

brief, at least if actually eliciting protective action among the=

recipients is the goal. In particular, a simple "imperative= " message

without context will generally not result in action. (E.g., if I= merely

shouted "RUN, NOW!" would you run immediately, or would you = ask me "Why?

In which direction? How far? And does this really apply to me?")<= o:p>

Agreed.

Did the research come up with any input as to what was enough, before = people ignored it. People are talking about fragmentation, which doesn't ev= en become an issue until MTU size is exceeded in IP (1500 bytes). Cell broa= dcast survives on the order of a hundred bytes.

At what point do these discussions become irrelevant because the messa= ges should be shorter than that.

Keith

Encouraging warning originators to write to the point is a worthy goal= ,

but arguably not something that can be enforced a-priori through<= /o:p>

technology. The whole point of CAP was to create an interoperabi= lity

layer that was independent of technical constraints, in the awareness = that

different delivery mechanisms will impose their own limitations. = (You can

think of the CAP message as the Platonic ideal of the warning message,= one

which casts different shadows on different walls of the cave but has a= n

essential nature common to them all.)

I'd also rather not provide space for each message to be front-ended b= y

legal disclaimers saying that the sender accepts no responsibility for= the

information supplied, and is not responsible for any accident or damag= e

accruing on the recipient by acting on this message.

Not sure technology can defeat bureaucracy, but I share your desire.

However, are we really talking about what size message will maximize

warning effectiveness? Sounds to me like our true concern is how= to fit

standard messages into the constraints of a pre-existing technology.

- Art

_______________________________________________

atoca mailing list

atoca@ietf.org

https://www.ie= tf.org/mailman/listinfo/atoca

_______________________________________________

atoca mailing list

atoca@ietf.org

https://www.ie= tf.org/mailman/listinfo/atoca

_______________________________________________

atoca mailing list

atoca@ietf.org

https://www.ie= tf.org/mailman/listinfo/atoca

--

___________________= ________________________

John Tacken | Conic= t Consultants BV
Hengeveldstraat 42, 3572 KJ Utrecht, = The Netherlands

M +31 6 28525280
E    john.tacken@conict.com
W www.conict.com

--_000_95C5C7A891135E4685CCFAE997351F9623C86FWABOTH9MSGUSR8BIT_-- From mark.wood@drcf.net Fri Sep 16 06:49:45 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1521F8C43 for ; Fri, 16 Sep 2011 06:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFLv+Xd2cXp4 for ; Fri, 16 Sep 2011 06:49:45 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACC121F8C41 for ; Fri, 16 Sep 2011 06:49:45 -0700 (PDT) X-Trace: 514965502/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQIAHJTc05RVitW/2dsb2JhbABCmSGOOXiBUwEGCDIcMAUGAyE+GgYeAQEEHodulSqlPIEFBIxNjAiHeYQp X-IronPort-AV: E=Sophos;i="4.68,393,1312153200"; d="scan'208";a="514965502" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 16 Sep 2011 14:51:58 +0100 From: "Mark" To: In-Reply-To: Date: Fri, 16 Sep 2011 14:52:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acx0dBONpqdmHJuAQZ2nspqZh3GRtAAAuqRg X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20110916134945.3ACC121F8C41@ietfa.amsl.com> Subject: Re: [atoca] Content Responsibility. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 13:49:46 -0000 Hi I feel that I owe you a clarification on what I mean by 'verbatim'. I mean the content that the originator produced. If the originator did not produce and interactive map, for example, then we can't synthesise one! So it will be for the sender to create whatever message he wants to, in whatever formats. It will be the job of the participating distributing network to distribute in the format that they have agreed. For example, a message that may end up as a cell broadcast with small text, may also have a more verbose text version intended for email distribution and a slightly less verbose one for IM, twitter feed etc. So we expect an original CAP message to be very feature rich and the gateways to be reducing this as the message progresses towards final distribution. On the other hand, if an owner of a network such as a 4G broadband network is very confident, then he can transmit the whole CAP and let the user decide what he will display. Obviously we cant send streaming video to citizens (as an official public warning message)unless the authorised sender decided to do so. He must then take all liability for what is sent. Mark From bd2985@att.com Fri Sep 16 07:00:26 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC02421F8C0E for ; Fri, 16 Sep 2011 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gnz+NrReCDTa for ; Fri, 16 Sep 2011 07:00:26 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3604821F8ABD for ; Fri, 16 Sep 2011 07:00:26 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1316181759!38424920!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24222 invoked from network); 16 Sep 2011 14:02:40 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 14:02:40 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GE2dpw013225; Fri, 16 Sep 2011 09:02:39 -0500 Received: from WABOTH9MSGHUB8C.ITServices.sbc.com (waboth9msghub8c.itservices.sbc.com [135.163.35.217]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GE2Yfr013146; Fri, 16 Sep 2011 09:02:34 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8C.ITServices.sbc.com ([135.163.35.217]) with mapi id 14.01.0289.001; Fri, 16 Sep 2011 07:02:34 -0700 From: "DALY, BRIAN K" To: Mark , "atoca@ietf.org" Thread-Topic: [atoca] Content Responsibility. Thread-Index: Acx0dBON0L1Zxo+Eg0mPRNunNOpf0gAAuqRgAABypNA= Date: Fri, 16 Sep 2011 14:02:33 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F9623C95F@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <20110916134945.3ACC121F8C41@ietfa.amsl.com> In-Reply-To: <20110916134945.3ACC121F8C41@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Content Responsibility. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 14:00:26 -0000 Mark - I think the bottom line is the alert originator or an authorized government= entity ("gateway") has to develop the text, and operators or handsets shou= ld not have responsibility for figuring out which portions of the text shou= ld or should not be displayed. Thus as an operator I will transmit "verbatim" and expect the Federal Alert= Gateway to provide me with the exact text to broadcast over CB. I will not= change, modify, translate (e.g. to different languages), or do any other a= ction on the text other than to package it into a CB payload and broadcast = it. I do not envision a 4G network sending entire CAP messages to the device ei= ther - in fact, CMAS is carried over to 4G and will work exactly like it is= defined for GSM and UMTS. -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of M= ark Sent: Friday, September 16, 2011 6:52 AM To: atoca@ietf.org Subject: Re: [atoca] Content Responsibility. Hi=20 I feel that I owe you a clarification on what I mean by 'verbatim'. I mean the content that the originator produced. If the originator did not produce and interactive map, for example, then we can't synthesise one! So it will be for the sender to create whatever message he wants to, in whatever formats. It will be the job of the participating distributing network to distribute in the format that they have agreed.=20 For example, a message that may end up as a cell broadcast with small text, may also have a more verbose text version intended for email distribution and a slightly less verbose one for IM, twitter feed etc.=20 So we expect an original CAP message to be very feature rich and the gateways to be reducing this as the message progresses towards final distribution.=20 On the other hand, if an owner of a network such as a 4G broadband network is very confident, then he can transmit the whole CAP and let the user decide what he will display. Obviously we cant send streaming video to citizens (as an official public warning message)unless the authorised sender decided to do so. He must then take all liability for what is sent. Mark =20 _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From mark.wood@drcf.net Fri Sep 16 08:12:33 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0321F8B9B for ; Fri, 16 Sep 2011 08:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkHjZzZyj4lF for ; Fri, 16 Sep 2011 08:12:31 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4544E21F8AF0 for ; Fri, 16 Sep 2011 08:12:31 -0700 (PDT) X-Trace: 365395690/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQIAGZnc05RVitW/2dsb2JhbABBmSGOOXiBUwEGCDIcER8FBgMhPhoGHgEBBB6HbpR+pT+BBQSMTYwIh3mEKQ X-IronPort-AV: E=Sophos;i="4.68,394,1312153200"; d="scan'208";a="365395690" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 16 Sep 2011 16:14:37 +0100 From: "Mark" To: In-Reply-To: <95C5C7A891135E4685CCFAE997351F9623C95F@WABOTH9MSGUSR8B.ITServices.sbc.com> Date: Fri, 16 Sep 2011 16:14:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acx0dBON0L1Zxo+Eg0mPRNunNOpf0gAAuqRgAABypNAAAjQVkA== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Message-Id: <20110916151231.4544E21F8AF0@ietfa.amsl.com> Subject: Re: [atoca] Content Responsibility. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 15:12:33 -0000 Chaps; -BD- "I do not envision a 4G network sending entire CAP messages to the device either - in fact, CMAS is carried over to 4G and will work exactly like it is defined for GSM and UMTS." -MW- Maybe I am not being more all inclusive when I say '4G'. Maybe "networks" which are *not* operating GSM, UMTS or LTE standards will participate, and they may do so within a framework which is not at all like CMAS. For example if a university enterprise network were to offer such a service over its WiFi system, it may decide to go well beyond what CMAS requires as the IP multicast system seems to have no specific limits as to payload size. Also, CMAS is the result of negotiations between USA entities, whereas other non US entities, (and indeed non cellular networks), may decide that some aspects of CMAS are too limiting to really be a strict model (Though many of its structures such will be the same). I feel that more standards than ETWS, CMAS and ETSI 102-900 are yet to emerge from the back rooms of governments! So it's not safe to conclude that another participating network with different system technology will restrict their offering to the subscriber as much as CMAS has. IMHO this means that if the participating network will agree, then almost all of the CAP message would be distributed (minus any security things that the trust protocol removes, of course!). Provided they are happy with the burden of so doing. However this is the decision of the owners of the participating network, who are after all, providing their spectrum and base station network. This does need to be respected in my view. Mark From artbotterell@gmail.com Fri Sep 16 09:15:45 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B365721F8B4A for ; Fri, 16 Sep 2011 09:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUBwiqYPMe2O for ; Fri, 16 Sep 2011 09:15:43 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 791EC21F8B5D for ; Fri, 16 Sep 2011 09:15:43 -0700 (PDT) Received: by gxk19 with SMTP id 19so3635638gxk.31 for ; Fri, 16 Sep 2011 09:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=y5uR1ErbhYpqMw7ahwrSVFTDt5f9/j74AzASEjP7agA=; b=EONrRdHQ4v43e39YQ7A5b8DD4lvVftnn/prfsNWe1IDGI5nj+x4MM/sQxA/qvNVI26 qW8pz/4P4FNbl0aGsVElW7LcJehd7ZNS5MAkXPUaujPthLtkpvLDgmLHrbOf+ii6ZjZc 9g2RUhtCEZZ/afQOCb08yLoWTdZAWwi1NXdao= Received: by 10.68.24.170 with SMTP id v10mr1821250pbf.359.1316189877978; Fri, 16 Sep 2011 09:17:57 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id e8sm34275580pbc.8.2011.09.16.09.17.55 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Sep 2011 09:17:56 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <4E734C23.5020800@conict.com> Date: Fri, 16 Sep 2011 09:17:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <67D51AC1-08E2-4586-888F-2334890A4C9E@incident.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> <4E734C23.5020800@conict.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 16:15:45 -0000 I fear we may be drifting rather far afield here, from the original = subject of this thread and perhaps from the expertise of this body. But = having actually operated a large-scale, multi-medium public warning = system for some years, I do want to head off a couple of possible = misconceptions. On Sep 16, 2011, at 6:16 AM, John Tacken wrote: > "What's happening" and "where is it happening" is information that is = available from the start of a crisis. Um... not necessarily. Depending on the hazard type, there can be quite = a lot of ambiguity as to the what and where. An explosion, for example, = could be anything from an industrial accident to a dirty bomb. A gas = pipeline rupture here in California last year was miscategorized as an = airplane crash for, in some official corners, longer than an hour, = because it caused a large fire and occurred near a major airport... and = also because that's what responders had been expecting. This is why a = CAP message has a 'certainty' value, although admittedly it's often hard = to get officials to admit to any uncertainty! Anyway, the practical point is that an incident frequently results in a = series of updates to an initial alert message as the situation clarifies = and/or evolves. > But it can take some time before you can advise civilians what action = to take?.=20 Not really, and issuing alerts without protective-action recommendations = (the CAP 'instruction' field) is a Bad Idea for several reasons. First off, it's always possible to provide some sort of instruction, = even if its just "be aware and monitor for developments." In most cases = the default instruction is essentially shelter-in-place, since even if = an evacuation is contemplated we want folks to gather materials and = specific directions before they scatter pell-mell. Issuing an alert without instructions generally fails in a combination = of two ways. The first, more obvious, problem is that some folks will = adopt uncoordinated protective actions at random, thus creating the sort = of chaos that we sometimes (pejoratively and inaccurately) call "panic." = =20 The less obvious, but actually more common, problem is that an alert = without instructions is much less powerful in overcoming what the = scientists call the "normalcy bias" and the rest of us call plain old = denial. There are various ways this can work inside people's heads. = Some may rationalize that if there isn't a protective action = recommendation it must not be time to act yet. Others may infer that = the originating officials don't know what to do and therefore lack = credibility. It's amazing how many ways folks can find to rationalize = away an unexpected and inconvenient alert. We don't really know all the = mechanics, but the research is clear on the basic point: alerts without = instructions are markedly ineffective compared to alerts that have = them... even if, as noted above, they're general and preliminary. - Art From thorpe@oss.com Fri Sep 16 11:14:59 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290A221F8B5E for ; Fri, 16 Sep 2011 11:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWXGV9BXCsgo for ; Fri, 16 Sep 2011 11:14:58 -0700 (PDT) Received: from fortress.oss.com (fortress.oss.com [66.146.12.63]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB9D21F8B56 for ; Fri, 16 Sep 2011 11:14:58 -0700 (PDT) Received: from fortress (fortress [192.168.2.1]) by fortress.oss.com (8.13.8+Sun/8.13.8) with ESMTP id p8GIHDHL004650 for ; Fri, 16 Sep 2011 11:17:13 -0700 (PDT) Date: Fri, 16 Sep 2011 11:17:13 -0700 (PDT) From: Paul Thorpe To: atoca@ietf.org In-Reply-To: <24530_1316099272_4E7214C8_24530_7507_1_4E7214C4.40509@orange-ftgroup.com> Message-ID: References: <37F0CFF6-8D6A-4381-96A1-A2D1779FEAB1@incident.com> <24530_1316099272_4E7214C8_24530_7507_1_4E7214C4.40509@orange-ftgroup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [atoca] Broadcast Reqs X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 18:14:59 -0000 > -------- Original Message -------- > Subject: Re: [atoca] Broadcast Reqs > Date: Thu, 15 Sep 2011 07:48:52 -0700 > From: Art Botterell > To: trutkowski@netmagic.com, Eliot Christian > CC: atoca@ietf.org > > Yes, I'm thinking that a lot of the issue here is that the ASN.1 > serialization "looks hard." The (XML-based) caplib did seem to create a > comfort zone for implementers in the early days. Is there, or would it > be hard to create, a comparable reference implementation for ASN.1? > > I could probably get some Carnegie Mellon grad students to do the > programming if someone had a few bucks to throw at the problem... > > - Art > We do not have a specific implementation for the ASN.1 schema for CAP available, but I would like to point out that many of the existing ASN.1 tools, both commercial and free, have the ability to generate one automatically and directly from the ASN.1 schema. Typically, an application developer who uses an ASN.1 tool will submit an ASN.1 schema to the tool, and the tool will generate a set of data structures in a particular programming language (e.g., Java classes, C++ classes, C# classes, or C structs). In writing his application code, the developer will then deal with data structures defined in a familiar programming language, and will not be exposed to the details of the serialization. The runtime library of the ASN.1 tool provides functions that convert the content of the data structures into a standard PER encoding and vice versa. When using the ASN.1 schema in the CAP 1.1 standard, the data structures generated by the ASN.1 tool will be a representation of a CAP alert message in a formalism familiar to the developer. Several ASN.1 tools, both commercial and free, are listed on the ITU-T website at http://www.itu.int/ITU-T/asn1/links/index.htm. ---------------------------------------------------------------------------- Paul E. Thorpe Toll Free : 1-888-OSS-ASN1 OSS Nokalva International: 1-732-302-0750 Email: thorpe@oss.com Tech Support : 1-732-302-9669 http://www.oss.com Fax : 1-732-302-0023 From jmpolk@cisco.com Fri Sep 16 11:18:54 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C18921F8BB6 for ; Fri, 16 Sep 2011 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NNmCr2bR0AA for ; Fri, 16 Sep 2011 11:18:53 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1621F8BB3 for ; Fri, 16 Sep 2011 11:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=4110; q=dns/txt; s=iport; t=1316197268; x=1317406868; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=oc6Av/jMS5/vP6wsan5gK/HVl7CRtqckLj/Bix0mKKY=; b=YEoDHVHb4HryJPH6XNcqPURK2r9+pNdQ6yBy7IKw2NkmAUhmIeZQ7zwR 1tFqsCJKYLkp+5CTJeFjn0WcVghmlVHK9pTEg9yXI8jAjGxhoEFVxdPRJ xm/Zdv4jfLVmMi0aQRlNNuQoSWxX4FwbhmGHocGW8G+pIj94V3UkOgQ6y k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAACyTc06rRDoJ/2dsb2JhbAA/A5hhjn53gVMBAQEBAwEBAQ8BJQI0FwQHBBEEAQEBHgkHGQ4fCQMFBgESIodZlgYBni2Da4MNBIdvnSU X-IronPort-AV: E=Sophos;i="4.68,394,1312156800"; d="scan'208";a="2609229" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 16 Sep 2011 18:21:08 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8GIL8fp031325; Fri, 16 Sep 2011 18:21:08 GMT Message-Id: <201109161821.p8GIL8fp031325@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Sep 2011 13:21:07 -0500 To: "DALY, BRIAN K" , "DRAGE, Keith (Keith)" , Art Botterell , "atoca@ietf.org" From: "James M. Polk" In-Reply-To: <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITS ervices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 18:18:54 -0000 Brian IP does NOT have an MTU of 1500. I believe you are thinking of the IEEE 802.3 Ethernet MTU only here. James At 08:25 PM 9/15/2011, DALY, BRIAN K wrote: >" Did the research come up with any input as to what was enough, >before people ignored it. People are talking about fragmentation, >which doesn't even become an issue until MTU size is exceeded in IP >(1500 bytes). Cell broadcast survives on the order of a hundred bytes." > >-------- >Brian K. Daly >Director, Core Network & Govn't/Regulatory Standards >AT&T Services, Inc. >+1.425.580.6873 >brian.k.daly@att.com > >Rethink Possible > > >-----Original Message----- >From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On >Behalf Of DRAGE, Keith (Keith) >Sent: Thursday, September 15, 2011 9:40 AM >To: Art Botterell; atoca@ietf.org >Subject: Re: [atoca] Alert signing > >See below > > > -----Original Message----- > > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > > Art Botterell > > Sent: 15 September 2011 16:52 > > To: atoca@ietf.org > > Subject: Re: [atoca] Alert signing > > > > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: > > > > > I would argue that at least short messages does create a constraint on > > the initiator to actually draft meaningful messages in a concise > > imperative form rather than finally getting around to the real message in > > page 5 of a sent document. > > > > The design of CAP was based on a considerable body of social science > > research regarding warning effectiveness. While brevity is generally a > > virtue, it turns out that it's possible to make a warning message too > > brief, at least if actually eliciting protective action among the > > recipients is the goal. In particular, a simple "imperative" message > > without context will generally not result in action. (E.g., if I merely > > shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? > > In which direction? How far? And does this really apply to me?") > > >Agreed. > >Did the research come up with any input as to what was enough, >before people ignored it. People are talking about fragmentation, >which doesn't even become an issue until MTU size is exceeded in IP >(1500 bytes). Cell broadcast survives on the order of a hundred bytes. > >At what point do these discussions become irrelevant because the >messages should be shorter than that. > >Keith > > > > Encouraging warning originators to write to the point is a worthy goal, > > but arguably not something that can be enforced a-priori through > > technology. The whole point of CAP was to create an interoperability > > layer that was independent of technical constraints, in the awareness that > > different delivery mechanisms will impose their own limitations. (You can > > think of the CAP message as the Platonic ideal of the warning message, one > > which casts different shadows on different walls of the cave but has an > > essential nature common to them all.) > > > > > I'd also rather not provide space for each message to be front-ended by > > legal disclaimers saying that the sender accepts no responsibility for the > > information supplied, and is not responsible for any accident or damage > > accruing on the recipient by acting on this message. > > > > Not sure technology can defeat bureaucracy, but I share your desire. > > However, are we really talking about what size message will maximize > > warning effectiveness? Sounds to me like our true concern is how to fit > > standard messages into the constraints of a pre-existing technology. > > > > - Art > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca >_______________________________________________ >atoca mailing list >atoca@ietf.org >https://www.ietf.org/mailman/listinfo/atoca >_______________________________________________ >atoca mailing list >atoca@ietf.org >https://www.ietf.org/mailman/listinfo/atoca From bd2985@att.com Fri Sep 16 11:20:26 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0914A21F8C35 for ; Fri, 16 Sep 2011 11:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMFkwR8g74Ca for ; Fri, 16 Sep 2011 11:20:25 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0725421F8C30 for ; Fri, 16 Sep 2011 11:20:24 -0700 (PDT) X-Env-Sender: bd2985@att.com X-Msg-Ref: server-7.tower-119.messagelabs.com!1316197358!37390283!1 X-Originating-IP: [144.160.112.28] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14752 invoked from network); 16 Sep 2011 18:22:38 -0000 Received: from sbcsmtp3.sbc.com (HELO tlpi048.enaf.dadc.sbc.com) (144.160.112.28) by server-7.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Sep 2011 18:22:38 -0000 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GIMbXW030727; Fri, 16 Sep 2011 13:22:38 -0500 Received: from WABOTH9MSGHUB8B.ITServices.sbc.com (waboth9msghub8b.itservices.sbc.com [135.163.35.101]) by tlpi048.enaf.dadc.sbc.com (8.14.4/8.14.4) with ESMTP id p8GIMYBm030692; Fri, 16 Sep 2011 13:22:34 -0500 Received: from WABOTH9MSGUSR8B.ITServices.sbc.com ([169.254.2.17]) by WABOTH9MSGHUB8B.ITServices.sbc.com ([135.163.35.101]) with mapi id 14.01.0289.001; Fri, 16 Sep 2011 11:22:34 -0700 From: "DALY, BRIAN K" To: "James M. Polk" , "DRAGE, Keith (Keith)" , Art Botterell , "atoca@ietf.org" Thread-Topic: [atoca] Alert signing Thread-Index: AQHMc7MNPl9Z5lcp/kmE0Yrq8zh6zpVO/0aAgAAHyYCAAAWZgIAADaOAgAAbFXCAAR4RaIAAAEag Date: Fri, 16 Sep 2011 18:22:33 +0000 Message-ID: <95C5C7A891135E4685CCFAE997351F9623CFEC@WABOTH9MSGUSR8B.ITServices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> <201109161821.p8GIL8fp031325@mtv-core-4.cisco.com> In-Reply-To: <201109161821.p8GIL8fp031325@mtv-core-4.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 18:20:26 -0000 Hard to keep track, but I think it might have been Keith that made that com= ment? -------- Brian K. Daly Director, Core Network & Govn't/Regulatory Standards AT&T Services, Inc. +1.425.580.6873 brian.k.daly@att.com Rethink Possible -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Friday, September 16, 2011 11:21 AM To: DALY, BRIAN K; DRAGE, Keith (Keith); Art Botterell; atoca@ietf.org Subject: Re: [atoca] Alert signing Brian IP does NOT have an MTU of 1500. I believe you are thinking of the IEEE 802.3 Ethernet MTU only here. James At 08:25 PM 9/15/2011, DALY, BRIAN K wrote: >" Did the research come up with any input as to what was enough,=20 >before people ignored it. People are talking about fragmentation,=20 >which doesn't even become an issue until MTU size is exceeded in IP=20 >(1500 bytes). Cell broadcast survives on the order of a hundred bytes." > >-------- >Brian K. Daly >Director, Core Network & Govn't/Regulatory Standards >AT&T Services, Inc. >+1.425.580.6873 >brian.k.daly@att.com > >Rethink Possible > > >-----Original Message----- >From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On=20 >Behalf Of DRAGE, Keith (Keith) >Sent: Thursday, September 15, 2011 9:40 AM >To: Art Botterell; atoca@ietf.org >Subject: Re: [atoca] Alert signing > >See below > > > -----Original Message----- > > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf = Of > > Art Botterell > > Sent: 15 September 2011 16:52 > > To: atoca@ietf.org > > Subject: Re: [atoca] Alert signing > > > > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: > > > > > I would argue that at least short messages does create a constraint o= n > > the initiator to actually draft meaningful messages in a concise > > imperative form rather than finally getting around to the real message = in > > page 5 of a sent document. > > > > The design of CAP was based on a considerable body of social science > > research regarding warning effectiveness. While brevity is generally a > > virtue, it turns out that it's possible to make a warning message too > > brief, at least if actually eliciting protective action among the > > recipients is the goal. In particular, a simple "imperative" message > > without context will generally not result in action. (E.g., if I merel= y > > shouted "RUN, NOW!" would you run immediately, or would you ask me "Why= ? > > In which direction? How far? And does this really apply to me?") > > >Agreed. > >Did the research come up with any input as to what was enough,=20 >before people ignored it. People are talking about fragmentation,=20 >which doesn't even become an issue until MTU size is exceeded in IP=20 >(1500 bytes). Cell broadcast survives on the order of a hundred bytes. > >At what point do these discussions become irrelevant because the=20 >messages should be shorter than that. > >Keith > > > > Encouraging warning originators to write to the point is a worthy goal, > > but arguably not something that can be enforced a-priori through > > technology. The whole point of CAP was to create an interoperability > > layer that was independent of technical constraints, in the awareness t= hat > > different delivery mechanisms will impose their own limitations. (You = can > > think of the CAP message as the Platonic ideal of the warning message, = one > > which casts different shadows on different walls of the cave but has an > > essential nature common to them all.) > > > > > I'd also rather not provide space for each message to be front-ended = by > > legal disclaimers saying that the sender accepts no responsibility for = the > > information supplied, and is not responsible for any accident or damage > > accruing on the recipient by acting on this message. > > > > Not sure technology can defeat bureaucracy, but I share your desire. > > However, are we really talking about what size message will maximize > > warning effectiveness? Sounds to me like our true concern is how to fi= t > > standard messages into the constraints of a pre-existing technology. > > > > - Art > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca >_______________________________________________ >atoca mailing list >atoca@ietf.org >https://www.ietf.org/mailman/listinfo/atoca >_______________________________________________ >atoca mailing list >atoca@ietf.org >https://www.ietf.org/mailman/listinfo/atoca From jmpolk@cisco.com Fri Sep 16 11:31:54 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0EF21F8B08 for ; Fri, 16 Sep 2011 11:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.316 X-Spam-Level: X-Spam-Status: No, score=-103.316 tagged_above=-999 required=5 tests=[AWL=-0.717, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvrhMKzKxS8A for ; Fri, 16 Sep 2011 11:31:54 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5121F8B01 for ; Fri, 16 Sep 2011 11:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5906; q=dns/txt; s=iport; t=1316198049; x=1317407649; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=N/solNaE3qTKY7/bN6Le09fs9agEgTT074MwUHzM6yQ=; b=YbTOQGRqqE7WU99ny7sWlCCr7s4AFXKOBx/llN1uWea/hpq+aIv1Ty6h mPf+uC0SXaq5Dm1dBxSWXPsD/Ki1WhkcHAZB7BtU77YxVnYt3YM2F1KZu mPWhfurbueEQbqWdknCKyuU22ZyHDXUamIw8Bt84XAuH0DoeAh8OEQR1A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAAMWVc06rRDoI/2dsb2JhbAA/A5hhjn53gVMBAQEBAwEBAQ8BJQI0FwQHBBEEAQEBHgkHGQ4fCQMFBgESIodZlXwBnjCDa4ItYASHb50l X-IronPort-AV: E=Sophos;i="4.68,394,1312156800"; d="scan'208";a="2604670" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 16 Sep 2011 18:34:08 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8GIY7tA026957; Fri, 16 Sep 2011 18:34:07 GMT Message-Id: <201109161834.p8GIY7tA026957@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Sep 2011 13:34:06 -0500 To: "DALY, BRIAN K" , "DRAGE, Keith (Keith)" , Art Botterell , "atoca@ietf.org" From: "James M. Polk" In-Reply-To: <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITS ervices.sbc.com> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 18:31:54 -0000 At 08:25 PM 9/15/2011, DALY, BRIAN K wrote: >Bottom line - people don't want to have to scroll through multiple >screens to read information - they want to be told "to the point" >with a minimal amount of scrolling through pages of text. was that study performed before the evidence of the far greater penetration of smart devices than everyone expected? >The input obtained from that study is one of the drivers that >limited a CMAS alert message to 90 characters (although there was >technical consideration as well), PLUS there was research that >stated to be most effective the alert message needs to contain the >following information, in this order: > >1. What's happening (e.g. Tornado Warning) >2. Where it is happening (e.g. "in your/this area") >3. What action to take (e.g., "take shelter now") >4. How long it will be happening (e.g. "until 7pm") >5. Who authorized this/sent this (e.g., "NWS") (following up to the above question) In other words, I have no problems sending or receiving the 5 bullets you have listed. What I have a problem with is only receiving that information. I know "thems fightin` words" with you, but the lowest common denominator theory or plan doesn't have to limit all of what's sent. For example, depending on when this study was done (and almost regardless of when this study was done - unless in the last 6 months), no one would have predicted that so many iPhones, Androids or Blackberry phones would be on the market and fully utilized for the rich media capabilities. In other words, having all 5 bullets on the first page of a multipage alert is great. The subsequent pages are thrown away by those devices that don't understand them - but they are tabbed windows to those that can. For example, I'd like to: - take your #3 and have it paint a map of where the shelters are. - take your #2 and show a video of the affected area. These require URLs and some geolocation to be utilized, because "in your area" might be the city of NY, or Chicago or LA - each of which might not be completely affected by whatever is happening. No need to panic folks that don't need to be panicked, right? Just some thoughts... James >-------- >Brian K. Daly >Director, Core Network & Govn't/Regulatory Standards >AT&T Services, Inc. >+1.425.580.6873 >brian.k.daly@att.com > >Rethink Possible > > >-----Original Message----- >From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On >Behalf Of DRAGE, Keith (Keith) >Sent: Thursday, September 15, 2011 9:40 AM >To: Art Botterell; atoca@ietf.org >Subject: Re: [atoca] Alert signing > >See below > > > -----Original Message----- > > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > > Art Botterell > > Sent: 15 September 2011 16:52 > > To: atoca@ietf.org > > Subject: Re: [atoca] Alert signing > > > > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: > > > > > I would argue that at least short messages does create a constraint on > > the initiator to actually draft meaningful messages in a concise > > imperative form rather than finally getting around to the real message in > > page 5 of a sent document. > > > > The design of CAP was based on a considerable body of social science > > research regarding warning effectiveness. While brevity is generally a > > virtue, it turns out that it's possible to make a warning message too > > brief, at least if actually eliciting protective action among the > > recipients is the goal. In particular, a simple "imperative" message > > without context will generally not result in action. (E.g., if I merely > > shouted "RUN, NOW!" would you run immediately, or would you ask me "Why? > > In which direction? How far? And does this really apply to me?") > > >Agreed. > >Did the research come up with any input as to what was enough, >before people ignored it. People are talking about fragmentation, >which doesn't even become an issue until MTU size is exceeded in IP >(1500 bytes). Cell broadcast survives on the order of a hundred bytes. > >At what point do these discussions become irrelevant because the >messages should be shorter than that. > >Keith > > > > Encouraging warning originators to write to the point is a worthy goal, > > but arguably not something that can be enforced a-priori through > > technology. The whole point of CAP was to create an interoperability > > layer that was independent of technical constraints, in the awareness that > > different delivery mechanisms will impose their own limitations. (You can > > think of the CAP message as the Platonic ideal of the warning message, one > > which casts different shadows on different walls of the cave but has an > > essential nature common to them all.) > > > > > I'd also rather not provide space for each message to be front-ended by > > legal disclaimers saying that the sender accepts no responsibility for the > > information supplied, and is not responsible for any accident or damage > > accruing on the recipient by acting on this message. > > > > Not sure technology can defeat bureaucracy, but I share your desire. > > However, are we really talking about what size message will maximize > > warning effectiveness? Sounds to me like our true concern is how to fit > > standard messages into the constraints of a pre-existing technology. > > > > - Art > > _______________________________________________ > > atoca mailing list > > atoca@ietf.org > > https://www.ietf.org/mailman/listinfo/atoca >_______________________________________________ >atoca mailing list >atoca@ietf.org >https://www.ietf.org/mailman/listinfo/atoca >_______________________________________________ >atoca mailing list >atoca@ietf.org >https://www.ietf.org/mailman/listinfo/atoca From Hannes.Tschofenig@gmx.net Sat Sep 17 11:17:11 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97C21F85FF for ; Sat, 17 Sep 2011 11:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x40Kd3kCsQbG for ; Sat, 17 Sep 2011 11:17:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 45DED21F85CE for ; Sat, 17 Sep 2011 11:17:10 -0700 (PDT) Received: (qmail invoked by alias); 17 Sep 2011 18:19:26 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp017) with SMTP; 17 Sep 2011 20:19:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+P6GUg5Z6PoCc+OpQ90ajQFR2sNZ8jbQZ00CDA32 /tGCbkQenkmp/Y From: Hannes Tschofenig Content-Type: multipart/alternative; boundary=Apple-Mail-1-821433238 Date: Sat, 17 Sep 2011 21:19:25 +0300 Message-Id: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> To: atoca@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Sep 2011 18:17:12 -0000 --Apple-Mail-1-821433238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all,=20 based on the discussions from the last IETF meeting I have written a = short section for the current requirements/framework/terminology = document. I would like to know whether it captures the discussions = appropriately or where additional text is needed.=20 ------ 3. Alert Delivery Architecture Section 1 describes the basic two steps that are involved with the alert message handling, namely subscription and alert delivery. From an architectural point of view there are, however, a few variations possible depending on the characteristics of the subscription process and the style of message delivery. This section offers more details on the communication architecture and highlights the necessary standardization actions. We start our description with the so-called "school closed" example where school authorities send alerts to all parents to notify theim about the fact that their children cannot attend school. Parents subscribe to these events when their children start attending the school and unsubscribe when they are finished with a particular school. The subscription procedures establishes a closed communication group and authorization is also taken off as part of this process. Typically, alert messages stay within the closed group and are not shared with others and alert message delivery is point- to-point with whatever communication protocol is most suitable. This also means that there the alerts reach those who have subscribed rather than those who are in the vicinity of the school. The number of alert message Recipients is typically rather small, in the order of hundreds to several thousands. A variation of the "school closed" example is an explicit subscription model where no closed group pattern exists. Consider a traveler who would like to receive weather alerts about a specific geographical region. He may have to manually search for how to subscribe to alerts for the desired region, potentially looking a different subscription points for different types of alerts. As an automated version of this procedure some form of discovery may help to find these subscription servers. The approach described in [I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery such alert subscription servers. The number of alert message Recipients is larger than in the previous example but will typically stay below the millions. With the next category we move to a scenario where large number of Recipients shall be notified but the subscription itself is implicit, as it is the case when persons are within a specific region that can easily be reached by making use of broadcast link layer technologies. The placement of the actors from Figure 1 is thereby important. When a Sender distributes the alert it distributes it already to Relays within the geographically affected area. Those Relays are located within Internet Service Providers so that multicast and broadcast communication protocols can be utilized for efficient distribution to a large number of Recipients. When the alert message delivery is accomplished at the networking layer then various requirements, such as the ability to deal with NAT and firewall traversal, have to be met by such a protocol. The number of alert message Recipients is very large, potentially in the millions. Next, we move to a model where the alert distribution uses a broadcast network layer distribution mechanism but subscription to the alerts is explicit. Figure 2 shows the architecture. The LoST Forest Guide ensures that there is a way for Reivers to discovery local alert subscription servers. The individual LoST servers thereby know about these authoritative servers and redirect discovery requests to the appropriate LoST server in case the answer cannot be provided for a request, similar to how LoST is used in the ECRIT emergency services architecture [RFC5582]. Once a Receiver had discovered a local subscription server it subscribes to it (with additional information about the type of alert it is interested in). As a response, it will receive information about the security credential the relay is going to use for subsequent alert delivery. When an Author creates an alert for distribution the affected region will be indicated and so the alert will be sent to a relay within the realm of the local alert distribution server and a notification will be sent to all the subscribed Receivers. The local Relay and the local alert subscription server will therefore cooperate in the handling of the alerts. ,-----. / Lost \ +-------( Server )---------+ Forest ,-----. \ A / ,-----. Guide / LoST \ `-----' / LoST \ ( Server ) ( Server ) \ D / ,-----. \ B / `-----' / LoST \ `-----' +-------( Server )---------+ \ B / `-----' ,''''''''''''''''''''''''\ : | Local ,------. | : | Alert | Local| | : ................... | Subscription | Relay|.|..: Alert | +------+ Author | | Server `......'-+-------------------------+-|Sender| O | | | | Notification | | | /|\ | '`'''''''''''''''''+'''''' | +------+ / \ | | Alert | `-----------------' Subscr. +---------+ | | Notification | | | | ..................... | +------+ Recipient| | |Recvr | O | | | | /|\ | | +------+ / \ | `-------------------' Figure 2: Architectural Model for the Broadcast Alert Delivery Mechanism with Explicit Subscription ------ The not-yet-submitted version of the document, which contains the above = writeup, can be found here:=20 = https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-frame= work/draft-ietf-atoca-requirements-02.txt Ciao Hannes --Apple-Mail-1-821433238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = all,

based on the discussions from the last IETF = meeting I have written a short section for the current = requirements/framework/terminology document. I = would like to know whether it captures the discussions appropriately or = where additional text is needed.

------

3. Alert Delivery = Architecture

Section 1 describes the basic two steps = that are involved with the
alert message handling, = namely subscription and alert delivery. From
an = architectural point of view there are, however, a few = variations
possible depending on the characteristics of = the subscription process
and the style of message = delivery. This section offers more details
on the = communication architecture and highlights the necessary
= standardization actions.

We start our = description with the so-called "school closed" example
= where school authorities send alerts to all parents to notify = theim
about the fact that their children cannot attend = school. Parents
subscribe to these events when = their children start attending the
school and = unsubscribe when they are finished with a particular
= school. The subscription procedures establishes a = closed
communication group and authorization is also = taken off as part of
this process. Typically, = alert messages stay within the closed group
and are not = shared with others and alert message delivery is point-
= to-point with whatever communication protocol is most suitable. = This
also means that there the alerts reach those = who have subscribed
rather than those who are in the = vicinity of the school. The number
of alert = message Recipients is typically rather small, in the order
= of hundreds to several thousands.

A variation = of the "school closed" example is an explicit
= subscription model where no closed group pattern exists. = Consider a
traveler who would like to receive = weather alerts about a specific
geographical region. = He may have to manually search for how to
= subscribe to alerts for the desired region, potentially looking = a
different subscription points for different types of = alerts. As an
automated version of this procedure = some form of discovery may help
to find these = subscription servers. The approach described in
= [I-D.rosen-ecrit-lost-early-warning] is one possible way to = discovery
such alert subscription servers. The = number of alert message
Recipients is larger than in the = previous example but will typically
stay below the = millions.

With the next category we move to a = scenario where large number of
Recipients shall be = notified but the subscription itself is implicit,
as it = is the case when persons are within a specific region that can
= easily be reached by making use of broadcast link layer = technologies.
The placement of the actors from Figure 1 = is thereby important. When
a Sender distributes = the alert it distributes it already to Relays
within the = geographically affected area. Those Relays are located
= within Internet Service Providers so that multicast and = broadcast
communication protocols can be utilized for = efficient distribution to
a large number of Recipients. = When the alert message delivery is
accomplished at = the networking layer then various requirements, such
as = the ability to deal with NAT and firewall traversal, have to = be
met by such a protocol. The number of alert = message Recipients is
very large, potentially in the = millions.

Next, we move to a model where the alert = distribution uses a
broadcast network layer distribution = mechanism but subscription to
the alerts is explicit. = Figure 2 shows the architecture. The LoST
= Forest Guide ensures that there is a way for Reivers to = discovery
local alert subscription servers. The = individual LoST servers
thereby know about these = authoritative servers and redirect discovery
requests to = the appropriate LoST server in case the answer cannot be
= provided for a request, similar to how LoST is used in the = ECRIT
emergency services architecture = [RFC5582].

Once a Receiver had discovered a local = subscription server it
subscribes to it (with additional = information about the type of alert
it is interested = in). As a response, it will receive information
= about the security credential the relay is going to use = for
subsequent alert delivery.

When = an Author creates an alert for distribution the affected = region
will be indicated and so the alert will be sent = to a relay within the
realm of the local alert = distribution server and a notification will
be sent to = all the subscribed Receivers. The local Relay and the
= local alert subscription server will therefore cooperate in = the
handling of the alerts.

= = ,-----.
= / Lost \
= +-------( = Server )---------+
Forest ,-----. = \ A / ,-----.
= Guide / LoST \ `-----' = / LoST \
= ( Server ) = ( Server )
= \ D / ,-----. \ = B /
= `-----' / LoST \ = `-----'
= +-------( Server )---------+
= \ = B /
= `-----'
= ,''''''''''''''''''''''''\ :
| Local = ,------. | :
| Alert = | Local| | : = ...................
| = Subscription | Relay|.|..: Alert = | +------+ Author |
| Server = `......'-+-------------------------+-|Sender| = O |
| = | | = Notification | | | /|\ = |
'`'''''''''''''''''+'''''' = | +------+ = / \ |
| = Alert | = = `-----------------'
Subscr. +---------+
= | | Notification
| = |
| |
= .....................
| +------+ Recipient|
| |Recvr = | O |
| | | = /|\ |
| +------+ / \ = |
`-------------------'

= Figure 2: Architectural Model for the Broadcast Alert Delivery
= Mechanism = with Explicit Subscription

------

The not-yet-submitted = version of the document, which contains the above writeup, can be found = here:
https://github.com/hann= estschofenig/tschofenig-ids/blob/master/atoca-framework/draft-ietf-atoca-r= equirements-02.txt

Ciao
Hannes

= --Apple-Mail-1-821433238-- From Hannes.Tschofenig@gmx.net Sun Sep 18 13:07:19 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ED021F869E for ; Sun, 18 Sep 2011 13:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By0WYRK2V9EU for ; Sun, 18 Sep 2011 13:07:18 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2350821F8540 for ; Sun, 18 Sep 2011 13:07:13 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2011 20:09:34 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp023) with SMTP; 18 Sep 2011 22:09:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19v9jQTdT5vEgnV76hrVw9mCtP031h5L73eRf1jOF hXFsdMkSaKby+H Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig X-Priority: 3 In-Reply-To: Date: Sun, 18 Sep 2011 23:09:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com><8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com><27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com><9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> To: Carl Reed X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 20:07:19 -0000 Hi Carl,=20 I just read this message and it relates to the message I sent today to = the mailing list about scope of the work.=20 GeoRSS is, if I understood it correctly, a mechanism for using alerts in = RSS feeds. While this is a perfectly fine idea it falls into the = category of what some people consider "out of scope for this group and = has been specified, implemented and deployed already". So, there isn't a = need to specify it again. Right?=20 I have to look into GeoSMS to understand what it does but I guess from = the name that it uses SMS as a way to carry information. In the IETF we = focus on IP, as you know.=20 On Sep 15, 2011, at 6:45 PM, Carl Reed wrote: > Sorry, I just want to understand why CAP only. In the OGC community, = current efforts have typically abstracted the alert service architecture = such that the publish/subscribe function for alerts is independent of = the alert format. In this way, CAP, SMS, GeoSMS, GeoRSS, or whatever = format is required or desired can be accommodated. Ciao Hannes From hannes.tschofenig@gmx.net Sun Sep 18 13:08:22 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB221F86A1 for ; Sun, 18 Sep 2011 13:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibaFGeropTSV for ; Sun, 18 Sep 2011 13:08:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0C81521F8540 for ; Sun, 18 Sep 2011 13:08:21 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2011 20:10:37 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp007) with SMTP; 18 Sep 2011 22:10:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19gBQ0QAK9gsbU37zHlNAXTj3Y9sPLJnL8Ck6/8dR AFq70mNNo2hJS4 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 18 Sep 2011 23:10:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3004D682-22F8-4887-9FD6-A41AB3F0EC57@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 20:08:23 -0000 How would this work for a broadcast message delivery (in comparison to a = point-to-point message exchange where one could imagine things like Path = MTU discovery etc.)?=20 On Sep 15, 2011, at 10:19 PM, Richard L. Barnes wrote: > Yeah, I think that all this really argues for is having a = fragmentation layer over UDP, plus maybe using GZIPped CAP. From hannes.tschofenig@gmx.net Sun Sep 18 13:14:27 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355DD21F8540 for ; Sun, 18 Sep 2011 13:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.647 X-Spam-Level: X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri2Lp5269a2W for ; Sun, 18 Sep 2011 13:14:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0DC1921F84DB for ; Sun, 18 Sep 2011 13:14:25 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2011 20:16:46 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp032) with SMTP; 18 Sep 2011 22:16:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+din595a+d5qXcDpUNhMo7NABM/N1uVUG50JdM5H 6rjFqU0tu+fKNz Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 18 Sep 2011 23:16:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4681930E-33DE-4F2F-AF26-AE6DA4FD22F8@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "atoca@ietf.org" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 20:14:27 -0000 Hi Keith,=20 I am looking forward to see this text input.=20 I am curious how this text would look like and provides guidance on how = to fit a CAP message in an UDP datagram.=20 I also don't think that the charter of the group ever envisioned that = the group would specify how the content of the alert can be restricted = to a specific size.=20 Ciao Hannes On Sep 16, 2011, at 2:00 PM, DRAGE, Keith (Keith) wrote: > I suggest that in some descriptive part of some potential ATOCA = document we capture some of this.=20 >=20 > Keith >=20 >> -----Original Message----- >> From: DALY, BRIAN K [mailto:bd2985@att.com] >> Sent: 16 September 2011 02:26 >> To: DRAGE, Keith (Keith); Art Botterell; atoca@ietf.org >> Subject: RE: [atoca] Alert signing >>=20 >> " Did the research come up with any input as to what was enough, = before >> people ignored it. People are talking about fragmentation, which = doesn't >> even become an issue until MTU size is exceeded in IP (1500 bytes). = Cell >> broadcast survives on the order of a hundred bytes." >>=20 >> Actually the FCC's Commercial Mobile System Alert Advisory Committee = spend >> considerable time looking at the issue of "how long should a message = be" >> especially when rendered on a mobile device screen AND accounted for = the >> needs of individuals with disabilities. >>=20 >> Bottom line - people don't want to have to scroll through multiple = screens >> to read information - they want to be told "to the point" with a = minimal >> amount of scrolling through pages of text. >>=20 >> The input obtained from that study is one of the drivers that limited = a >> CMAS alert message to 90 characters (although there was technical >> consideration as well), PLUS there was research that stated to be = most >> effective the alert message needs to contain the following = information, in >> this order: >>=20 >> 1. What's happening (e.g. Tornado Warning) >> 2. Where it is happening (e.g. "in your/this area") >> 3. What action to take (e.g., "take shelter now") >> 4. How long it will be happening (e.g. "until 7pm") >> 5. Who authorized this/sent this (e.g., "NWS") >>=20 >> -------- >> Brian K. Daly >> Director, Core Network & Govn't/Regulatory Standards >> AT&T Services, Inc. >> +1.425.580.6873 >> brian.k.daly@att.com >>=20 >> Rethink Possible >>=20 >>=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of >> DRAGE, Keith (Keith) >> Sent: Thursday, September 15, 2011 9:40 AM >> To: Art Botterell; atoca@ietf.org >> Subject: Re: [atoca] Alert signing >>=20 >> See below >>=20 >>> -----Original Message----- >>> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf >> Of >>> Art Botterell >>> Sent: 15 September 2011 16:52 >>> To: atoca@ietf.org >>> Subject: Re: [atoca] Alert signing >>>=20 >>> On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: >>>=20 >>>> I would argue that at least short messages does create a constraint = on >>> the initiator to actually draft meaningful messages in a concise >>> imperative form rather than finally getting around to the real = message >> in >>> page 5 of a sent document. >>>=20 >>> The design of CAP was based on a considerable body of social science >>> research regarding warning effectiveness. While brevity is = generally a >>> virtue, it turns out that it's possible to make a warning message = too >>> brief, at least if actually eliciting protective action among the >>> recipients is the goal. In particular, a simple "imperative" = message >>> without context will generally not result in action. (E.g., if I = merely >>> shouted "RUN, NOW!" would you run immediately, or would you ask me = "Why? >>> In which direction? How far? And does this really apply to me?") >>>=20 >> Agreed. >>=20 >> Did the research come up with any input as to what was enough, before >> people ignored it. People are talking about fragmentation, which = doesn't >> even become an issue until MTU size is exceeded in IP (1500 bytes). = Cell >> broadcast survives on the order of a hundred bytes. >>=20 >> At what point do these discussions become irrelevant because the = messages >> should be shorter than that. >>=20 >> Keith >>=20 >>=20 >>> Encouraging warning originators to write to the point is a worthy = goal, >>> but arguably not something that can be enforced a-priori through >>> technology. The whole point of CAP was to create an = interoperability >>> layer that was independent of technical constraints, in the = awareness >> that >>> different delivery mechanisms will impose their own limitations. = (You >> can >>> think of the CAP message as the Platonic ideal of the warning = message, >> one >>> which casts different shadows on different walls of the cave but has = an >>> essential nature common to them all.) >>>=20 >>>> I'd also rather not provide space for each message to be = front-ended >> by >>> legal disclaimers saying that the sender accepts no responsibility = for >> the >>> information supplied, and is not responsible for any accident or = damage >>> accruing on the recipient by acting on this message. >>>=20 >>> Not sure technology can defeat bureaucracy, but I share your desire. >>> However, are we really talking about what size message will maximize >>> warning effectiveness? Sounds to me like our true concern is how to = fit >>> standard messages into the constraints of a pre-existing technology. >>>=20 >>> - Art >>> _______________________________________________ >>> atoca mailing list >>> atoca@ietf.org >>> https://www.ietf.org/mailman/listinfo/atoca >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From hannes.tschofenig@gmx.net Sun Sep 18 13:25:35 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203D521F889A for ; Sun, 18 Sep 2011 13:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2vqpvrF2cvb for ; Sun, 18 Sep 2011 13:25:34 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B885E21F8888 for ; Sun, 18 Sep 2011 13:25:33 -0700 (PDT) Received: (qmail invoked by alias); 18 Sep 2011 20:27:53 -0000 Received: from a88-115-210-23.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.210.23] by mail.gmx.net (mp070) with SMTP; 18 Sep 2011 22:27:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX184KmV4fFs4rqzQVTISoXUSOozBVqsYbRsNPmTNRK VNYoLA63YPO75W Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <201109161834.p8GIY7tA026957@mtv-core-3.cisco.com> Date: Sun, 18 Sep 2011 23:27:50 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F0321D6-DFB8-4E52-B05F-1A41C28A6292@gmx.net> References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <79C52F44-6971-4F4D-BCE3-CB301F263BA4@incident.com> <95C5C7A891135E4685CCFAE997351F962369C1@WABOTH9MSGUSR8B.ITServices.sbc.com> <201109161834.p8GIY7tA026957@mtv-core-3.cisco.com> To: James M. Polk X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "atoca@ietf.org" Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 20:25:35 -0000 Hi James,=20 There are various reasons for the increased message size, namely=20 * cryptographic protection (xml digital signature in case of CAP, the = original discussion starter) * encoding (XML encoding, JSON, ASN.1, etc.) * information being sent overall (this is what many discussed here in = this thread although it is not really up to us to decide anyway) * multi-media content (we had spoken about this during the charter = discussion) * content in different languages=20 With a point-to-point delivery the size of the message is not = necessarily a problem (at least not from the transport protocol with = respect to fragmentation) since one could easily make use of TCP, for = example. An RSS feed does this and so does SIP/XMPP.=20 The problem with these protocols is that they are not suitable for mass = delivery in the sense we discussed it and how many had anticipated these = things to work (namely as a broadcast/multicast UDP datagram sent to end = hosts).=20 Brian had provided us in the past already with information about the = design decisions for CMAS and that's simply the decisions they had = taken. The requirements to support devices available in the field and = different technology puts constraints on their solution. I believe we = should accept that.=20 Ciao Hannes On Sep 16, 2011, at 9:34 PM, James M. Polk wrote: > At 08:25 PM 9/15/2011, DALY, BRIAN K wrote: >=20 > >=20 >=20 >=20 >> Bottom line - people don't want to have to scroll through multiple = screens to read information - they want to be told "to the point" with a = minimal amount of scrolling through pages of text. >=20 > was that study performed before the evidence of the far greater = penetration of smart devices than everyone expected? >=20 >=20 >> The input obtained from that study is one of the drivers that limited = a CMAS alert message to 90 characters (although there was technical = consideration as well), PLUS there was research that stated to be most = effective the alert message needs to contain the following information, = in this order: >>=20 >> 1. What's happening (e.g. Tornado Warning) >> 2. Where it is happening (e.g. "in your/this area") >> 3. What action to take (e.g., "take shelter now") >> 4. How long it will be happening (e.g. "until 7pm") >> 5. Who authorized this/sent this (e.g., "NWS") >=20 > (following up to the above question) >=20 > In other words, I have no problems sending or receiving the 5 bullets = you have listed. What I have a problem with is only receiving that = information. I know "thems fightin` words" with you, but the lowest = common denominator theory or plan doesn't have to limit all of what's = sent. >=20 > For example, depending on when this study was done (and almost = regardless of when this study was done - unless in the last 6 months), = no one would have predicted that so many iPhones, Androids or Blackberry = phones would be on the market and fully utilized for the rich media = capabilities. In other words, having all 5 bullets on the first page of = a multipage alert is great. The subsequent pages are thrown away by = those devices that don't understand them - but they are tabbed windows = to those that can. For example, I'd like to: >=20 > - take your #3 and have it paint a map of where the shelters are. > - take your #2 and show a video of the affected area. >=20 > These require URLs and some geolocation to be utilized, because "in = your area" might be the city of NY, or Chicago or LA - each of which = might not be completely affected by whatever is happening. No need to = panic folks that don't need to be panicked, right? >=20 > Just some thoughts... >=20 > James >=20 >=20 >> -------- >> Brian K. Daly >> Director, Core Network & Govn't/Regulatory Standards >> AT&T Services, Inc. >> +1.425.580.6873 >> brian.k.daly@att.com >>=20 >> Rethink Possible >>=20 >>=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of DRAGE, Keith (Keith) >> Sent: Thursday, September 15, 2011 9:40 AM >> To: Art Botterell; atoca@ietf.org >> Subject: Re: [atoca] Alert signing >>=20 >> See below >>=20 >> > -----Original Message----- >> > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of >> > Art Botterell >> > Sent: 15 September 2011 16:52 >> > To: atoca@ietf.org >> > Subject: Re: [atoca] Alert signing >> > >> > On Sep 15, 2011, at 8:31 AM, DRAGE, Keith (Keith) wrote: >> > >> > > I would argue that at least short messages does create a = constraint on >> > the initiator to actually draft meaningful messages in a concise >> > imperative form rather than finally getting around to the real = message in >> > page 5 of a sent document. >> > >> > The design of CAP was based on a considerable body of social = science >> > research regarding warning effectiveness. While brevity is = generally a >> > virtue, it turns out that it's possible to make a warning message = too >> > brief, at least if actually eliciting protective action among the >> > recipients is the goal. In particular, a simple "imperative" = message >> > without context will generally not result in action. (E.g., if I = merely >> > shouted "RUN, NOW!" would you run immediately, or would you ask me = "Why? >> > In which direction? How far? And does this really apply to me?") >> > >> Agreed. >>=20 >> Did the research come up with any input as to what was enough, before = people ignored it. People are talking about fragmentation, which doesn't = even become an issue until MTU size is exceeded in IP (1500 bytes). Cell = broadcast survives on the order of a hundred bytes. >>=20 >> At what point do these discussions become irrelevant because the = messages should be shorter than that. >>=20 >> Keith >>=20 >>=20 >> > Encouraging warning originators to write to the point is a worthy = goal, >> > but arguably not something that can be enforced a-priori through >> > technology. The whole point of CAP was to create an = interoperability >> > layer that was independent of technical constraints, in the = awareness that >> > different delivery mechanisms will impose their own limitations. = (You can >> > think of the CAP message as the Platonic ideal of the warning = message, one >> > which casts different shadows on different walls of the cave but = has an >> > essential nature common to them all.) >> > >> > > I'd also rather not provide space for each message to be = front-ended by >> > legal disclaimers saying that the sender accepts no responsibility = for the >> > information supplied, and is not responsible for any accident or = damage >> > accruing on the recipient by acting on this message. >> > >> > Not sure technology can defeat bureaucracy, but I share your = desire. >> > However, are we really talking about what size message will = maximize >> > warning effectiveness? Sounds to me like our true concern is how = to fit >> > standard messages into the constraints of a pre-existing = technology. >> > >> > - Art >> > _______________________________________________ >> > atoca mailing list >> > atoca@ietf.org >> > https://www.ietf.org/mailman/listinfo/atoca >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rbarnes@bbn.com Sun Sep 18 16:38:42 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4566621F86C1 for ; Sun, 18 Sep 2011 16:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.603 X-Spam-Level: X-Spam-Status: No, score=-106.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UxxR1deO4RP for ; Sun, 18 Sep 2011 16:38:41 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0EE21F84C3 for ; Sun, 18 Sep 2011 16:38:41 -0700 (PDT) Received: from [128.89.254.51] (port=51663 helo=[192.168.1.3]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1R5Qyr-000F9v-6L; Sun, 18 Sep 2011 19:41:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <3004D682-22F8-4887-9FD6-A41AB3F0EC57@gmx.net> Date: Sun, 18 Sep 2011 19:41:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F040D2C3ACB@SISPE7MB1.commscope.com> <8938089B-DB56-4D9B-9795-9F54FF007701@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE608FE5@SISPE7MB1.commscope.com> <9E63CBC6-76D9-4159-AA9E-C154278890C5@bbn.com> <27AFD040F6F8AA4193E0614E2E3AF9C910CE609498@SISPE7MB1.commscope.com> <351A99C8-EC5C-4982-A20C-8266BFA1C519@gmx.net> <70E3E594-61CF-42AF-AE7E-9CFD0A3A8F63@incident.com> <3004D682-22F8-4887-9FD6-A41AB3F0EC57@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1084) Cc: atoca@ietf.org Subject: Re: [atoca] Alert signing X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 23:38:42 -0000 In the case where broadcast is being used, I would expect the alert = server to have a pretty good idea of things like the MTU to endpoints. =20= Even when that's not true, the server can make a pretty good guess as to = the MTU. E.g., if you look at some of the ideas for "stateless TCP" = [1], the server just chops the message into 512-octet chunks and fires = them off to the client. (ISTM that 1024 would probably be small = enough.) Obviously, the more you fragment, the more risk there is that = a lost datagram will render an endpoint unable to receive the alert. = But you can overcome that with retransmission (especially if you buffer = received fragments -- though there's DOS risk there). Or, if you want = to get really fancy, with an erasure code [2]. To address one particular scenario where an alert server doesn't know = the MTU: If a broadcast recipient relays an alert to further downstream = recipients, it seems like it assumes responsibility for re-assembly of = the alert and proper fragmentation for downstream endpoints. --Richard [1] [2] On Sep 18, 2011, at 4:10 PM, Hannes Tschofenig wrote: > How would this work for a broadcast message delivery (in comparison to = a point-to-point message exchange where one could imagine things like = Path MTU discovery etc.)?=20 >=20 > On Sep 15, 2011, at 10:19 PM, Richard L. Barnes wrote: >=20 >> Yeah, I think that all this really argues for is having a = fragmentation layer over UDP, plus maybe using GZIPped CAP. >=20 From Martin.Thomson@commscope.com Sun Sep 18 17:13:03 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B0621F8B4B for ; Sun, 18 Sep 2011 17:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7Pp5eqlH0a1 for ; Sun, 18 Sep 2011 17:13:02 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id A94A921F8B46 for ; Sun, 18 Sep 2011 17:12:59 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-4f-4e7689986156 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 90.62.08855.899867E4; Sun, 18 Sep 2011 19:15:20 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.192.1; Sun, 18 Sep 2011 19:15:20 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 19 Sep 2011 08:15:16 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "atoca@ietf.org" Date: Mon, 19 Sep 2011 08:15:14 +0800 Thread-Topic: [Ecrit] Scope of the Work Thread-Index: Acx2IJfvP1DLZQtxQpCVE1nUwiTsZgAPb5IQAACw+7A= Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C508@SISPE7MB1.commscope.com> References: <0A1E418E-52B2-426A-B8B9-F0F35BBFA920@gmx.net> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C507@SISPE7MB1.commscope.com> In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C507@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [atoca] [Ecrit] Scope of the Work X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 00:13:03 -0000 This is a good question. Sent to the wrong WG :) If anyone has any thoughts on this topic, I'd be interested to hear them. (And then I did exactly the same thing...) On 2011-09-19 at 02:32:07, Hannes Tschofenig wrote: > Hi all, >=20 > in earlier discussions we had always listed the school shooting=20 > scenario as a use case to summarize a cluster of solutions that use=20 > existing protocols, such as XMPP or SIP, to convey the alerts in a=20 > point-to-point fashion (using a subscribe/notify paradigm). > A few of us had worked on these solutions, such as=20 > http://xmpp.org/extensions/xep-0127.html or=20 > http://tools.ietf.org/html/draft-rosen-sipping-cap-04. These writeups=20 > should give you more background about the characteristics of the=20 > provided solution (in case the scenario description isn't so good). >=20 > These solutions are not suitable for mass delivery (aka Tsunami=20 > warning > case) but work fine in various other use cases. I had a short writeup=20 > of the scenario in the architecture mail I distributed yesterday. >=20 > Now, in off-list discussions for the virtual interim meeting the=20 > question was raised whether this use case is something that should not=20 > be dealt with in the group but instead the focus be spent on the mass=20 > delivery. From a requirements point of view these two cases are=20 > obviously quite different and the mass delivery case would make use of=20 > multicast/broadcast delivery instead. >=20 > I would need feedback from the rest of the group. There are two=20 > choices, I believe: >=20 > 1) Focus on the mass alert delivery work, >=20 > 2) In addition to the mass delivery work also address the school=20 > shooting scenario (based on how I described it in my architectural=20 > writeup, see http://www.ietf.org/mail-=20 > archive/web/atoca/current/msg00536.html, that would lead to a > point-to- point alert delivery. >=20 > What would you prefer? >=20 > Ciao > Hannes From artbotterell@gmail.com Sun Sep 18 17:38:41 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B3621F8B19 for ; Sun, 18 Sep 2011 17:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+Y8sxy-WogM for ; Sun, 18 Sep 2011 17:38:40 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id F108221F8B1A for ; Sun, 18 Sep 2011 17:38:39 -0700 (PDT) Received: by yie12 with SMTP id 12so4560034yie.31 for ; Sun, 18 Sep 2011 17:41:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=+jtKFEjXcJ8BeU6QmervllCPCtt9nSKn1MnYAjUlZ4E=; b=FDX7k75qGHkk0WGEXyg4ZGrXvShMKCCtU6us2H5C955BI0h1aLeCuLfABZWd33hjD/ 2/pgjv3H0p4/Z25QpW/G7pCssMDpOueW/TvrJ/libwmZJx2NIfJHY71zKkUyY+bXQlB5 zmS8ecgwQuCYQzeS9UE4zRtiVD/2WfF/kW/XI= Received: by 10.68.17.198 with SMTP id q6mr3295994pbd.354.1316392860416; Sun, 18 Sep 2011 17:41:00 -0700 (PDT) Received: from [192.168.1.7] (99-182-125-96.lightspeed.frokca.sbcglobal.net. [99.182.125.96]) by mx.google.com with ESMTPS id i8sm1740643pbp.1.2011.09.18.17.40.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Sep 2011 17:40:58 -0700 (PDT) Sender: Art Botterell Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Art Botterell In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C508@SISPE7MB1.commscope.com> Date: Sun, 18 Sep 2011 17:40:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CBA3684-14EB-4D84-8B40-292B18084C42@incident.com> References: <0A1E418E-52B2-426A-B8B9-F0F35BBFA920@gmx.net> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C507@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C508@SISPE7MB1.commscope.com> To: atoca@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [atoca] [Ecrit] Scope of the Work X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 00:38:41 -0000 Let me just confess a feeling that we may have a shortfall of analysis = here. Particular use cases are valuable to the extent they reveal = underlying patterns that can then become generalized; otherwise we wind = up building single functions instead of flexible tools.. In this case, = what seems like a dichotomy may actually be a continuum, with the = use-cases we're considering being relatively near the opposite ends of a = spectrum, and with a variety of others lying between them. Anyway, perhaps the correct formulation isn't "mass" versus "school" so = much as broadly-targeted vs. narrowly targeted... or perhaps = attribute-constrained vs. list-constrained (where geography is one of a = variety of possible attributes that might inform the distribution of an = alert). In any event, most of the qualitative distinctions reflect = technology artifacts rather than different requirements. In particular, = list-driven approaches tend not to scale well due both to network = inefficiencies and the exponential cost of maintaining = large-yet-accurate lists. Ultimately, I think... and I believe I've said this before, so please = forgive the repetition... that what we're really looking at is a = relatively generic, albeit still unresolved, problem of multicasting, as = opposed to the scalability problems of a unicast approach. - Art On Sep 18, 2011, at 5:15 PM, Thomson, Martin wrote: > This is a good question. Sent to the wrong WG :) >=20 > If anyone has any thoughts on this topic, I'd be interested to hear = them. >=20 > (And then I did exactly the same thing...) >=20 > On 2011-09-19 at 02:32:07, Hannes Tschofenig wrote: >> Hi all, >>=20 >> in earlier discussions we had always listed the school shooting=20 >> scenario as a use case to summarize a cluster of solutions that use=20= >> existing protocols, such as XMPP or SIP, to convey the alerts in a=20 >> point-to-point fashion (using a subscribe/notify paradigm). >> A few of us had worked on these solutions, such as=20 >> http://xmpp.org/extensions/xep-0127.html or=20 >> http://tools.ietf.org/html/draft-rosen-sipping-cap-04. These writeups=20= >> should give you more background about the characteristics of the=20 >> provided solution (in case the scenario description isn't so good). >>=20 >> These solutions are not suitable for mass delivery (aka Tsunami=20 >> warning >> case) but work fine in various other use cases. I had a short writeup=20= >> of the scenario in the architecture mail I distributed yesterday. >>=20 >> Now, in off-list discussions for the virtual interim meeting the=20 >> question was raised whether this use case is something that should = not=20 >> be dealt with in the group but instead the focus be spent on the mass=20= >> delivery. =46rom a requirements point of view these two cases are=20 >> obviously quite different and the mass delivery case would make use = of=20 >> multicast/broadcast delivery instead. >>=20 >> I would need feedback from the rest of the group. There are two=20 >> choices, I believe: >>=20 >> 1) Focus on the mass alert delivery work, >>=20 >> 2) In addition to the mass delivery work also address the school=20 >> shooting scenario (based on how I described it in my architectural=20 >> writeup, see http://www.ietf.org/mail-=20 >> archive/web/atoca/current/msg00536.html, that would lead to a >> point-to- point alert delivery. >>=20 >> What would you prefer? >>=20 >> Ciao >> Hannes >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From Hannes.Tschofenig@gmx.net Mon Sep 19 00:19:10 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951BD21F8B03 for ; Mon, 19 Sep 2011 00:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.051 X-Spam-Level: X-Spam-Status: No, score=-102.051 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhJxgMZAQNM3 for ; Mon, 19 Sep 2011 00:19:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 24E5A21F86A0 for ; Mon, 19 Sep 2011 00:19:07 -0700 (PDT) Received: (qmail invoked by alias); 19 Sep 2011 07:21:29 -0000 Received: from unknown (EHLO [10.255.133.66]) [192.100.123.77] by mail.gmx.net (mp052) with SMTP; 19 Sep 2011 09:21:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+TQ0gZbOqT651KHhCoYAijW9JQXkbUmPQdF8IgAh a0ZaNdUCKT/fWA Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig In-Reply-To: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> Date: Mon, 19 Sep 2011 10:21:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> To: Hannes Tschofenig , atoca@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 07:19:10 -0000 Here is some feedback from Richard on my writeup sent off list earlier. = With his permission I share it with you: ----- The document only barely touches on the separation of distribution from = broadcast. The only spot I see it is in the separation of "Receiver" = from "recipient", which seems confusing. The document seems inordinately = focused on the "Message Handling System" ("distribution", in the = terminology I've been using), and doesn't really say anything about the = ultimate delivery ("broadcast"). ISTM that the situation should be = reversed. Given the abundant prior art in the distribution space -- and = the fact that it's overall an easier problem technically -- means we = don't have to say a whole lot here. Whereas the problems raised by the = broadcast protocol are numerous and subtle. Starting with the "school closed" case is less than convincing. The = more I think about it, the less I think we need to do anything about = that case. There are lots of existing technologies that meet the needs = of that case (SIP, Jabber, email); or at least, I don't recall having = heard an argument that they don't. Notwithstanding the above, the requirements are actually pretty OK. I = would assign them to slightly different parts of the architecture = (mainly as aspects of the broadcast protocol), and I think there need to = also be some security requirements, but it seems like they should = basically all be carried forward. ----- Ciao Hannes On Sep 17, 2011, at 9:19 PM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > based on the discussions from the last IETF meeting I have written a = short section for the current requirements/framework/terminology = document. I would like to know whether it captures the discussions = appropriately or where additional text is needed.=20 >=20 > ------ >=20 > 3. Alert Delivery Architecture >=20 > Section 1 describes the basic two steps that are involved with the > alert message handling, namely subscription and alert delivery. = From > an architectural point of view there are, however, a few variations > possible depending on the characteristics of the subscription = process > and the style of message delivery. This section offers more = details > on the communication architecture and highlights the necessary > standardization actions. >=20 > We start our description with the so-called "school closed" example > where school authorities send alerts to all parents to notify theim > about the fact that their children cannot attend school. Parents > subscribe to these events when their children start attending the > school and unsubscribe when they are finished with a particular > school. The subscription procedures establishes a closed > communication group and authorization is also taken off as part of > this process. Typically, alert messages stay within the closed = group > and are not shared with others and alert message delivery is point- > to-point with whatever communication protocol is most suitable. = This > also means that there the alerts reach those who have subscribed > rather than those who are in the vicinity of the school. The = number > of alert message Recipients is typically rather small, in the order > of hundreds to several thousands. >=20 > A variation of the "school closed" example is an explicit > subscription model where no closed group pattern exists. Consider = a > traveler who would like to receive weather alerts about a specific > geographical region. He may have to manually search for how to > subscribe to alerts for the desired region, potentially looking a > different subscription points for different types of alerts. As an > automated version of this procedure some form of discovery may help > to find these subscription servers. The approach described in > [I-D.rosen-ecrit-lost-early-warning] is one possible way to = discovery > such alert subscription servers. The number of alert message > Recipients is larger than in the previous example but will = typically > stay below the millions. >=20 > With the next category we move to a scenario where large number of > Recipients shall be notified but the subscription itself is = implicit, > as it is the case when persons are within a specific region that = can > easily be reached by making use of broadcast link layer = technologies. > The placement of the actors from Figure 1 is thereby important. = When > a Sender distributes the alert it distributes it already to Relays > within the geographically affected area. Those Relays are located > within Internet Service Providers so that multicast and broadcast > communication protocols can be utilized for efficient distribution = to > a large number of Recipients. When the alert message delivery is > accomplished at the networking layer then various requirements, = such > as the ability to deal with NAT and firewall traversal, have to be > met by such a protocol. The number of alert message Recipients is > very large, potentially in the millions. >=20 > Next, we move to a model where the alert distribution uses a > broadcast network layer distribution mechanism but subscription to > the alerts is explicit. Figure 2 shows the architecture. The LoST > Forest Guide ensures that there is a way for Reivers to discovery > local alert subscription servers. The individual LoST servers > thereby know about these authoritative servers and redirect = discovery > requests to the appropriate LoST server in case the answer cannot = be > provided for a request, similar to how LoST is used in the ECRIT > emergency services architecture [RFC5582]. >=20 > Once a Receiver had discovered a local subscription server it > subscribes to it (with additional information about the type of = alert > it is interested in). As a response, it will receive information > about the security credential the relay is going to use for > subsequent alert delivery. >=20 > When an Author creates an alert for distribution the affected = region > will be indicated and so the alert will be sent to a relay within = the > realm of the local alert distribution server and a notification = will > be sent to all the subscribed Receivers. The local Relay and the > local alert subscription server will therefore cooperate in the > handling of the alerts. >=20 >=20 > ,-----. > / Lost \ > +-------( Server )---------+ > Forest ,-----. \ A / ,-----. > Guide / LoST \ `-----' / LoST \ > ( Server ) ( Server ) > \ D / ,-----. \ B / > `-----' / LoST \ `-----' > +-------( Server )---------+ > \ B / > `-----' > ,''''''''''''''''''''''''\ : > | Local ,------. | : > | Alert | Local| | : = ................... > | Subscription | Relay|.|..: Alert | +------+ Author = | > | Server `......'-+-------------------------+-|Sender| O = | > | | | Notification | | | /|\ = | > '`'''''''''''''''''+'''''' | +------+ / \ = | > | Alert | = `-----------------' > Subscr. +---------+ > | | Notification > | | > | | > ..................... > | +------+ Recipient| > | |Recvr | O | > | | | /|\ | > | +------+ / \ | > `-------------------' >=20 > Figure 2: Architectural Model for the Broadcast Alert Delivery > Mechanism with Explicit Subscription >=20 > ------ >=20 > The not-yet-submitted version of the document, which contains the = above writeup, can be found here:=20 > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-frame= work/draft-ietf-atoca-requirements-02.txt >=20 > Ciao > Hannes >=20 From peter.sanders@one2many.eu Mon Sep 19 01:34:12 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED36C21F8B6C for ; Mon, 19 Sep 2011 01:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG+5dfmp97UH for ; Mon, 19 Sep 2011 01:34:11 -0700 (PDT) Received: from smtp.byte.nl (mx.c1.byte.nl [82.94.214.65]) by ietfa.amsl.com (Postfix) with ESMTP id A3FBA21F8B67 for ; Mon, 19 Sep 2011 01:34:10 -0700 (PDT) Received: from peters (unknown [92.65.238.116]) (Authenticated sender: onema004) by smtp.byte.nl (Postfix) with ESMTPA id 87AEE39D46; Mon, 19 Sep 2011 10:36:31 +0200 (CEST) From: "Peter Sanders" To: "'Hannes Tschofenig'" References: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> In-Reply-To: Date: Mon, 19 Sep 2011 10:36:33 +0200 Organization: one2many Message-ID: <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acx2nMZARwM0UoXmQlGvPhPxQ68CngABT68w Content-Language: nl Cc: atoca@ietf.org Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 08:34:13 -0000 Hi Hannes, I would support Richard's idea that the "school closed" example is not very convincing. One reason is that the alert is not location specific. It doesn't really matter where the school children or their parents are when the alert is transmitted. A second reason is that it is not clear that there is a sense of urgency here. Possibly the message is sent on the previous evening of the day when the school is closed. Regards, Peter -----Original Message----- From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: maandag 19 september 2011 9:21 To: Hannes Tschofenig; atoca@ietf.org Subject: Re: [atoca] Architecture Writeup Here is some feedback from Richard on my writeup sent off list earlier. With his permission I share it with you: ----- The document only barely touches on the separation of distribution from broadcast. The only spot I see it is in the separation of "Receiver" from "recipient", which seems confusing. The document seems inordinately focused on the "Message Handling System" ("distribution", in the terminology I've been using), and doesn't really say anything about the ultimate delivery ("broadcast"). ISTM that the situation should be reversed. Given the abundant prior art in the distribution space -- and the fact that it's overall an easier problem technically -- means we don't have to say a whole lot here. Whereas the problems raised by the broadcast protocol are numerous and subtle. Starting with the "school closed" case is less than convincing. The more I think about it, the less I think we need to do anything about that case. There are lots of existing technologies that meet the needs of that case (SIP, Jabber, email); or at least, I don't recall having heard an argument that they don't. Notwithstanding the above, the requirements are actually pretty OK. I would assign them to slightly different parts of the architecture (mainly as aspects of the broadcast protocol), and I think there need to also be some security requirements, but it seems like they should basically all be carried forward. ----- Ciao Hannes On Sep 17, 2011, at 9:19 PM, Hannes Tschofenig wrote: > Hi all, > > based on the discussions from the last IETF meeting I have written a short section for the current requirements/framework/terminology document. I would like to know whether it captures the discussions appropriately or where additional text is needed. > > ------ > > 3. Alert Delivery Architecture > > Section 1 describes the basic two steps that are involved with the > alert message handling, namely subscription and alert delivery. From > an architectural point of view there are, however, a few variations > possible depending on the characteristics of the subscription process > and the style of message delivery. This section offers more details > on the communication architecture and highlights the necessary > standardization actions. > > We start our description with the so-called "school closed" example > where school authorities send alerts to all parents to notify theim > about the fact that their children cannot attend school. Parents > subscribe to these events when their children start attending the > school and unsubscribe when they are finished with a particular > school. The subscription procedures establishes a closed > communication group and authorization is also taken off as part of > this process. Typically, alert messages stay within the closed group > and are not shared with others and alert message delivery is point- > to-point with whatever communication protocol is most suitable. This > also means that there the alerts reach those who have subscribed > rather than those who are in the vicinity of the school. The number > of alert message Recipients is typically rather small, in the order > of hundreds to several thousands. > > A variation of the "school closed" example is an explicit > subscription model where no closed group pattern exists. Consider a > traveler who would like to receive weather alerts about a specific > geographical region. He may have to manually search for how to > subscribe to alerts for the desired region, potentially looking a > different subscription points for different types of alerts. As an > automated version of this procedure some form of discovery may help > to find these subscription servers. The approach described in > [I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery > such alert subscription servers. The number of alert message > Recipients is larger than in the previous example but will typically > stay below the millions. > > With the next category we move to a scenario where large number of > Recipients shall be notified but the subscription itself is implicit, > as it is the case when persons are within a specific region that can > easily be reached by making use of broadcast link layer technologies. > The placement of the actors from Figure 1 is thereby important. When > a Sender distributes the alert it distributes it already to Relays > within the geographically affected area. Those Relays are located > within Internet Service Providers so that multicast and broadcast > communication protocols can be utilized for efficient distribution to > a large number of Recipients. When the alert message delivery is > accomplished at the networking layer then various requirements, such > as the ability to deal with NAT and firewall traversal, have to be > met by such a protocol. The number of alert message Recipients is > very large, potentially in the millions. > > Next, we move to a model where the alert distribution uses a > broadcast network layer distribution mechanism but subscription to > the alerts is explicit. Figure 2 shows the architecture. The LoST > Forest Guide ensures that there is a way for Reivers to discovery > local alert subscription servers. The individual LoST servers > thereby know about these authoritative servers and redirect discovery > requests to the appropriate LoST server in case the answer cannot be > provided for a request, similar to how LoST is used in the ECRIT > emergency services architecture [RFC5582]. > > Once a Receiver had discovered a local subscription server it > subscribes to it (with additional information about the type of alert > it is interested in). As a response, it will receive information > about the security credential the relay is going to use for > subsequent alert delivery. > > When an Author creates an alert for distribution the affected region > will be indicated and so the alert will be sent to a relay within the > realm of the local alert distribution server and a notification will > be sent to all the subscribed Receivers. The local Relay and the > local alert subscription server will therefore cooperate in the > handling of the alerts. > > > ,-----. > / Lost \ > +-------( Server )---------+ > Forest ,-----. \ A / ,-----. > Guide / LoST \ `-----' / LoST \ > ( Server ) ( Server ) > \ D / ,-----. \ B / > `-----' / LoST \ `-----' > +-------( Server )---------+ > \ B / > `-----' > ,''''''''''''''''''''''''\ : > | Local ,------. | : > | Alert | Local| | : ................... > | Subscription | Relay|.|..: Alert | +------+ Author | > | Server `......'-+-------------------------+-|Sender| O | > | | | Notification | | | /|\ | > '`'''''''''''''''''+'''''' | +------+ / \ | > | Alert | `-----------------' > Subscr. +---------+ > | | Notification > | | > | | > ..................... > | +------+ Recipient| > | |Recvr | O | > | | | /|\ | > | +------+ / \ | > `-------------------' > > Figure 2: Architectural Model for the Broadcast Alert Delivery > Mechanism with Explicit Subscription > > ------ > > The not-yet-submitted version of the document, which contains the above writeup, can be found here: > https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-framewo rk/draft-ietf-atoca-requirements-02.txt > > Ciao > Hannes > _______________________________________________ atoca mailing list atoca@ietf.org https://www.ietf.org/mailman/listinfo/atoca From mark.wood@drcf.net Mon Sep 19 03:15:27 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1B21F8B7A for ; Mon, 19 Sep 2011 03:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.847, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QRTQU1WyduE for ; Mon, 19 Sep 2011 03:15:26 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by ietfa.amsl.com (Postfix) with ESMTP id 57E0921F8B8C for ; Mon, 19 Sep 2011 03:15:26 -0700 (PDT) X-Trace: 515957600/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/81.86.43.86/None/mark.wood@drcf.net X-SBRS: None X-RemoteIP: 81.86.43.86 X-IP-MAIL-FROM: mark.wood@drcf.net X-SMTP-AUTH: X-Originating-Country: GB/UNITED KINGDOM X-MUA: Microsoft Office Outlook, Build 11.0.5510Produced By Microsoft MimeOLE V6.1.7601.17609 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMGAL4Vd05RVitW/2dsb2JhbABCmQGOHHiBUwEGCDIcFRsFBgMSDz4aBhAOAQEEHhCHXpYTpEKBBQSMS4wJh3qEKQ X-IronPort-AV: E=Sophos;i="4.68,404,1312153200"; d="scan'208";a="515957600" X-IP-Direction: IN Received: from 81-86-43-86.dsl.pipex.com (HELO number15) ([81.86.43.86]) by smtp.pipex.tiscali.co.uk with ESMTP; 19 Sep 2011 11:17:42 +0100 From: "Mark" To: In-Reply-To: <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> Date: Mon, 19 Sep 2011 11:17:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 Thread-Index: Acx2nMZARwM0UoXmQlGvPhPxQ68CngABT68wAAQXaWA= Message-Id: <20110919101526.57E0921F8B8C@ietfa.amsl.com> Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 10:15:27 -0000 Thanks Peter; -PS- A second reason is that it is not clear that there is a sense of urgency here. Possibly the message is sent on the previous evening of the day when the school is closed. Regards, Peter -MW- Sadly, it's usually the case that the mass scale 10^7 distribution needs to be delivered "in a timely manner" at the moment that the network is in acute overload situations. By contrast, such things as 'civic information' or school closures, even if on a large scale, may not also simultaneously occur during acute overload instances. Therefore for many situations the normal push/pull bearers that we have now may well be perfectly fine. Broadcast and multicast bearers are also a good fit for smaller scale civic messaging, because they are much more efficient and are natively and passively geo specific, but using them in combination with push or pull is also possible provided we are not in an acute phase. I will be having a chat with my CAP expert later today to get some clarification about how CAP is authenticated. I think there is an EXL -DE wrapper around it which contains specified origination point codes. I note that ITU-T SG11 has become involved in this part of the solution because one of the other things they do is to manage the object identifier space (or one of the three of them). I will chat to some people who know about that today and ask for clarification. Mark ca From Hannes.Tschofenig@gmx.net Mon Sep 19 04:02:03 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709F621F847F for ; Mon, 19 Sep 2011 04:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.04 X-Spam-Level: X-Spam-Status: No, score=-102.04 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QmCpfEi95UJ for ; Mon, 19 Sep 2011 04:02:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9950821F847C for ; Mon, 19 Sep 2011 04:02:01 -0700 (PDT) Received: (qmail invoked by alias); 19 Sep 2011 11:04:18 -0000 Received: from unknown (EHLO [10.255.133.66]) [192.100.123.77] by mail.gmx.net (mp012) with SMTP; 19 Sep 2011 13:04:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/nhZ5qubLnERM5l/dAmt2Cq44Xj/K/wCgghbrLGr Wu+szJwBehm7z5 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> Date: Mon, 19 Sep 2011 14:04:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <87D738A3-08FD-4B87-9ED4-C128A024DE9B@gmx.net> References: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> To: Peter Sanders X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:02:03 -0000 Hi Peter,=20 I agree with you that location may not play the same role as in the mass = alert distribution case.=20 In this case the alerts may refer to a specific location (such as "give = me all weather alerts from the Helsinki area") but in the school = specific example the location plays a less important role.=20 The urgency is clearly also not the same as in the tsuami warning case. = For that reason the point-to-point delivery is a suitable choice here.=20= I have specifically added this example because many of the Internet = alert distribution examples make use of this type of alert distribution = and they happen to use CAP and GeoRSS for that purpose. For example, = have a look at:=20 http://alerts.weather.gov/ Ciao Hannes On Sep 19, 2011, at 11:36 AM, Peter Sanders wrote: > Hi Hannes, >=20 > I would support Richard's idea that the "school closed" example is not = very > convincing. One reason is that the alert is not location specific. It > doesn't really matter where the school children or their parents are = when > the alert is transmitted. A second reason is that it is not clear that = there > is a sense of urgency here. Possibly the message is sent on the = previous > evening of the day when the school is closed. >=20 > Regards, > Peter=20 >=20 >=20 > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf = Of > Hannes Tschofenig > Sent: maandag 19 september 2011 9:21 > To: Hannes Tschofenig; atoca@ietf.org > Subject: Re: [atoca] Architecture Writeup >=20 > Here is some feedback from Richard on my writeup sent off list = earlier. With > his permission I share it with you: >=20 >=20 > ----- >=20 > The document only barely touches on the separation of distribution = from > broadcast. The only spot I see it is in the separation of "Receiver" = from > "recipient", which seems confusing. The document seems inordinately = focused > on the "Message Handling System" ("distribution", in the terminology = I've > been using), and doesn't really say anything about the ultimate = delivery > ("broadcast"). ISTM that the situation should be reversed. Given the > abundant prior art in the distribution space -- and the fact that it's > overall an easier problem technically -- means we don't have to say a = whole > lot here. Whereas the problems raised by the broadcast protocol are > numerous and subtle. >=20 > Starting with the "school closed" case is less than convincing. The = more I > think about it, the less I think we need to do anything about that = case. > There are lots of existing technologies that meet the needs of that = case > (SIP, Jabber, email); or at least, I don't recall having heard an = argument > that they don't. >=20 > Notwithstanding the above, the requirements are actually pretty OK. I = would > assign them to slightly different parts of the architecture (mainly as > aspects of the broadcast protocol), and I think there need to also be = some > security requirements, but it seems like they should basically all be > carried forward. >=20 > ----- >=20 > Ciao > Hannes >=20 >=20 > On Sep 17, 2011, at 9:19 PM, Hannes Tschofenig wrote: >=20 >> Hi all,=20 >>=20 >> based on the discussions from the last IETF meeting I have written a = short > section for the current requirements/framework/terminology document. I = would > like to know whether it captures the discussions appropriately or = where > additional text is needed.=20 >>=20 >> ------ >>=20 >> 3. Alert Delivery Architecture >>=20 >> Section 1 describes the basic two steps that are involved with the >> alert message handling, namely subscription and alert delivery. = From >> an architectural point of view there are, however, a few variations >> possible depending on the characteristics of the subscription = process >> and the style of message delivery. This section offers more = details >> on the communication architecture and highlights the necessary >> standardization actions. >>=20 >> We start our description with the so-called "school closed" example >> where school authorities send alerts to all parents to notify theim >> about the fact that their children cannot attend school. Parents >> subscribe to these events when their children start attending the >> school and unsubscribe when they are finished with a particular >> school. The subscription procedures establishes a closed >> communication group and authorization is also taken off as part of >> this process. Typically, alert messages stay within the closed = group >> and are not shared with others and alert message delivery is point- >> to-point with whatever communication protocol is most suitable. = This >> also means that there the alerts reach those who have subscribed >> rather than those who are in the vicinity of the school. The = number >> of alert message Recipients is typically rather small, in the order >> of hundreds to several thousands. >>=20 >> A variation of the "school closed" example is an explicit >> subscription model where no closed group pattern exists. Consider = a >> traveler who would like to receive weather alerts about a specific >> geographical region. He may have to manually search for how to >> subscribe to alerts for the desired region, potentially looking a >> different subscription points for different types of alerts. As an >> automated version of this procedure some form of discovery may help >> to find these subscription servers. The approach described in >> [I-D.rosen-ecrit-lost-early-warning] is one possible way to = discovery >> such alert subscription servers. The number of alert message >> Recipients is larger than in the previous example but will = typically >> stay below the millions. >>=20 >> With the next category we move to a scenario where large number of >> Recipients shall be notified but the subscription itself is = implicit, >> as it is the case when persons are within a specific region that = can >> easily be reached by making use of broadcast link layer = technologies. >> The placement of the actors from Figure 1 is thereby important. = When >> a Sender distributes the alert it distributes it already to Relays >> within the geographically affected area. Those Relays are located >> within Internet Service Providers so that multicast and broadcast >> communication protocols can be utilized for efficient distribution = to >> a large number of Recipients. When the alert message delivery is >> accomplished at the networking layer then various requirements, = such >> as the ability to deal with NAT and firewall traversal, have to be >> met by such a protocol. The number of alert message Recipients is >> very large, potentially in the millions. >>=20 >> Next, we move to a model where the alert distribution uses a >> broadcast network layer distribution mechanism but subscription to >> the alerts is explicit. Figure 2 shows the architecture. The LoST >> Forest Guide ensures that there is a way for Reivers to discovery >> local alert subscription servers. The individual LoST servers >> thereby know about these authoritative servers and redirect = discovery >> requests to the appropriate LoST server in case the answer cannot = be >> provided for a request, similar to how LoST is used in the ECRIT >> emergency services architecture [RFC5582]. >>=20 >> Once a Receiver had discovered a local subscription server it >> subscribes to it (with additional information about the type of = alert >> it is interested in). As a response, it will receive information >> about the security credential the relay is going to use for >> subsequent alert delivery. >>=20 >> When an Author creates an alert for distribution the affected = region >> will be indicated and so the alert will be sent to a relay within = the >> realm of the local alert distribution server and a notification = will >> be sent to all the subscribed Receivers. The local Relay and the >> local alert subscription server will therefore cooperate in the >> handling of the alerts. >>=20 >>=20 >> ,-----. >> / Lost \ >> +-------( Server )---------+ >> Forest ,-----. \ A / ,-----. >> Guide / LoST \ `-----' / LoST \ >> ( Server ) ( Server ) >> \ D / ,-----. \ B / >> `-----' / LoST \ `-----' >> +-------( Server )---------+ >> \ B / >> `-----' >> ,''''''''''''''''''''''''\ : >> | Local ,------. | : >> | Alert | Local| | : = ................... >> | Subscription | Relay|.|..: Alert | +------+ Author = | >> | Server `......'-+-------------------------+-|Sender| O = | >> | | | Notification | | | /|\ = | >> '`'''''''''''''''''+'''''' | +------+ / \ = | >> | Alert | = `-----------------' >> Subscr. +---------+ >> | | Notification >> | | >> | | >> ..................... >> | +------+ Recipient| >> | |Recvr | O | >> | | | /|\ | >> | +------+ / \ | >> `-------------------' >>=20 >> Figure 2: Architectural Model for the Broadcast Alert Delivery >> Mechanism with Explicit Subscription >>=20 >> ------ >>=20 >> The not-yet-submitted version of the document, which contains the = above > writeup, can be found here:=20 >>=20 > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-frame= wo > rk/draft-ietf-atoca-requirements-02.txt >>=20 >> Ciao >> Hannes >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca >=20 From hannes.tschofenig@gmx.net Mon Sep 19 04:06:58 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7665521F87D3 for ; Mon, 19 Sep 2011 04:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.037 X-Spam-Level: X-Spam-Status: No, score=-102.037 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlBaBsWQTxL2 for ; Mon, 19 Sep 2011 04:06:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9AEDF21F87C2 for ; Mon, 19 Sep 2011 04:06:57 -0700 (PDT) Received: (qmail invoked by alias); 19 Sep 2011 11:09:17 -0000 Received: from unknown (EHLO [10.255.133.66]) [192.100.123.77] by mail.gmx.net (mp018) with SMTP; 19 Sep 2011 13:09:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/DMH4UIBrDJFBK0KWAiBQmBtlfTnt9vtN5ABtA10 J5KuKyByxoC6yT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20110919101526.57E0921F8B8C@ietfa.amsl.com> Date: Mon, 19 Sep 2011 14:09:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110919101526.57E0921F8B8C@ietfa.amsl.com> To: Mark X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:06:58 -0000 Hi Mark,=20 On Sep 19, 2011, at 1:17 PM, Mark wrote: > I will be having a chat with my CAP expert later today to get some > clarification about how CAP is authenticated. We know how CAP messages are authenticated; at least we know what the = specification says (namely XML DSIG). It would be interesting to hear what is being used in the real world=20 > I think there is an EXL -DE > wrapper around it which contains specified origination point codes. I = note > that ITU-T SG11 has become involved in this part of the solution = because one > of the other things they do is to manage the object identifier space = (or one > of the three of them).=20 Nobody so far suggested to use EDXL-DE in this discussion.=20 EDXL-DE, if I correctly understood it, adds another wrapper on top of = CAP.=20 This will obviously not make the size problems to go away. Instead, they = will become more problematic as we add more wrappers.=20 Ciao Hannes From hannes.tschofenig@gmx.net Mon Sep 19 04:11:25 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF7121F8A80 for ; Mon, 19 Sep 2011 04:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.034 X-Spam-Level: X-Spam-Status: No, score=-102.034 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpUpcBSMUURF for ; Mon, 19 Sep 2011 04:11:24 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6ACC321F8A7A for ; Mon, 19 Sep 2011 04:11:23 -0700 (PDT) Received: (qmail invoked by alias); 19 Sep 2011 11:13:44 -0000 Received: from unknown (EHLO [10.255.133.66]) [192.100.123.77] by mail.gmx.net (mp052) with SMTP; 19 Sep 2011 13:13:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/mj7wx5+rmJ7EXSwS2HWEcugEfhSdUZWTBSFsfQH Jm+JjvSqLjmip0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4CBA3684-14EB-4D84-8B40-292B18084C42@incident.com> Date: Mon, 19 Sep 2011 14:13:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A1E418E-52B2-426A-B8B9-F0F35BBFA920@gmx.net> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C507@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0C508@SISPE7MB1.commscope.com> <4CBA3684-14EB-4D84-8B40-292B18084C42@incident.com> To: Art Botterell X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] [Ecrit] Scope of the Work X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:11:25 -0000 Hi Art,=20 I have used these scenario terms only for convenience reasons to refer = to the different classes of systems.=20 There is one solution cluster that uses unicast alert delivery (I = mentioned the XMPP/Atom/etc. approach here) and then there is the second = one that uses multicast/broadcast. The requirements for these two are = quite different and from the feedback I had gotten regarding scoping = there seems to be a preference to work on the latter but not on the = former (with the impression being that the former category is already = being worked on).=20 Ciao Hannes PS: I have indeed sent the message to the wrong mailing list. Sorry = about that. On Sep 19, 2011, at 3:40 AM, Art Botterell wrote: > Let me just confess a feeling that we may have a shortfall of analysis = here. Particular use cases are valuable to the extent they reveal = underlying patterns that can then become generalized; otherwise we wind = up building single functions instead of flexible tools.. In this case, = what seems like a dichotomy may actually be a continuum, with the = use-cases we're considering being relatively near the opposite ends of a = spectrum, and with a variety of others lying between them. >=20 > Anyway, perhaps the correct formulation isn't "mass" versus "school" = so much as broadly-targeted vs. narrowly targeted... or perhaps = attribute-constrained vs. list-constrained (where geography is one of a = variety of possible attributes that might inform the distribution of an = alert). In any event, most of the qualitative distinctions reflect = technology artifacts rather than different requirements. In particular, = list-driven approaches tend not to scale well due both to network = inefficiencies and the exponential cost of maintaining = large-yet-accurate lists. >=20 > Ultimately, I think... and I believe I've said this before, so please = forgive the repetition... that what we're really looking at is a = relatively generic, albeit still unresolved, problem of multicasting, as = opposed to the scalability problems of a unicast approach. >=20 > - Art >=20 >=20 > On Sep 18, 2011, at 5:15 PM, Thomson, Martin wrote: >=20 >> This is a good question. Sent to the wrong WG :) >>=20 >> If anyone has any thoughts on this topic, I'd be interested to hear = them. >>=20 >> (And then I did exactly the same thing...) >>=20 >> On 2011-09-19 at 02:32:07, Hannes Tschofenig wrote: >>> Hi all, >>>=20 >>> in earlier discussions we had always listed the school shooting=20 >>> scenario as a use case to summarize a cluster of solutions that use=20= >>> existing protocols, such as XMPP or SIP, to convey the alerts in a=20= >>> point-to-point fashion (using a subscribe/notify paradigm). >>> A few of us had worked on these solutions, such as=20 >>> http://xmpp.org/extensions/xep-0127.html or=20 >>> http://tools.ietf.org/html/draft-rosen-sipping-cap-04. These = writeups=20 >>> should give you more background about the characteristics of the=20 >>> provided solution (in case the scenario description isn't so good). >>>=20 >>> These solutions are not suitable for mass delivery (aka Tsunami=20 >>> warning >>> case) but work fine in various other use cases. I had a short = writeup=20 >>> of the scenario in the architecture mail I distributed yesterday. >>>=20 >>> Now, in off-list discussions for the virtual interim meeting the=20 >>> question was raised whether this use case is something that should = not=20 >>> be dealt with in the group but instead the focus be spent on the = mass=20 >>> delivery. =46rom a requirements point of view these two cases are=20 >>> obviously quite different and the mass delivery case would make use = of=20 >>> multicast/broadcast delivery instead. >>>=20 >>> I would need feedback from the rest of the group. There are two=20 >>> choices, I believe: >>>=20 >>> 1) Focus on the mass alert delivery work, >>>=20 >>> 2) In addition to the mass delivery work also address the school=20 >>> shooting scenario (based on how I described it in my architectural=20= >>> writeup, see http://www.ietf.org/mail-=20 >>> archive/web/atoca/current/msg00536.html, that would lead to a >>> point-to- point alert delivery. >>>=20 >>> What would you prefer? >>>=20 >>> Ciao >>> Hannes >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From hannes.tschofenig@gmx.net Mon Sep 19 04:18:22 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B5B21F8BA0 for ; Mon, 19 Sep 2011 04:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh1cjTSyC61Z for ; Mon, 19 Sep 2011 04:18:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8A69821F8BAC for ; Mon, 19 Sep 2011 04:18:17 -0700 (PDT) Received: (qmail invoked by alias); 19 Sep 2011 11:20:38 -0000 Received: from unknown (EHLO [10.255.133.66]) [192.100.123.77] by mail.gmx.net (mp033) with SMTP; 19 Sep 2011 13:20:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18+Z9gcnRc+8yGleOuGL8EXk8S87cn1j6ubFm9BSQ sEwvs0emqmWVpI Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <20110916151231.4544E21F8AF0@ietfa.amsl.com> Date: Mon, 19 Sep 2011 14:20:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <88A55840-1615-4319-A395-61D3E3AC14B9@gmx.net> References: <20110916151231.4544E21F8AF0@ietfa.amsl.com> To: Mark X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: atoca@ietf.org Subject: Re: [atoca] Content Responsibility. X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 11:18:22 -0000 Although your discussion is interesting the alert content is outside the = scope of the ATOCA group.=20 Is there anything in this thread that could provide input to the = technical requirements we put into the requirements document?=20 On Sep 16, 2011, at 6:14 PM, Mark wrote: >=20 > Chaps; >=20 >=20 > -BD- "I do not envision a 4G network sending entire CAP messages to = the > device either - in fact, CMAS is carried over to 4G and will work = exactly > like it is defined for GSM and UMTS." >=20 > -MW- Maybe I am not being more all inclusive when I say '4G'.=20 >=20 > Maybe "networks" which are *not* operating GSM, UMTS or LTE standards = will > participate, and they may do so within a framework which is not at all = like > CMAS. >=20 > For example if a university enterprise network were to offer such a = service > over its WiFi system, it may decide to go well beyond what CMAS = requires as > the IP multicast system seems to have no specific limits as to payload = size. >=20 >=20 > Also, CMAS is the result of negotiations between USA entities, whereas = other > non US entities, (and indeed non cellular networks), may decide that = some > aspects of CMAS are too limiting to really be a strict model (Though = many of > its structures such will be the same). >=20 > I feel that more standards than ETWS, CMAS and ETSI 102-900 are yet to > emerge from the back rooms of governments! >=20 > So it's not safe to conclude that another participating network with > different system technology will restrict their offering to the = subscriber > as much as CMAS has. >=20 > IMHO this means that if the participating network will agree, then = almost > all of the CAP message would be distributed (minus any security things = that > the trust protocol removes, of course!). Provided they are happy with = the > burden of so doing.=20 >=20 > However this is the decision of the owners of the participating = network, who > are after all, providing their spectrum and base station network. This = does > need to be respected in my view. =20 >=20 >=20 > Mark >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From hgs@cs.columbia.edu Mon Sep 19 06:19:32 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3C721F8BF9 for ; Mon, 19 Sep 2011 06:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYzvFZAD-4AC for ; Mon, 19 Sep 2011 06:19:31 -0700 (PDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44E21F8BC5 for ; Mon, 19 Sep 2011 06:19:31 -0700 (PDT) Received: from upstairs-3.home (pool-71-187-38-33.nwrknj.fios.verizon.net [71.187.38.33]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p8JDLo3K007239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Sep 2011 09:21:51 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> Date: Mon, 19 Sep 2011 09:21:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DB3C0D1-BD92-49E5-A817-2A907A87CCBB@cs.columbia.edu> References: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> To: Peter Sanders X-Mailer: Apple Mail (2.1244.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: atoca@ietf.org Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 13:19:33 -0000 I think it's helpful to enumerate the scenarios, including the school = alerts, even if we then declare some to be "already solved" or "beyond = the scope". The problem with non-standard school alerts is fairly obvious: Right = now, if each school has its own mechanism, aggregators (e.g., TV = stations, public transit authorities or large employers) have to = manually extract the information and keep track of a dozen different = ways to get the information. Typically, such systems are also = display-oriented, making processing of the information very difficult. = Such processing includes appropriate rendering for people with = disabilities. Also, I think it would be helpful to distinguish more clearly between = delivery of structured and display of formatted information.Somewhere = along the way, the translation happens. We have often implicitly assumed = that this is in the end system, but that's clearly not always the case. = For example, CAP could be translated to a voice call "in the network", = or an SMS message or some other display format. This includes language = translation by third-party services. (Government issues the alert, but, = say, a local NGO decides to convert the alert to the language of an = immigrant community.) Henning On Sep 19, 2011, at 4:36 AM, Peter Sanders wrote: > Hi Hannes, >=20 > I would support Richard's idea that the "school closed" example is not = very > convincing. One reason is that the alert is not location specific. It > doesn't really matter where the school children or their parents are = when > the alert is transmitted. A second reason is that it is not clear that = there > is a sense of urgency here. Possibly the message is sent on the = previous > evening of the day when the school is closed. >=20 > Regards, > Peter=20 >=20 >=20 > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf = Of > Hannes Tschofenig > Sent: maandag 19 september 2011 9:21 > To: Hannes Tschofenig; atoca@ietf.org > Subject: Re: [atoca] Architecture Writeup >=20 > Here is some feedback from Richard on my writeup sent off list = earlier. With > his permission I share it with you: >=20 >=20 > ----- >=20 > The document only barely touches on the separation of distribution = from > broadcast. The only spot I see it is in the separation of "Receiver" = from > "recipient", which seems confusing. The document seems inordinately = focused > on the "Message Handling System" ("distribution", in the terminology = I've > been using), and doesn't really say anything about the ultimate = delivery > ("broadcast"). ISTM that the situation should be reversed. Given the > abundant prior art in the distribution space -- and the fact that it's > overall an easier problem technically -- means we don't have to say a = whole > lot here. Whereas the problems raised by the broadcast protocol are > numerous and subtle. >=20 > Starting with the "school closed" case is less than convincing. The = more I > think about it, the less I think we need to do anything about that = case. > There are lots of existing technologies that meet the needs of that = case > (SIP, Jabber, email); or at least, I don't recall having heard an = argument > that they don't. >=20 > Notwithstanding the above, the requirements are actually pretty OK. I = would > assign them to slightly different parts of the architecture (mainly as > aspects of the broadcast protocol), and I think there need to also be = some > security requirements, but it seems like they should basically all be > carried forward. >=20 > ----- >=20 > Ciao > Hannes >=20 >=20 > On Sep 17, 2011, at 9:19 PM, Hannes Tschofenig wrote: >=20 >> Hi all,=20 >>=20 >> based on the discussions from the last IETF meeting I have written a = short > section for the current requirements/framework/terminology document. I = would > like to know whether it captures the discussions appropriately or = where > additional text is needed.=20 >>=20 >> ------ >>=20 >> 3. Alert Delivery Architecture >>=20 >> Section 1 describes the basic two steps that are involved with the >> alert message handling, namely subscription and alert delivery. = From >> an architectural point of view there are, however, a few variations >> possible depending on the characteristics of the subscription = process >> and the style of message delivery. This section offers more = details >> on the communication architecture and highlights the necessary >> standardization actions. >>=20 >> We start our description with the so-called "school closed" example >> where school authorities send alerts to all parents to notify theim >> about the fact that their children cannot attend school. Parents >> subscribe to these events when their children start attending the >> school and unsubscribe when they are finished with a particular >> school. The subscription procedures establishes a closed >> communication group and authorization is also taken off as part of >> this process. Typically, alert messages stay within the closed = group >> and are not shared with others and alert message delivery is point- >> to-point with whatever communication protocol is most suitable. = This >> also means that there the alerts reach those who have subscribed >> rather than those who are in the vicinity of the school. The = number >> of alert message Recipients is typically rather small, in the order >> of hundreds to several thousands. >>=20 >> A variation of the "school closed" example is an explicit >> subscription model where no closed group pattern exists. Consider = a >> traveler who would like to receive weather alerts about a specific >> geographical region. He may have to manually search for how to >> subscribe to alerts for the desired region, potentially looking a >> different subscription points for different types of alerts. As an >> automated version of this procedure some form of discovery may help >> to find these subscription servers. The approach described in >> [I-D.rosen-ecrit-lost-early-warning] is one possible way to = discovery >> such alert subscription servers. The number of alert message >> Recipients is larger than in the previous example but will = typically >> stay below the millions. >>=20 >> With the next category we move to a scenario where large number of >> Recipients shall be notified but the subscription itself is = implicit, >> as it is the case when persons are within a specific region that = can >> easily be reached by making use of broadcast link layer = technologies. >> The placement of the actors from Figure 1 is thereby important. = When >> a Sender distributes the alert it distributes it already to Relays >> within the geographically affected area. Those Relays are located >> within Internet Service Providers so that multicast and broadcast >> communication protocols can be utilized for efficient distribution = to >> a large number of Recipients. When the alert message delivery is >> accomplished at the networking layer then various requirements, = such >> as the ability to deal with NAT and firewall traversal, have to be >> met by such a protocol. The number of alert message Recipients is >> very large, potentially in the millions. >>=20 >> Next, we move to a model where the alert distribution uses a >> broadcast network layer distribution mechanism but subscription to >> the alerts is explicit. Figure 2 shows the architecture. The LoST >> Forest Guide ensures that there is a way for Reivers to discovery >> local alert subscription servers. The individual LoST servers >> thereby know about these authoritative servers and redirect = discovery >> requests to the appropriate LoST server in case the answer cannot = be >> provided for a request, similar to how LoST is used in the ECRIT >> emergency services architecture [RFC5582]. >>=20 >> Once a Receiver had discovered a local subscription server it >> subscribes to it (with additional information about the type of = alert >> it is interested in). As a response, it will receive information >> about the security credential the relay is going to use for >> subsequent alert delivery. >>=20 >> When an Author creates an alert for distribution the affected = region >> will be indicated and so the alert will be sent to a relay within = the >> realm of the local alert distribution server and a notification = will >> be sent to all the subscribed Receivers. The local Relay and the >> local alert subscription server will therefore cooperate in the >> handling of the alerts. >>=20 >>=20 >> ,-----. >> / Lost \ >> +-------( Server )---------+ >> Forest ,-----. \ A / ,-----. >> Guide / LoST \ `-----' / LoST \ >> ( Server ) ( Server ) >> \ D / ,-----. \ B / >> `-----' / LoST \ `-----' >> +-------( Server )---------+ >> \ B / >> `-----' >> ,''''''''''''''''''''''''\ : >> | Local ,------. | : >> | Alert | Local| | : = ................... >> | Subscription | Relay|.|..: Alert | +------+ Author = | >> | Server `......'-+-------------------------+-|Sender| O = | >> | | | Notification | | | /|\ = | >> '`'''''''''''''''''+'''''' | +------+ / \ = | >> | Alert | = `-----------------' >> Subscr. +---------+ >> | | Notification >> | | >> | | >> ..................... >> | +------+ Recipient| >> | |Recvr | O | >> | | | /|\ | >> | +------+ / \ | >> `-------------------' >>=20 >> Figure 2: Architectural Model for the Broadcast Alert Delivery >> Mechanism with Explicit Subscription >>=20 >> ------ >>=20 >> The not-yet-submitted version of the document, which contains the = above > writeup, can be found here:=20 >>=20 > = https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-frame= wo > rk/draft-ietf-atoca-requirements-02.txt >>=20 >> Ciao >> Hannes >>=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca >=20 From igor.faynberg@alcatel-lucent.com Mon Sep 19 06:30:23 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587E421F8BCB for ; Mon, 19 Sep 2011 06:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.603 X-Spam-Level: X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3Z3Y7unLj0c for ; Mon, 19 Sep 2011 06:30:22 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 14C4321F8BA8 for ; Mon, 19 Sep 2011 06:30:21 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p8JDWiZq023201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Sep 2011 08:32:44 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8JDWhBs012781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Sep 2011 08:32:44 -0500 Received: from [135.244.2.102] (faynberg.lra.lucent.com [135.244.2.102]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p8JDWgvV026341; Mon, 19 Sep 2011 08:32:42 -0500 (CDT) Message-ID: <4E774479.80705@alcatel-lucent.com> Date: Mon, 19 Sep 2011 09:32:41 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: atoca@ietf.org References: <23F05F30-1FA2-4104-BBD1-1D6AA92668B3@gmx.net> <006e01cc76a7$3cdb6910$b6923b30$@sanders@one2many.eu> <9DB3C0D1-BD92-49E5-A817-2A907A87CCBB@cs.columbia.edu> In-Reply-To: <9DB3C0D1-BD92-49E5-A817-2A907A87CCBB@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [atoca] Architecture Writeup X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 13:30:23 -0000 +1 Igor On 9/19/2011 9:21 AM, Henning Schulzrinne wrote: > I think it's helpful to enumerate the scenarios, including the school alerts, even if we then declare some to be "already solved" or "beyond the scope". > > The problem with non-standard school alerts is fairly obvious: Right now, if each school has its own mechanism, aggregators (e.g., TV stations, public transit authorities or large employers) have to manually extract the information and keep track of a dozen different ways to get the information. Typically, such systems are also display-oriented, making processing of the information very difficult. Such processing includes appropriate rendering for people with disabilities. > > Also, I think it would be helpful to distinguish more clearly between delivery of structured and display of formatted information.Somewhere along the way, the translation happens. We have often implicitly assumed that this is in the end system, but that's clearly not always the case. For example, CAP could be translated to a voice call "in the network", or an SMS message or some other display format. This includes language translation by third-party services. (Government issues the alert, but, say, a local NGO decides to convert the alert to the language of an immigrant community.) > > Henning > > On Sep 19, 2011, at 4:36 AM, Peter Sanders wrote: > >> Hi Hannes, >> >> I would support Richard's idea that the "school closed" example is not very >> convincing. One reason is that the alert is not location specific. It >> doesn't really matter where the school children or their parents are when >> the alert is transmitted. A second reason is that it is not clear that there >> is a sense of urgency here. Possibly the message is sent on the previous >> evening of the day when the school is closed. >> >> Regards, >> Peter >> >> >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of >> Hannes Tschofenig >> Sent: maandag 19 september 2011 9:21 >> To: Hannes Tschofenig; atoca@ietf.org >> Subject: Re: [atoca] Architecture Writeup >> >> Here is some feedback from Richard on my writeup sent off list earlier. With >> his permission I share it with you: >> >> >> ----- >> >> The document only barely touches on the separation of distribution from >> broadcast. The only spot I see it is in the separation of "Receiver" from >> "recipient", which seems confusing. The document seems inordinately focused >> on the "Message Handling System" ("distribution", in the terminology I've >> been using), and doesn't really say anything about the ultimate delivery >> ("broadcast"). ISTM that the situation should be reversed. Given the >> abundant prior art in the distribution space -- and the fact that it's >> overall an easier problem technically -- means we don't have to say a whole >> lot here. Whereas the problems raised by the broadcast protocol are >> numerous and subtle. >> >> Starting with the "school closed" case is less than convincing. The more I >> think about it, the less I think we need to do anything about that case. >> There are lots of existing technologies that meet the needs of that case >> (SIP, Jabber, email); or at least, I don't recall having heard an argument >> that they don't. >> >> Notwithstanding the above, the requirements are actually pretty OK. I would >> assign them to slightly different parts of the architecture (mainly as >> aspects of the broadcast protocol), and I think there need to also be some >> security requirements, but it seems like they should basically all be >> carried forward. >> >> ----- >> >> Ciao >> Hannes >> >> >> On Sep 17, 2011, at 9:19 PM, Hannes Tschofenig wrote: >> >>> Hi all, >>> >>> based on the discussions from the last IETF meeting I have written a short >> section for the current requirements/framework/terminology document. I would >> like to know whether it captures the discussions appropriately or where >> additional text is needed. >>> ------ >>> >>> 3. Alert Delivery Architecture >>> >>> Section 1 describes the basic two steps that are involved with the >>> alert message handling, namely subscription and alert delivery. From >>> an architectural point of view there are, however, a few variations >>> possible depending on the characteristics of the subscription process >>> and the style of message delivery. This section offers more details >>> on the communication architecture and highlights the necessary >>> standardization actions. >>> >>> We start our description with the so-called "school closed" example >>> where school authorities send alerts to all parents to notify theim >>> about the fact that their children cannot attend school. Parents >>> subscribe to these events when their children start attending the >>> school and unsubscribe when they are finished with a particular >>> school. The subscription procedures establishes a closed >>> communication group and authorization is also taken off as part of >>> this process. Typically, alert messages stay within the closed group >>> and are not shared with others and alert message delivery is point- >>> to-point with whatever communication protocol is most suitable. This >>> also means that there the alerts reach those who have subscribed >>> rather than those who are in the vicinity of the school. The number >>> of alert message Recipients is typically rather small, in the order >>> of hundreds to several thousands. >>> >>> A variation of the "school closed" example is an explicit >>> subscription model where no closed group pattern exists. Consider a >>> traveler who would like to receive weather alerts about a specific >>> geographical region. He may have to manually search for how to >>> subscribe to alerts for the desired region, potentially looking a >>> different subscription points for different types of alerts. As an >>> automated version of this procedure some form of discovery may help >>> to find these subscription servers. The approach described in >>> [I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery >>> such alert subscription servers. The number of alert message >>> Recipients is larger than in the previous example but will typically >>> stay below the millions. >>> >>> With the next category we move to a scenario where large number of >>> Recipients shall be notified but the subscription itself is implicit, >>> as it is the case when persons are within a specific region that can >>> easily be reached by making use of broadcast link layer technologies. >>> The placement of the actors from Figure 1 is thereby important. When >>> a Sender distributes the alert it distributes it already to Relays >>> within the geographically affected area. Those Relays are located >>> within Internet Service Providers so that multicast and broadcast >>> communication protocols can be utilized for efficient distribution to >>> a large number of Recipients. When the alert message delivery is >>> accomplished at the networking layer then various requirements, such >>> as the ability to deal with NAT and firewall traversal, have to be >>> met by such a protocol. The number of alert message Recipients is >>> very large, potentially in the millions. >>> >>> Next, we move to a model where the alert distribution uses a >>> broadcast network layer distribution mechanism but subscription to >>> the alerts is explicit. Figure 2 shows the architecture. The LoST >>> Forest Guide ensures that there is a way for Reivers to discovery >>> local alert subscription servers. The individual LoST servers >>> thereby know about these authoritative servers and redirect discovery >>> requests to the appropriate LoST server in case the answer cannot be >>> provided for a request, similar to how LoST is used in the ECRIT >>> emergency services architecture [RFC5582]. >>> >>> Once a Receiver had discovered a local subscription server it >>> subscribes to it (with additional information about the type of alert >>> it is interested in). As a response, it will receive information >>> about the security credential the relay is going to use for >>> subsequent alert delivery. >>> >>> When an Author creates an alert for distribution the affected region >>> will be indicated and so the alert will be sent to a relay within the >>> realm of the local alert distribution server and a notification will >>> be sent to all the subscribed Receivers. The local Relay and the >>> local alert subscription server will therefore cooperate in the >>> handling of the alerts. >>> >>> >>> ,-----. >>> / Lost \ >>> +-------( Server )---------+ >>> Forest ,-----. \ A / ,-----. >>> Guide / LoST \ `-----' / LoST \ >>> ( Server ) ( Server ) >>> \ D / ,-----. \ B / >>> `-----' / LoST \ `-----' >>> +-------( Server )---------+ >>> \ B / >>> `-----' >>> ,''''''''''''''''''''''''\ : >>> | Local ,------. | : >>> | Alert | Local| | : ................... >>> | Subscription | Relay|.|..: Alert | +------+ Author | >>> | Server `......'-+-------------------------+-|Sender| O | >>> | | | Notification | | | /|\ | >>> '`'''''''''''''''''+'''''' | +------+ / \ | >>> | Alert | `-----------------' >>> Subscr. +---------+ >>> | | Notification >>> | | >>> | | >>> ..................... >>> | +------+ Recipient| >>> | |Recvr | O | >>> | | | /|\ | >>> | +------+ / \ | >>> `-------------------' >>> >>> Figure 2: Architectural Model for the Broadcast Alert Delivery >>> Mechanism with Explicit Subscription >>> >>> ------ >>> >>> The not-yet-submitted version of the document, which contains the above >> writeup, can be found here: >> https://github.com/hannestschofenig/tschofenig-ids/blob/master/atoca-framewo >> rk/draft-ietf-atoca-requirements-02.txt >>> Ciao >>> Hannes >>> >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >> >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca >> > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From sob@harvard.edu Fri Sep 23 07:06:28 2011 Return-Path: X-Original-To: atoca@ietfa.amsl.com Delivered-To: atoca@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBF421F8C91 for ; Fri, 23 Sep 2011 07:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbrV57qMpoDE for ; Fri, 23 Sep 2011 07:06:28 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7621F8C92 for ; Fri, 23 Sep 2011 07:06:28 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 9F4C6F98B0B; Fri, 23 Sep 2011 10:09:01 -0400 (EDT) To: atoca@ietf.org Message-Id: <20110923140901.9F4C6F98B0B@newdev.eecs.harvard.edu> Date: Fri, 23 Sep 2011 10:09:01 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [atoca] US FCC Review of the Emergency Alert System X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert $atoca$ working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 14:06:29 -0000 fyi http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db0916/FCC-11-136A1.pdf Scott