From br@brianrosen.net Fri May 1 07:12:19 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B48028C187 for ; Fri, 1 May 2009 07:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksUqWJV8wh-f for ; Fri, 1 May 2009 07:12:18 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 53F8528C0E1 for ; Fri, 1 May 2009 07:12:18 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LztUa-0000R5-4C; Fri, 01 May 2009 09:13:35 -0500 From: "Brian Rosen" To: , References: <49FA1E10.6050101@netmagic.com> In-Reply-To: <49FA1E10.6050101@netmagic.com> Date: Fri, 1 May 2009 10:13:37 -0400 Message-ID: <088c01c9ca67$08bc9a30$1a35ce90$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnJ3lJz1DMLqnC1QoWI0KA4Zg+X3QAgGLtQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 14:12:19 -0000 Thanks for the reference to X.1303. I think we need to confine our discussions on this list to "authority to citizen" (although that wording is changing), and our use of CAP will be limited to that context. Brian -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of Tony Rutkowski Sent: Thursday, April 30, 2009 5:54 PM To: earlywarning@ietf.org Subject: [earlywarning] global CAP community Hi all, Glad to see this working group get under way. There is a large and diverse global CAP community. Because the "authority" is often (but not always as Art notes) government in nature, or implemented pursuant to government requirements, the intergovernmental - industry organizations like ITU-T have been significantly involved. At the domestic level, legislation like the US WARN Act also affect these implementations. I have attached the ITU-T X-series version of CAP 1.1. It's a copy of the OASIS version, plus a translation into ASN.1 (for those who love that syntax or find it useful for compact applications). It's also what most governmental authorities will reference in most jurisdictions. As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay involved in this IETF WG and keep you apprised of things happening there and contribute to your work. Because CAP is flexible, extensible, and ubiquitous, it's worth considering its application in diverse contexts. For example, what would others think of using CAP in conjunction with dispersing cybersecurity forensics (think IODEF or CAPEX) or vulnerability information? If so, what is there some larger ontology that needs to be developed? cheers, tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From creed@opengeospatial.org Fri May 1 08:59:31 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB5F3A6D18 for ; Fri, 1 May 2009 08:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6LPIBy48pMH for ; Fri, 1 May 2009 08:59:30 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [208.44.53.140]) by core3.amsl.com (Postfix) with ESMTP id 366A93A7087 for ; Fri, 1 May 2009 08:59:30 -0700 (PDT) Received: from CarlandSusieOf (c-75-71-192-203.hsd1.co.comcast.net [75.71.192.203]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3) with ESMTP id n41G0EG5023459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 May 2009 12:00:15 -0400 Message-ID: <61C38B2D3CDF403AAE17DC6DB452DAD3@CarlandSusieOf> From: "Carl Reed" To: "Brian Rosen" , , References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> In-Reply-To: <088c01c9ca67$08bc9a30$1a35ce90$@net> Date: Fri, 1 May 2009 09:59:31 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0206_01C9CA43.85B0DCF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Virus-Scanned: ClamAV 0.92.1/9309/Thu Apr 30 23:55:03 2009 on mail.opengeospatial.org X-Virus-Status: Clean Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 15:59:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0206_01C9CA43.85B0DCF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tony - I worked CAP 1.0 and 1.1 standardization. My sense is that the CAP = community wishes to adhere to the "The design should not place undue = burdens of complexity on technical implementers." Whenever I tried to = have additional functionality added, such as the ability to express a = coordinate reference system other than WGS 84 2d, there was considerable = pushback. So, my guidance on this topic would be to consider how to = enhance CAP for use in other domains, I would suggest you look to what = is currently being done in OASIS in terms of defining CAP profiles.=20 As to extensibility of CAP, that is another issue. This is one of the = topics being considered as part of the CAP 2.0 discussions. We are = hoping, for example, to enhance the geo information model and schema = elements of CAP to be consistent with GeoRSS and PIDF-LO geodetic.=20 Regards Carl Reed CTO OGC ----- Original Message -----=20 From: "Brian Rosen" To: ; Sent: Friday, May 01, 2009 8:13 AM Subject: Re: [earlywarning] global CAP community > Thanks for the reference to X.1303. >=20 > I think we need to confine our discussions on this list to "authority = to > citizen" (although that wording is changing), and our use of CAP will = be > limited to that context. >=20 > Brian >=20 > -----Original Message----- > From: earlywarning-bounces@ietf.org = [mailto:earlywarning-bounces@ietf.org] > On Behalf Of Tony Rutkowski > Sent: Thursday, April 30, 2009 5:54 PM > To: earlywarning@ietf.org > Subject: [earlywarning] global CAP community >=20 > Hi all, >=20 > Glad to see this working group get under way. There is a large and = diverse > global CAP community. >=20 > Because the "authority" is often (but not always as Art notes) = government in > nature, or implemented pursuant to government requirements, the > intergovernmental - industry organizations like ITU-T have been > significantly involved. At the domestic level, legislation like the = US WARN > Act also affect these implementations. >=20 > I have attached the ITU-T X-series version of CAP 1.1. It's a copy of = the > OASIS version, plus a translation into ASN.1 (for those who love that = syntax > or find it useful for compact applications). It's also what most > governmental authorities will reference in most jurisdictions. >=20 > As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay > involved in this IETF WG and keep you apprised of things happening = there and > contribute to your work. >=20 > Because CAP is flexible, extensible, and ubiquitous, it's worth = considering > its application in diverse contexts. For example, what would others = think > of using CAP in conjunction with dispersing cybersecurity forensics = (think > IODEF or CAPEX) or vulnerability > information? If so, what is there some larger ontology that needs > to be developed? >=20 > cheers, > tony >=20 > -- > Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 = 703.999.8270 >=20 >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning ------=_NextPart_000_0206_01C9CA43.85B0DCF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Tony -
 
I worked CAP 1.0 and 1.1 standardization. My sense is that the CAP=20 community wishes to adhere to the "The design should not place undue = burdens of=20 complexity on technical implementers." Whenever I tried to have = additional=20 functionality added, such as the ability to express a coordinate = reference=20 system other than WGS 84 2d, there was considerable pushback. So, my = guidance on=20 this topic would be to consider how to enhance CAP for use in other = domains, I=20 would suggest you look to what is currently being done in OASIS in terms = of=20 defining CAP profiles.
 
As to extensibility of CAP, that is another issue. This is one = of the=20 topics being considered as part of the CAP 2.0 discussions. We are = hoping, for=20 example, to enhance the geo information model and schema elements of CAP = to be=20 consistent with GeoRSS and PIDF-LO geodetic.
 
Regards
 
Carl Reed
CTO
OGC
 
----- Original Message -----=20
From: "Brian Rosen" <br@brianrosen.net>
To: <trutkowski@netmagic.com>; = <earlywarning@ietf.org>
=
Sent: Friday, May 01, 2009 8:13 AM
Subject: Re: [earlywarning] global CAP community

> Thanks for the reference to X.1303.
>
> = I think=20 we need to confine our discussions on this list to "authority to
> = citizen" (although that wording is changing), and our use of CAP will = be
>=20 limited to that context.
>
> Brian
>
> = -----Original=20 Message-----
> From: earlywarning-bounces@ietf.o= rg=20 [mailto:earlywarning-bounces@ietf.org]
> On Behalf Of Tony=20 Rutkowski
> Sent: Thursday, April 30, 2009 5:54 PM
> To: earlywarning@ietf.org
> = Subject:=20 [earlywarning] global CAP community
>
> Hi all,
> =
>=20 Glad to see this working group get under way.  There is a large and = diverse
> global CAP community.
>
> Because the = "authority"=20 is often (but not always as Art notes) government in
> nature, or=20 implemented pursuant to government requirements, the
> = intergovernmental -=20 industry organizations like ITU-T have been
> significantly=20 involved.  At the domestic level, legislation like the US = WARN
> Act=20 also affect these implementations.
>
> I have attached the = ITU-T=20 X-series version of CAP 1.1.  It's a copy of the
> OASIS = version,=20 plus a translation into ASN.1 (for those who love that syntax
> or = find it=20 useful for compact applications).  It's also what most
> = governmental=20 authorities will reference in most jurisdictions.
>
> As = the=20 rapporteur of working group Q.4/17 in ITU-T, I'll try and stay
> = involved=20 in this IETF WG and keep you apprised of things happening there = and
>=20 contribute to your work.
>
> Because CAP is flexible, = extensible,=20 and ubiquitous, it's worth considering
> its application in = diverse=20 contexts.  For example, what would others think
> of using = CAP in=20 conjunction with dispersing cybersecurity forensics (think
> IODEF = or=20 CAPEX) or vulnerability
> information?   If so, what is = there=20 some larger ontology that needs
> to be developed?
> =
>=20 cheers,
> tony
>
> --
> Tony Rutkowski | = Netmagic=20 Associates LLC | Ashburn VA | mob: +1 703.999.8270
>
> =
>=20 _______________________________________________
> earlywarning = mailing=20 list
> earlywarning@ietf.org
> = https://www.i= etf.org/mailman/listinfo/earlywarning ------=_NextPart_000_0206_01C9CA43.85B0DCF0-- From rbarnes@bbn.com Fri May 1 09:01:41 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0F73A6FF2 for ; Fri, 1 May 2009 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cmJuzRaK8CE for ; Fri, 1 May 2009 09:01:39 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 681EF3A6D49 for ; Fri, 1 May 2009 09:00:45 -0700 (PDT) Received: from [128.89.254.153] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LzvBc-00052v-Ea; Fri, 01 May 2009 12:02:04 -0400 Message-ID: <49FB1CFB.4050708@bbn.com> Date: Fri, 01 May 2009 12:02:03 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Brian Rosen References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> In-Reply-To: <088c01c9ca67$08bc9a30$1a35ce90$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:01:41 -0000 I wonder if it might ultimately be a good idea to deprecate the word "authority" for the purposes of these technical discussions, in favor of a more neutral term. "Alert originator" or something like that. The only characteristics of the authority/originator that this group needs to care about are (1) That it's the source of alerts that the system distributes (2) That it will need to be able to authenticate to the distribution system (in order to support the application of authorization policies) Whether the entity that fulfills those criteria is a government, a corporation, or my Twitter feed really isn't important, as long as the appropriate credentials and policies have been set up. --Richard Brian Rosen wrote: > Thanks for the reference to X.1303. > > I think we need to confine our discussions on this list to "authority to > citizen" (although that wording is changing), and our use of CAP will be > limited to that context. > > Brian > > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] > On Behalf Of Tony Rutkowski > Sent: Thursday, April 30, 2009 5:54 PM > To: earlywarning@ietf.org > Subject: [earlywarning] global CAP community > > Hi all, > > Glad to see this working group get under way. There is a large and diverse > global CAP community. > > Because the "authority" is often (but not always as Art notes) government in > nature, or implemented pursuant to government requirements, the > intergovernmental - industry organizations like ITU-T have been > significantly involved. At the domestic level, legislation like the US WARN > Act also affect these implementations. > > I have attached the ITU-T X-series version of CAP 1.1. It's a copy of the > OASIS version, plus a translation into ASN.1 (for those who love that syntax > or find it useful for compact applications). It's also what most > governmental authorities will reference in most jurisdictions. > > As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay > involved in this IETF WG and keep you apprised of things happening there and > contribute to your work. > > Because CAP is flexible, extensible, and ubiquitous, it's worth considering > its application in diverse contexts. For example, what would others think > of using CAP in conjunction with dispersing cybersecurity forensics (think > IODEF or CAPEX) or vulnerability > information? If so, what is there some larger ontology that needs > to be developed? > > cheers, > tony > > -- > Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 > > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > From creed@opengeospatial.org Fri May 1 09:28:41 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742013A6CB1 for ; Fri, 1 May 2009 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oVNlxN5UO91 for ; Fri, 1 May 2009 09:28:40 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [208.44.53.140]) by core3.amsl.com (Postfix) with ESMTP id 635F03A6FC2 for ; Fri, 1 May 2009 09:28:40 -0700 (PDT) Received: from CarlandSusieOf (c-75-71-192-203.hsd1.co.comcast.net [75.71.192.203]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3) with ESMTP id n41GTwQN026292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 May 2009 12:29:59 -0400 Message-ID: From: "Carl Reed" To: "Richard Barnes" , "Brian Rosen" References: <49FA1E10.6050101@netmagic.com><088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> In-Reply-To: <49FB1CFB.4050708@bbn.com> Date: Fri, 1 May 2009 10:28:06 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Virus-Scanned: ClamAV 0.92.1/9309/Thu Apr 30 23:55:03 2009 on mail.opengeospatial.org X-Virus-Status: Clean Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 16:28:41 -0000 For what it is worth, what Richard is suggesting is the approach that many in OGC implementation community use for providing alerts. Typically, the alerting infrastructure, such as being developed for numerous applications in Europe and Asia, supports multiple alert payload encoding. The user (gov, citizen, whatever) subscribes to alerts in the desired/required payload encoding . Authentication is a key aspect of this process: Anyone subscribing to receive alerts is authenticated in terms of what content can actually distributed to them. As to the alert originator, we have the same issue: more and more alerts are originating from sensor networks. The sensor networks are integrated into some larger information processing network (earthquake, tsunami, wildfire, etc). These "originator" systems may be government, private, NGO, research/ University or some partnership. Cheers Carl ----- Original Message ----- From: "Richard Barnes" To: "Brian Rosen" Cc: Sent: Friday, May 01, 2009 10:02 AM Subject: Re: [earlywarning] global CAP community >I wonder if it might ultimately be a good idea to deprecate the word >"authority" for the purposes of these technical discussions, in favor of a >more neutral term. "Alert originator" or something like that. The only >characteristics of the authority/originator that this group needs to care >about are > > (1) That it's the source of alerts that the system distributes > > (2) That it will need to be able to authenticate to the distribution > system (in order to support the application of authorization policies) > > Whether the entity that fulfills those criteria is a government, a > corporation, or my Twitter feed really isn't important, as long as the > appropriate credentials and policies have been set up. > > --Richard > > > > Brian Rosen wrote: >> Thanks for the reference to X.1303. >> >> I think we need to confine our discussions on this list to "authority to >> citizen" (although that wording is changing), and our use of CAP will be >> limited to that context. >> >> Brian >> >> -----Original Message----- >> From: earlywarning-bounces@ietf.org >> [mailto:earlywarning-bounces@ietf.org] >> On Behalf Of Tony Rutkowski >> Sent: Thursday, April 30, 2009 5:54 PM >> To: earlywarning@ietf.org >> Subject: [earlywarning] global CAP community >> >> Hi all, >> >> Glad to see this working group get under way. There is a large and >> diverse >> global CAP community. >> >> Because the "authority" is often (but not always as Art notes) government >> in >> nature, or implemented pursuant to government requirements, the >> intergovernmental - industry organizations like ITU-T have been >> significantly involved. At the domestic level, legislation like the US >> WARN >> Act also affect these implementations. >> >> I have attached the ITU-T X-series version of CAP 1.1. It's a copy of >> the >> OASIS version, plus a translation into ASN.1 (for those who love that >> syntax >> or find it useful for compact applications). It's also what most >> governmental authorities will reference in most jurisdictions. >> >> As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >> involved in this IETF WG and keep you apprised of things happening there >> and >> contribute to your work. >> >> Because CAP is flexible, extensible, and ubiquitous, it's worth >> considering >> its application in diverse contexts. For example, what would others >> think >> of using CAP in conjunction with dispersing cybersecurity forensics >> (think >> IODEF or CAPEX) or vulnerability >> information? If so, what is there some larger ontology that needs >> to be developed? >> >> cheers, >> tony >> >> -- >> Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >> 703.999.8270 >> >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From rbarnes@bbn.com Fri May 1 11:25:10 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD63C3A6C9C for ; Fri, 1 May 2009 11:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dbFKKriNGcs for ; Fri, 1 May 2009 11:25:07 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4703B3A6EBD for ; Fri, 1 May 2009 11:25:07 -0700 (PDT) Received: from [128.89.254.128] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LzxRO-0006qK-EX; Fri, 01 May 2009 14:26:30 -0400 Message-ID: <49FB3ED6.9090107@bbn.com> Date: Fri, 01 May 2009 14:26:30 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Carl Reed References: <49FA1E10.6050101@netmagic.com><088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:25:10 -0000 Carl, Is there a common term in the OGC for this entity, one that this group could re-use? Did I actually guess right with "alert orginator"?? --Richard Carl Reed wrote: > For what it is worth, what Richard is suggesting is the approach that > many in OGC implementation community use for providing alerts. > Typically, the alerting infrastructure, such as being developed for > numerous applications in Europe and Asia, supports multiple alert > payload encoding. The user (gov, citizen, whatever) subscribes to alerts > in the desired/required payload encoding . Authentication is a key > aspect of this process: Anyone subscribing to receive alerts is > authenticated in terms of what content can actually distributed to them. > > As to the alert originator, we have the same issue: more and more alerts > are originating from sensor networks. The sensor networks are integrated > into some larger information processing network (earthquake, tsunami, > wildfire, etc). These "originator" systems may be government, private, > NGO, research/ University or some partnership. > > Cheers > > Carl > > > ----- Original Message ----- From: "Richard Barnes" > To: "Brian Rosen" > Cc: > Sent: Friday, May 01, 2009 10:02 AM > Subject: Re: [earlywarning] global CAP community > > >> I wonder if it might ultimately be a good idea to deprecate the word >> "authority" for the purposes of these technical discussions, in favor >> of a more neutral term. "Alert originator" or something like that. >> The only characteristics of the authority/originator that this group >> needs to care about are >> >> (1) That it's the source of alerts that the system distributes >> >> (2) That it will need to be able to authenticate to the distribution >> system (in order to support the application of authorization policies) >> >> Whether the entity that fulfills those criteria is a government, a >> corporation, or my Twitter feed really isn't important, as long as the >> appropriate credentials and policies have been set up. >> >> --Richard >> >> >> >> Brian Rosen wrote: >>> Thanks for the reference to X.1303. >>> >>> I think we need to confine our discussions on this list to "authority to >>> citizen" (although that wording is changing), and our use of CAP will be >>> limited to that context. >>> >>> Brian >>> >>> -----Original Message----- >>> From: earlywarning-bounces@ietf.org >>> [mailto:earlywarning-bounces@ietf.org] >>> On Behalf Of Tony Rutkowski >>> Sent: Thursday, April 30, 2009 5:54 PM >>> To: earlywarning@ietf.org >>> Subject: [earlywarning] global CAP community >>> >>> Hi all, >>> >>> Glad to see this working group get under way. There is a large and >>> diverse >>> global CAP community. >>> >>> Because the "authority" is often (but not always as Art notes) >>> government in >>> nature, or implemented pursuant to government requirements, the >>> intergovernmental - industry organizations like ITU-T have been >>> significantly involved. At the domestic level, legislation like the >>> US WARN >>> Act also affect these implementations. >>> >>> I have attached the ITU-T X-series version of CAP 1.1. It's a copy >>> of the >>> OASIS version, plus a translation into ASN.1 (for those who love that >>> syntax >>> or find it useful for compact applications). It's also what most >>> governmental authorities will reference in most jurisdictions. >>> >>> As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>> involved in this IETF WG and keep you apprised of things happening >>> there and >>> contribute to your work. >>> >>> Because CAP is flexible, extensible, and ubiquitous, it's worth >>> considering >>> its application in diverse contexts. For example, what would others >>> think >>> of using CAP in conjunction with dispersing cybersecurity forensics >>> (think >>> IODEF or CAPEX) or vulnerability >>> information? If so, what is there some larger ontology that needs >>> to be developed? >>> >>> cheers, >>> tony >>> >>> -- >>> Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >>> 703.999.8270 >>> >>> >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >>> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > From jmpolk@cisco.com Fri May 1 11:36:46 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2893A6A3C for ; Fri, 1 May 2009 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yde58OxO7Obi for ; Fri, 1 May 2009 11:36:45 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CDB4A3A72A3 for ; Fri, 1 May 2009 11:33:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="179713122" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 01 May 2009 18:35:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n41IZ14q010665; Fri, 1 May 2009 11:35:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n41IZ1QT027811; Fri, 1 May 2009 18:35:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 11:35:01 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 11:35:00 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 13:34:56 -0500 To: Richard Barnes , Brian Rosen From: "James M. Polk" In-Reply-To: <49FB1CFB.4050708@bbn.com> References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 18:35:00.0808 (UTC) FILETIME=[89366C80:01C9CA8B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3660; t=1241202901; x=1242066901; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=MGW1kvsgSGs7DJ8MWjZlWf+muQ6t+8wcMaAXWQ5hy9Y=; b=QzLVyMdyjzlKrEQdt9d+Y6nH4RTQtzYL0eG7HPicWnEqUk0Vb5+T1HcGwz 9GSpnSMnlYsPJg/PRJeDMPpQOzAJtNXlZ5067X1ayivduPm6haUyzTmKAThx 5vXMMbUoUo; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:36:46 -0000 At 11:02 AM 5/1/2009, Richard Barnes wrote: >I wonder if it might ultimately be a good idea to deprecate the word >"authority" for the purposes of these technical discussions, in >favor of a more neutral term. "Alert originator" or something like >that. The only characteristics of the authority/originator that >this group needs to care about are > >(1) That it's the source of alerts that the system distributes > >(2) That it will need to be able to authenticate to the distribution >system (in order to support the application of authorization policies) > >Whether the entity that fulfills those criteria is a government, a >corporation, or my Twitter feed really isn't important, I reeeeally disagree with this statement. You, Richard (and I'm only picking on you because you brought it up) might not care, but many will care the differences here. I only want to get a Presidential alert (one of CAP's alert levels) from an authorized source. I don't want to get it from my company, your company or anyone's twitter. I want it coming from an "authorized" source. Anything less than that is person to person for all I care, and I dont' have a good means of validating that source, if it's opened up to be "from anybody" using twitter. >as long as the appropriate credentials and policies have been set up. how exactly is twitter going to provide these credentials? >--Richard > > > >Brian Rosen wrote: >>Thanks for the reference to X.1303. >>I think we need to confine our discussions on this list to "authority to >>citizen" (although that wording is changing), and our use of CAP will be >>limited to that context. >>Brian >>-----Original Message----- >>From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] >>On Behalf Of Tony Rutkowski >>Sent: Thursday, April 30, 2009 5:54 PM >>To: earlywarning@ietf.org >>Subject: [earlywarning] global CAP community >>Hi all, >>Glad to see this working group get under way. There is a large and diverse >>global CAP community. >>Because the "authority" is often (but not always as Art notes) government in >>nature, or implemented pursuant to government requirements, the >>intergovernmental - industry organizations like ITU-T have been >>significantly involved. At the domestic level, legislation like the US WARN >>Act also affect these implementations. >>I have attached the ITU-T X-series version of CAP 1.1. It's a copy of the >>OASIS version, plus a translation into ASN.1 (for those who love that syntax >>or find it useful for compact applications). It's also what most >>governmental authorities will reference in most jurisdictions. >>As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>involved in this IETF WG and keep you apprised of things happening there and >>contribute to your work. >>Because CAP is flexible, extensible, and ubiquitous, it's worth considering >>its application in diverse contexts. For example, what would others think >>of using CAP in conjunction with dispersing cybersecurity forensics (think >>IODEF or CAPEX) or vulnerability >>information? If so, what is there some larger ontology that needs >>to be developed? >>cheers, >>tony >>-- >>Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 >> >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Fri May 1 11:38:58 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCBA53A6C9C for ; Fri, 1 May 2009 11:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.489 X-Spam-Level: X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+4w8vt2aRBp for ; Fri, 1 May 2009 11:38:51 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DD2483A6A3C for ; Fri, 1 May 2009 11:38:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="34791513" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 01 May 2009 18:40:15 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n41IeFMA005206; Fri, 1 May 2009 11:40:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n41IeFcc003824; Fri, 1 May 2009 18:40:15 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 11:40:15 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 11:40:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 13:40:10 -0500 To: "Carl Reed" , "Richard Barnes" , "Brian Rosen" From: "James M. Polk" In-Reply-To: References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 18:40:14.0792 (UTC) FILETIME=[445C9480:01C9CA8C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5089; t=1241203215; x=1242067215; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=FlLz0gCzOqsBlQaU8dui5ilH0S4tFPW1s2AZvD+y8xs=; b=SKpvxyQamwPLDALDPw/87DtmivCBFe7Ipal5tbzv3DiJFPPye4ebJYI1Y7 9GjZUot35QSIhMTAlFkdFUIEP4IRaLuUyYAo6EN8WlX/9NJfaWQPXiygZtXb ZPT+/u8QK0; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:38:58 -0000 At 11:28 AM 5/1/2009, Carl Reed wrote: >For what it is worth, what Richard is suggesting is the approach >that many in OGC implementation community use for providing alerts. >Typically, the alerting infrastructure, such as being developed for >numerous applications in Europe and Asia, supports multiple alert >payload encoding. The user (gov, citizen, whatever) subscribes to >alerts in the desired/required payload encoding . Authentication is >a key aspect of this process: Anyone subscribing to receive alerts >is authenticated in terms of what content can actually distributed to them. > >As to the alert originator, we have the same issue: more and more >alerts are originating from sensor networks. The sensor networks are >integrated into some larger information processing network >(earthquake, tsunami, wildfire, etc). These "originator" systems may >be government, private, NGO, research/ University or some partnership. Carl -- then they need to be classified as such, do they not? How exactly does one trust the originator of a message? Any alerts from earthquake, tsunami, wildfire, etc... can be architected up to an "authority", then that authority can distribute the information to anyone they allow to subscribe to the service (or just freely give it out). I believe this is begging for someone who wants to pull a prank in, say a London tunnel, of alerting a large number of people about a false event. That would be almost as damaging as an actual event, given the panic that would ensue. >Cheers > >Carl > > >----- Original Message ----- From: "Richard Barnes" >To: "Brian Rosen" >Cc: >Sent: Friday, May 01, 2009 10:02 AM >Subject: Re: [earlywarning] global CAP community > > >>I wonder if it might ultimately be a good idea to deprecate the >>word "authority" for the purposes of these technical discussions, >>in favor of a more neutral term. "Alert originator" or something >>like that. The only characteristics of the authority/originator >>that this group needs to care about are >> >>(1) That it's the source of alerts that the system distributes >> >>(2) That it will need to be able to authenticate to the >>distribution system (in order to support the application of >>authorization policies) >> >>Whether the entity that fulfills those criteria is a government, a >>corporation, or my Twitter feed really isn't important, as long as >>the appropriate credentials and policies have been set up. >> >>--Richard >> >> >> >>Brian Rosen wrote: >>>Thanks for the reference to X.1303. >>> >>>I think we need to confine our discussions on this list to "authority to >>>citizen" (although that wording is changing), and our use of CAP will be >>>limited to that context. >>> >>>Brian >>> >>>-----Original Message----- >>>From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] >>>On Behalf Of Tony Rutkowski >>>Sent: Thursday, April 30, 2009 5:54 PM >>>To: earlywarning@ietf.org >>>Subject: [earlywarning] global CAP community >>> >>>Hi all, >>> >>>Glad to see this working group get under way. There is a large and diverse >>>global CAP community. >>> >>>Because the "authority" is often (but not always as Art notes) government in >>>nature, or implemented pursuant to government requirements, the >>>intergovernmental - industry organizations like ITU-T have been >>>significantly involved. At the domestic level, legislation like the US WARN >>>Act also affect these implementations. >>> >>>I have attached the ITU-T X-series version of CAP 1.1. It's a copy of the >>>OASIS version, plus a translation into ASN.1 (for those who love that syntax >>>or find it useful for compact applications). It's also what most >>>governmental authorities will reference in most jurisdictions. >>> >>>As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>>involved in this IETF WG and keep you apprised of things happening there and >>>contribute to your work. >>> >>>Because CAP is flexible, extensible, and ubiquitous, it's worth considering >>>its application in diverse contexts. For example, what would others think >>>of using CAP in conjunction with dispersing cybersecurity forensics (think >>>IODEF or CAPEX) or vulnerability >>>information? If so, what is there some larger ontology that needs >>>to be developed? >>> >>>cheers, >>>tony >>> >>>-- >>>Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 >>> >>> >>>_______________________________________________ >>>earlywarning mailing list >>>earlywarning@ietf.org >>>https://www.ietf.org/mailman/listinfo/earlywarning >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Fri May 1 11:44:31 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4DDD3A69B2 for ; Fri, 1 May 2009 11:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD1Vy5IYKOGn for ; Fri, 1 May 2009 11:44:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E064D3A6EBD for ; Fri, 1 May 2009 11:44:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="74239916" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 01 May 2009 18:45:54 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n41Ijs8W015427; Fri, 1 May 2009 11:45:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n41Ijsbx020243; Fri, 1 May 2009 18:45:54 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 11:45:54 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 11:45:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 13:45:49 -0500 To: Richard Barnes , Carl Reed From: "James M. Polk" In-Reply-To: <49FB3ED6.9090107@bbn.com> References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 18:45:54.0163 (UTC) FILETIME=[0EA47C30:01C9CA8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5467; t=1241203554; x=1242067554; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=C2bU0dSooEizoSk9ciPowbxzF3SAJxdLOArwdTQE4p0=; b=glSD0SZYDeSLF9EaxfN5Fi1lXjwrTKT1D112p+Nvma1HBWdtiU1ICKSore 5VYdDsbnHXEXjNUkWnuReuEVK4Sl/MaSW5VybOtN6NZZc9tpsg/agpv1nqkJ TgJTLewIVl; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 18:44:32 -0000 At 01:26 PM 5/1/2009, Richard Barnes wrote: >Carl, > >Is there a common term in the OGC for this entity, one that this >group could re-use? Did I actually guess right with "alert orginator"?? "alert-originator-to-who"? We just lost the latter half of this too, because "citizen" just went out the window given Carl's description of "The sensor networks are integrated into some larger information processing network (earthquake, tsunami, wildfire, etc)." Because the sensor information likely won't be consumer very often by "citizens", but by government agencies, and research labs. We're moving closer towards "point-to-point-alerts", and losing the concept of "authority" without the ability to verify who is the source of the information, which I consider really dangerous - because it will be misused. James >--Richard > > > >Carl Reed wrote: >>For what it is worth, what Richard is suggesting is the approach >>that many in OGC implementation community use for providing alerts. >>Typically, the alerting infrastructure, such as being developed for >>numerous applications in Europe and Asia, supports multiple alert >>payload encoding. The user (gov, citizen, whatever) subscribes to >>alerts in the desired/required payload encoding . Authentication is >>a key aspect of this process: Anyone subscribing to receive alerts >>is authenticated in terms of what content can actually distributed to them. >>As to the alert originator, we have the same issue: more and more >>alerts are originating from sensor networks. The sensor networks >>are integrated into some larger information processing network >>(earthquake, tsunami, wildfire, etc). These "originator" systems >>may be government, private, NGO, research/ University or some partnership. >>Cheers >>Carl >> >>----- Original Message ----- From: "Richard Barnes" >>To: "Brian Rosen" >>Cc: >>Sent: Friday, May 01, 2009 10:02 AM >>Subject: Re: [earlywarning] global CAP community >> >>>I wonder if it might ultimately be a good idea to deprecate the >>>word "authority" for the purposes of these technical discussions, >>>in favor of a more neutral term. "Alert originator" or something like that. >>>The only characteristics of the authority/originator that this >>>group needs to care about are >>> >>>(1) That it's the source of alerts that the system distributes >>> >>>(2) That it will need to be able to authenticate to the >>>distribution system (in order to support the application of >>>authorization policies) >>> >>>Whether the entity that fulfills those criteria is a government, a >>>corporation, or my Twitter feed really isn't important, as long as >>>the appropriate credentials and policies have been set up. >>> >>>--Richard >>> >>> >>> >>>Brian Rosen wrote: >>>>Thanks for the reference to X.1303. >>>> >>>>I think we need to confine our discussions on this list to "authority to >>>>citizen" (although that wording is changing), and our use of CAP will be >>>>limited to that context. >>>> >>>>Brian >>>> >>>>-----Original Message----- >>>>From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] >>>>On Behalf Of Tony Rutkowski >>>>Sent: Thursday, April 30, 2009 5:54 PM >>>>To: earlywarning@ietf.org >>>>Subject: [earlywarning] global CAP community >>>> >>>>Hi all, >>>> >>>>Glad to see this working group get under way. There is a large and diverse >>>>global CAP community. >>>> >>>>Because the "authority" is often (but not always as Art notes) >>>>government in >>>>nature, or implemented pursuant to government requirements, the >>>>intergovernmental - industry organizations like ITU-T have been >>>>significantly involved. At the domestic level, legislation like >>>>the US WARN >>>>Act also affect these implementations. >>>> >>>>I have attached the ITU-T X-series version of CAP 1.1. It's a copy of the >>>>OASIS version, plus a translation into ASN.1 (for those who love >>>>that syntax >>>>or find it useful for compact applications). It's also what most >>>>governmental authorities will reference in most jurisdictions. >>>> >>>>As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>>>involved in this IETF WG and keep you apprised of things >>>>happening there and >>>>contribute to your work. >>>> >>>>Because CAP is flexible, extensible, and ubiquitous, it's worth considering >>>>its application in diverse contexts. For example, what would others think >>>>of using CAP in conjunction with dispersing cybersecurity forensics (think >>>>IODEF or CAPEX) or vulnerability >>>>information? If so, what is there some larger ontology that needs >>>>to be developed? >>>> >>>>cheers, >>>>tony >>>> >>>>-- >>>>Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >>>>703.999.8270 >>>> >>>> >>>>_______________________________________________ >>>>earlywarning mailing list >>>>earlywarning@ietf.org >>>>https://www.ietf.org/mailman/listinfo/earlywarning >>>_______________________________________________ >>>earlywarning mailing list >>>earlywarning@ietf.org >>>https://www.ietf.org/mailman/listinfo/earlywarning >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From carlberg@g11.org.uk Fri May 1 12:00:15 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45FA3A6BD2 for ; Fri, 1 May 2009 12:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtmJCAcNHipw for ; Fri, 1 May 2009 12:00:13 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 528CC28C283 for ; Fri, 1 May 2009 12:00:10 -0700 (PDT) Received: from c-98-218-170-127.hsd1.va.comcast.net ([98.218.170.127]:65172 helo=[192.168.1.120]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lzxyx-0000kw-P4; Fri, 01 May 2009 19:01:11 +0000 Message-Id: <678745F2-9C68-4B90-895E-4F1151265620@g11.org.uk> From: ken carlberg To: "James M. Polk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 1 May 2009 15:01:13 -0400 References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:00:15 -0000 On May 1, 2009, at 2:45 PM, James M. Polk wrote: > "alert-originator-to-who"? Might I suggest "Authorized-originator to subscriber". I agree with the notion (if not the exact wording) brought up by Richard that it would be constructive to move away from the term "authority" since that term gravitates most folks to a 1-to-1 association with government, and that's not always the case with systems out there today. And while I thought it was implied in Richard's posting, the originator needs to have some measure of authority in originating a message to the alerting system as James is stating in his posting. The subscriber can be the direct consumer (you or me) or a proxy such as when my local cable company in the U.S. receives feeds from the Emergency Alert System and forwards it one additional downstream level to its subscribers. -ken From creed@opengeospatial.org Fri May 1 12:04:50 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520C03A710D for ; Fri, 1 May 2009 12:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwOYOMlqx1qh for ; Fri, 1 May 2009 12:04:49 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [208.44.53.140]) by core3.amsl.com (Postfix) with ESMTP id 435EA28C1E8 for ; Fri, 1 May 2009 12:02:41 -0700 (PDT) Received: from CarlandSusieOf (c-75-71-192-203.hsd1.co.comcast.net [75.71.192.203]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3) with ESMTP id n41J3xw4007527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 1 May 2009 15:04:00 -0400 Message-ID: From: "Carl Reed" To: "Richard Barnes" , "James M. Polk" References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> In-Reply-To: Date: Fri, 1 May 2009 13:04:03 -0600 Organization: OGC MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Virus-Scanned: ClamAV 0.92.1/9311/Fri May 1 12:29:13 2009 on mail.opengeospatial.org X-Virus-Status: Clean Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:04:50 -0000 James - I do not think I said that the citizen is out of the loop. The end user of these systems is often the citizen and not another government agency. For example, in the Indonesian Tsunami early warning system, ocean sensors provide measurements into a processing environment that uses the sensor measurements along with other data to model tsunami propagation for a given event. This information is then used to generate the appropriate alerts to the appropriate entities in the appropriate geographic region(s) including citizens. My point is that sensors themselves may not generate an alert but instead feed a workflow that does generate alerts. Also, the measurements generated many sensor networks are now directly accessible to citizens - such as traffic alert data. Sorry for any confusion. Carl ----- Original Message ----- From: "James M. Polk" To: "Richard Barnes" ; "Carl Reed" Cc: Sent: Friday, May 01, 2009 12:45 PM Subject: Re: [earlywarning] global CAP community > At 01:26 PM 5/1/2009, Richard Barnes wrote: >>Carl, >> >>Is there a common term in the OGC for this entity, one that this group >>could re-use? Did I actually guess right with "alert orginator"?? > > "alert-originator-to-who"? > > We just lost the latter half of this too, because "citizen" just went out > the window given Carl's description of > > "The sensor networks are integrated into some larger information > processing network (earthquake, tsunami, wildfire, etc)." > > Because the sensor information likely won't be consumer very often by > "citizens", but by government agencies, and research labs. > > We're moving closer towards "point-to-point-alerts", and losing the > concept of "authority" without the ability to verify who is the source of > the information, which I consider really dangerous - because it will be > misused. > > James > > >>--Richard >> >> >> >>Carl Reed wrote: >>>For what it is worth, what Richard is suggesting is the approach that >>>many in OGC implementation community use for providing alerts. Typically, >>>the alerting infrastructure, such as being developed for numerous >>>applications in Europe and Asia, supports multiple alert payload >>>encoding. The user (gov, citizen, whatever) subscribes to alerts in the >>>desired/required payload encoding . Authentication is a key aspect of >>>this process: Anyone subscribing to receive alerts is authenticated in >>>terms of what content can actually distributed to them. >>>As to the alert originator, we have the same issue: more and more alerts >>>are originating from sensor networks. The sensor networks are integrated >>>into some larger information processing network (earthquake, tsunami, >>>wildfire, etc). These "originator" systems may be government, private, >>>NGO, research/ University or some partnership. >>>Cheers >>>Carl >>> >>>----- Original Message ----- From: "Richard Barnes" >>>To: "Brian Rosen" >>>Cc: >>>Sent: Friday, May 01, 2009 10:02 AM >>>Subject: Re: [earlywarning] global CAP community >>> >>>>I wonder if it might ultimately be a good idea to deprecate the word >>>>"authority" for the purposes of these technical discussions, in favor of >>>>a more neutral term. "Alert originator" or something like that. >>>>The only characteristics of the authority/originator that this group >>>>needs to care about are >>>> >>>>(1) That it's the source of alerts that the system distributes >>>> >>>>(2) That it will need to be able to authenticate to the distribution >>>>system (in order to support the application of authorization policies) >>>> >>>>Whether the entity that fulfills those criteria is a government, a >>>>corporation, or my Twitter feed really isn't important, as long as the >>>>appropriate credentials and policies have been set up. >>>> >>>>--Richard >>>> >>>> >>>> >>>>Brian Rosen wrote: >>>>>Thanks for the reference to X.1303. >>>>> >>>>>I think we need to confine our discussions on this list to "authority >>>>>to >>>>>citizen" (although that wording is changing), and our use of CAP will >>>>>be >>>>>limited to that context. >>>>> >>>>>Brian >>>>> >>>>>-----Original Message----- >>>>>From: earlywarning-bounces@ietf.org >>>>>[mailto:earlywarning-bounces@ietf.org] >>>>>On Behalf Of Tony Rutkowski >>>>>Sent: Thursday, April 30, 2009 5:54 PM >>>>>To: earlywarning@ietf.org >>>>>Subject: [earlywarning] global CAP community >>>>> >>>>>Hi all, >>>>> >>>>>Glad to see this working group get under way. There is a large and >>>>>diverse >>>>>global CAP community. >>>>> >>>>>Because the "authority" is often (but not always as Art notes) >>>>>government in >>>>>nature, or implemented pursuant to government requirements, the >>>>>intergovernmental - industry organizations like ITU-T have been >>>>>significantly involved. At the domestic level, legislation like the US >>>>>WARN >>>>>Act also affect these implementations. >>>>> >>>>>I have attached the ITU-T X-series version of CAP 1.1. It's a copy of >>>>>the >>>>>OASIS version, plus a translation into ASN.1 (for those who love that >>>>>syntax >>>>>or find it useful for compact applications). It's also what most >>>>>governmental authorities will reference in most jurisdictions. >>>>> >>>>>As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>>>>involved in this IETF WG and keep you apprised of things happening >>>>>there and >>>>>contribute to your work. >>>>> >>>>>Because CAP is flexible, extensible, and ubiquitous, it's worth >>>>>considering >>>>>its application in diverse contexts. For example, what would others >>>>>think >>>>>of using CAP in conjunction with dispersing cybersecurity forensics >>>>>(think >>>>>IODEF or CAPEX) or vulnerability >>>>>information? If so, what is there some larger ontology that needs >>>>>to be developed? >>>>> >>>>>cheers, >>>>>tony >>>>> >>>>>-- >>>>>Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >>>>>703.999.8270 >>>>> >>>>> >>>>>_______________________________________________ >>>>>earlywarning mailing list >>>>>earlywarning@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/earlywarning >>>>_______________________________________________ >>>>earlywarning mailing list >>>>earlywarning@ietf.org >>>>https://www.ietf.org/mailman/listinfo/earlywarning >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > From rbarnes@bbn.com Fri May 1 12:07:23 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFA83A6C9C for ; Fri, 1 May 2009 12:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcx0Wv80b0iu for ; Fri, 1 May 2009 12:07:22 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 025563A6B82 for ; Fri, 1 May 2009 12:05:38 -0700 (PDT) Received: from [128.89.254.128] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Lzy4b-0007L3-ED; Fri, 01 May 2009 15:07:01 -0400 Message-ID: <49FB4855.4070305@bbn.com> Date: Fri, 01 May 2009 15:07:01 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "James M. Polk" References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:07:23 -0000 James, Protocols don't know about citizenship. At the protocol level, alert consumers are just message consumers with special requirements (immediacy, geographic targeting, etc). Point-to-point messaging is indeed our starting point: The point of this working group is to take existing IETF messaging protocols (e.g., SIP) and extend them to meet the requirements for delivering emergency messages: -- Strong, E2E authentication and authorization of alert originators -- E2E authentication and integrity-protection for alerts -- Delivery based on geolocation (and other constraints) -- Priority and preemption (?) -- Scalability (e.g., using multicast) --Richard James M. Polk wrote: > At 01:26 PM 5/1/2009, Richard Barnes wrote: >> Carl, >> >> Is there a common term in the OGC for this entity, one that this group >> could re-use? Did I actually guess right with "alert orginator"?? > > "alert-originator-to-who"? > > We just lost the latter half of this too, because "citizen" just went > out the window given Carl's description of > > "The sensor networks are integrated into some larger information > processing network (earthquake, tsunami, wildfire, etc)." > > Because the sensor information likely won't be consumer very often by > "citizens", but by government agencies, and research labs. > > We're moving closer towards "point-to-point-alerts", and losing the > concept of "authority" without the ability to verify who is the source > of the information, which I consider really dangerous - because it will > be misused. > > James > > >> --Richard >> >> >> >> Carl Reed wrote: >>> For what it is worth, what Richard is suggesting is the approach that >>> many in OGC implementation community use for providing alerts. >>> Typically, the alerting infrastructure, such as being developed for >>> numerous applications in Europe and Asia, supports multiple alert >>> payload encoding. The user (gov, citizen, whatever) subscribes to >>> alerts in the desired/required payload encoding . Authentication is a >>> key aspect of this process: Anyone subscribing to receive alerts is >>> authenticated in terms of what content can actually distributed to them. >>> As to the alert originator, we have the same issue: more and more >>> alerts are originating from sensor networks. The sensor networks are >>> integrated into some larger information processing network >>> (earthquake, tsunami, wildfire, etc). These "originator" systems may >>> be government, private, NGO, research/ University or some partnership. >>> Cheers >>> Carl >>> >>> ----- Original Message ----- From: "Richard Barnes" >>> To: "Brian Rosen" >>> Cc: >>> Sent: Friday, May 01, 2009 10:02 AM >>> Subject: Re: [earlywarning] global CAP community >>> >>>> I wonder if it might ultimately be a good idea to deprecate the word >>>> "authority" for the purposes of these technical discussions, in >>>> favor of a more neutral term. "Alert originator" or something like >>>> that. >>>> The only characteristics of the authority/originator that this group >>>> needs to care about are >>>> >>>> (1) That it's the source of alerts that the system distributes >>>> >>>> (2) That it will need to be able to authenticate to the distribution >>>> system (in order to support the application of authorization policies) >>>> >>>> Whether the entity that fulfills those criteria is a government, a >>>> corporation, or my Twitter feed really isn't important, as long as >>>> the appropriate credentials and policies have been set up. >>>> >>>> --Richard >>>> >>>> >>>> >>>> Brian Rosen wrote: >>>>> Thanks for the reference to X.1303. >>>>> >>>>> I think we need to confine our discussions on this list to >>>>> "authority to >>>>> citizen" (although that wording is changing), and our use of CAP >>>>> will be >>>>> limited to that context. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: earlywarning-bounces@ietf.org >>>>> [mailto:earlywarning-bounces@ietf.org] >>>>> On Behalf Of Tony Rutkowski >>>>> Sent: Thursday, April 30, 2009 5:54 PM >>>>> To: earlywarning@ietf.org >>>>> Subject: [earlywarning] global CAP community >>>>> >>>>> Hi all, >>>>> >>>>> Glad to see this working group get under way. There is a large and >>>>> diverse >>>>> global CAP community. >>>>> >>>>> Because the "authority" is often (but not always as Art notes) >>>>> government in >>>>> nature, or implemented pursuant to government requirements, the >>>>> intergovernmental - industry organizations like ITU-T have been >>>>> significantly involved. At the domestic level, legislation like >>>>> the US WARN >>>>> Act also affect these implementations. >>>>> >>>>> I have attached the ITU-T X-series version of CAP 1.1. It's a copy >>>>> of the >>>>> OASIS version, plus a translation into ASN.1 (for those who love >>>>> that syntax >>>>> or find it useful for compact applications). It's also what most >>>>> governmental authorities will reference in most jurisdictions. >>>>> >>>>> As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>>>> involved in this IETF WG and keep you apprised of things happening >>>>> there and >>>>> contribute to your work. >>>>> >>>>> Because CAP is flexible, extensible, and ubiquitous, it's worth >>>>> considering >>>>> its application in diverse contexts. For example, what would >>>>> others think >>>>> of using CAP in conjunction with dispersing cybersecurity forensics >>>>> (think >>>>> IODEF or CAPEX) or vulnerability >>>>> information? If so, what is there some larger ontology that needs >>>>> to be developed? >>>>> >>>>> cheers, >>>>> tony >>>>> >>>>> -- >>>>> Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >>>>> 703.999.8270 >>>>> >>>>> >>>>> _______________________________________________ >>>>> earlywarning mailing list >>>>> earlywarning@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/earlywarning >>>> _______________________________________________ >>>> earlywarning mailing list >>>> earlywarning@ietf.org >>>> https://www.ietf.org/mailman/listinfo/earlywarning >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > From trutkowski@netmagic.com Fri May 1 12:38:17 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB8DC28C1BF for ; Fri, 1 May 2009 12:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7qAm2vkSH2i for ; Fri, 1 May 2009 12:38:17 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id B41DC28C200 for ; Fri, 1 May 2009 12:37:22 -0700 (PDT) Received: from [192.168.1.4] ([72.86.34.21]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIZ00DHPD80RTLE@vms173017.mailsrvcs.net> for earlywarning@ietf.org; Fri, 01 May 2009 14:38:29 -0500 (CDT) Message-id: <49FB4FB0.6020706@netmagic.com> Date: Fri, 01 May 2009 15:38:24 -0400 From: Tony Rutkowski Organization: Netmagic Associates LLC User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: ken carlberg References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> <678745F2-9C68-4B90-895E-4F1151265620@g11.org.uk> In-reply-to: <678745F2-9C68-4B90-895E-4F1151265620@g11.org.uk> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:38:18 -0000 > Might I suggest "Authorized-originator to subscriber". I agree with > the notion (if not the exact wording) brought up by Richard that it > would be constructive to move away from the term "authority" since > that term gravitates most folks to a 1-to-1 association with > government, and that's not always the case with systems out there > today. And while I thought it was implied in Richard's posting, the > originator needs to have some measure of authority in originating a > message to the alerting system as James is stating in his posting. This seems like a good direction. The term "authority-to-citizen" is somewhat ETSI EMTEL centric and implies implementations that are generally obligatory under regulatory provisions in Europe. Your focus seems definitely much broader. --toont From jmpolk@cisco.com Fri May 1 12:54:23 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9543A6CB2 for ; Fri, 1 May 2009 12:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGNBMZISO5un for ; Fri, 1 May 2009 12:54:21 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 97CD33A6D8B for ; Fri, 1 May 2009 12:54:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="74258742" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 01 May 2009 19:55:44 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id n41Jti02017516; Fri, 1 May 2009 12:55:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n41JtiwI025365; Fri, 1 May 2009 19:55:44 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 12:55:44 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 12:55:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 14:55:39 -0500 To: "Carl Reed" , "Richard Barnes" From: "James M. Polk" In-Reply-To: References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 19:55:44.0069 (UTC) FILETIME=[D0056750:01C9CA96] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7927; t=1241207744; x=1242071744; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=8TDAtWLUD8rJObVlaMomY/S/XtpajGjHM/IT4pq6imY=; b=TN+N9ael/djrlyFufzU/j7q925+4NyQglm70K0hKLRgA9NTDIk1gNnrE4f rzPZFZQMTxvxhyCE73iHTblsFvK5luVt7wUWqnENboQRSJOkLOuLEWlNvJpg pn14YtNoO9; Authentication-Results: sj-dkim-8; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:54:23 -0000 Carl The sensors, as you've described them (which is nearly how I would have too BTW) feed into a system that then informs citizens, it is not the citizens that inform other citizens about alerts within the Indonesian Tsunami early warning system, is it? I get that the sensors feed their information into a collector (i.e., server) that then informs the masses. This isn't citizen to citizen ala Twitter. Nothing here prevents communications ala Twitter, but it isn't how we're going to define ATOCA's operational model, is it? I see the model you say last below as how I describe it, sensors to a server, which has some level of authority (even if that authority is the local university - at least there are supposed to be experts running that system). Citizens then access what the server puts out (i.e., they subscribe to it, to get the info. If they don't subscribe, they don't get the info). James At 02:04 PM 5/1/2009, Carl Reed wrote: >James - > >I do not think I said that the citizen is out of the loop. The end >user of these systems is often the citizen and not another >government agency. For example, in the Indonesian Tsunami early >warning system, ocean sensors provide measurements into a processing >environment that uses the sensor measurements along with other data >to model tsunami propagation for a given event. This information is >then used to generate the appropriate alerts to the appropriate >entities in the appropriate geographic region(s) including citizens. >My point is that sensors themselves may not generate an alert but >instead feed a workflow that does generate alerts. > >Also, the measurements generated many sensor networks are now >directly accessible to citizens - such as traffic alert data. > >Sorry for any confusion. > >Carl > >----- Original Message ----- From: "James M. Polk" >To: "Richard Barnes" ; "Carl Reed" >Cc: >Sent: Friday, May 01, 2009 12:45 PM >Subject: Re: [earlywarning] global CAP community > > >>At 01:26 PM 5/1/2009, Richard Barnes wrote: >>>Carl, >>> >>>Is there a common term in the OGC for this entity, one that this >>>group could re-use? Did I actually guess right with "alert orginator"?? >> >>"alert-originator-to-who"? >> >>We just lost the latter half of this too, because "citizen" just >>went out the window given Carl's description of >> >> "The sensor networks are integrated into some larger information >> processing network (earthquake, tsunami, wildfire, etc)." >> >>Because the sensor information likely won't be consumer very often >>by "citizens", but by government agencies, and research labs. >> >>We're moving closer towards "point-to-point-alerts", and losing the >>concept of "authority" without the ability to verify who is the >>source of the information, which I consider really dangerous - >>because it will be misused. >> >>James >> >> >>>--Richard >>> >>> >>> >>>Carl Reed wrote: >>>>For what it is worth, what Richard is suggesting is the approach >>>>that many in OGC implementation community use for providing >>>>alerts. Typically, the alerting infrastructure, such as being >>>>developed for numerous applications in Europe and Asia, supports >>>>multiple alert payload encoding. The user (gov, citizen, >>>>whatever) subscribes to alerts in the desired/required payload >>>>encoding . Authentication is a key aspect of this process: Anyone >>>>subscribing to receive alerts is authenticated in terms of what >>>>content can actually distributed to them. >>>>As to the alert originator, we have the same issue: more and more >>>>alerts are originating from sensor networks. The sensor networks >>>>are integrated into some larger information processing network >>>>(earthquake, tsunami, wildfire, etc). These "originator" systems >>>>may be government, private, NGO, research/ University or some partnership. >>>>Cheers >>>>Carl >>>> >>>>----- Original Message ----- From: "Richard Barnes" >>>>To: "Brian Rosen" >>>>Cc: >>>>Sent: Friday, May 01, 2009 10:02 AM >>>>Subject: Re: [earlywarning] global CAP community >>>> >>>>>I wonder if it might ultimately be a good idea to deprecate the >>>>>word "authority" for the purposes of these technical >>>>>discussions, in favor of a more neutral term. "Alert >>>>>originator" or something like that. >>>>>The only characteristics of the authority/originator that this >>>>>group needs to care about are >>>>> >>>>>(1) That it's the source of alerts that the system distributes >>>>> >>>>>(2) That it will need to be able to authenticate to the >>>>>distribution system (in order to support the application of >>>>>authorization policies) >>>>> >>>>>Whether the entity that fulfills those criteria is a government, >>>>>a corporation, or my Twitter feed really isn't important, as >>>>>long as the appropriate credentials and policies have been set up. >>>>> >>>>>--Richard >>>>> >>>>> >>>>> >>>>>Brian Rosen wrote: >>>>>>Thanks for the reference to X.1303. >>>>>> >>>>>>I think we need to confine our discussions on this list to "authority to >>>>>>citizen" (although that wording is changing), and our use of CAP will be >>>>>>limited to that context. >>>>>> >>>>>>Brian >>>>>> >>>>>>-----Original Message----- >>>>>>From: earlywarning-bounces@ietf.org >>>>>>[mailto:earlywarning-bounces@ietf.org] >>>>>>On Behalf Of Tony Rutkowski >>>>>>Sent: Thursday, April 30, 2009 5:54 PM >>>>>>To: earlywarning@ietf.org >>>>>>Subject: [earlywarning] global CAP community >>>>>> >>>>>>Hi all, >>>>>> >>>>>>Glad to see this working group get under way. There is a large >>>>>>and diverse >>>>>>global CAP community. >>>>>> >>>>>>Because the "authority" is often (but not always as Art notes) >>>>>>government in >>>>>>nature, or implemented pursuant to government requirements, the >>>>>>intergovernmental - industry organizations like ITU-T have been >>>>>>significantly involved. At the domestic level, legislation >>>>>>like the US WARN >>>>>>Act also affect these implementations. >>>>>> >>>>>>I have attached the ITU-T X-series version of CAP 1.1. It's a >>>>>>copy of the >>>>>>OASIS version, plus a translation into ASN.1 (for those who >>>>>>love that syntax >>>>>>or find it useful for compact applications). It's also what most >>>>>>governmental authorities will reference in most jurisdictions. >>>>>> >>>>>>As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>>>>>involved in this IETF WG and keep you apprised of things >>>>>>happening there and >>>>>>contribute to your work. >>>>>> >>>>>>Because CAP is flexible, extensible, and ubiquitous, it's worth >>>>>>considering >>>>>>its application in diverse contexts. For example, what would >>>>>>others think >>>>>>of using CAP in conjunction with dispersing cybersecurity >>>>>>forensics (think >>>>>>IODEF or CAPEX) or vulnerability >>>>>>information? If so, what is there some larger ontology that needs >>>>>>to be developed? >>>>>> >>>>>>cheers, >>>>>>tony >>>>>> >>>>>>-- >>>>>>Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >>>>>>703.999.8270 >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>earlywarning mailing list >>>>>>earlywarning@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/earlywarning >>>>>_______________________________________________ >>>>>earlywarning mailing list >>>>>earlywarning@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/earlywarning >>>_______________________________________________ >>>earlywarning mailing list >>>earlywarning@ietf.org >>>https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Fri May 1 12:59:35 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B093A6B58 for ; Fri, 1 May 2009 12:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzMJqLnc76c3 for ; Fri, 1 May 2009 12:59:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CCF303A6927 for ; Fri, 1 May 2009 12:59:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="296724838" Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 01 May 2009 20:00:58 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id n41K0wJ4004825; Fri, 1 May 2009 13:00:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n41K0wJP000332; Fri, 1 May 2009 20:00:58 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 13:00:58 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 13:00:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 15:00:53 -0500 To: Richard Barnes From: "James M. Polk" In-Reply-To: <49FB4855.4070305@bbn.com> References: <49FA1E10.6050101@netmagic.com> <088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> <49FB3ED6.9090107@bbn.com> <49FB4855.4070305@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 20:00:58.0275 (UTC) FILETIME=[8B4D6F30:01C9CA97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7203; t=1241208058; x=1242072058; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=DiFUYlegG8nm1z0Y1/wX4r7aarITau8g8lHey+V2z3M=; b=NpKKux4kzNtLLknGcDgJLn3WNtGqhfAbfFZF21G2F5dHYff9Opr3nxFTwl o4RNRwahfYprFcPZlRzWWFSR3Ec/eQs32m8++lulO4CPIPQSkMKuepfh08l5 AW1yB2KVQl; Authentication-Results: sj-dkim-5; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 19:59:36 -0000 At 02:07 PM 5/1/2009, Richard Barnes wrote: >James, > >Protocols don't know about citizenship. At the protocol level, >alert consumers are just message consumers with special requirements >(immediacy, geographic targeting, etc). Richard there is also the concept of accessibility (citizens might not have access, which is built into the protocol as "access can be limited to few"). There is also the concept of "this comes from an authoritative source" - though that's not strictly in the protocol, it can be explicit or implicit in who can distribute the info. Allowing this to run in the wild will only cause great harm, and send all governments into a frenzy with having to deal with our wildness in lack of scope. >Point-to-point messaging is indeed our starting point: The point of >this working group is to take existing IETF messaging protocols >(e.g., SIP) and extend them to meet the requirements for delivering >emergency messages: >-- Strong, E2E authentication and authorization of alert originators this makes me wonder how ordinary citizens will meet your scoping point #1 above? Is anything on Twitter verifyable? >-- E2E authentication and integrity-protection for alerts >-- Delivery based on geolocation (and other constraints) >-- Priority and preemption (?) >-- Scalability (e.g., using multicast) > >--Richard > > > > >James M. Polk wrote: >>At 01:26 PM 5/1/2009, Richard Barnes wrote: >>>Carl, >>> >>>Is there a common term in the OGC for this entity, one that this >>>group could re-use? Did I actually guess right with "alert orginator"?? >>"alert-originator-to-who"? >>We just lost the latter half of this too, because "citizen" just >>went out the window given Carl's description of >> "The sensor networks are integrated into some larger information >> processing network (earthquake, tsunami, wildfire, etc)." >>Because the sensor information likely won't be consumer very often >>by "citizens", but by government agencies, and research labs. >>We're moving closer towards "point-to-point-alerts", and losing the >>concept of "authority" without the ability to verify who is the >>source of the information, which I consider really dangerous - >>because it will be misused. >>James >> >>>--Richard >>> >>> >>> >>>Carl Reed wrote: >>>>For what it is worth, what Richard is suggesting is the approach >>>>that many in OGC implementation community use for providing >>>>alerts. Typically, the alerting infrastructure, such as being >>>>developed for numerous applications in Europe and Asia, supports >>>>multiple alert payload encoding. The user (gov, citizen, >>>>whatever) subscribes to alerts in the desired/required payload >>>>encoding . Authentication is a key aspect of this process: Anyone >>>>subscribing to receive alerts is authenticated in terms of what >>>>content can actually distributed to them. >>>>As to the alert originator, we have the same issue: more and more >>>>alerts are originating from sensor networks. The sensor networks >>>>are integrated into some larger information processing network >>>>(earthquake, tsunami, wildfire, etc). These "originator" systems >>>>may be government, private, NGO, research/ University or some partnership. >>>>Cheers >>>>Carl >>>> >>>>----- Original Message ----- From: "Richard Barnes" >>>>To: "Brian Rosen" >>>>Cc: >>>>Sent: Friday, May 01, 2009 10:02 AM >>>>Subject: Re: [earlywarning] global CAP community >>>> >>>>>I wonder if it might ultimately be a good idea to deprecate the >>>>>word "authority" for the purposes of these technical >>>>>discussions, in favor of a more neutral term. "Alert >>>>>originator" or something like that. >>>>>The only characteristics of the authority/originator that this >>>>>group needs to care about are >>>>> >>>>>(1) That it's the source of alerts that the system distributes >>>>> >>>>>(2) That it will need to be able to authenticate to the >>>>>distribution system (in order to support the application of >>>>>authorization policies) >>>>> >>>>>Whether the entity that fulfills those criteria is a government, >>>>>a corporation, or my Twitter feed really isn't important, as >>>>>long as the appropriate credentials and policies have been set up. >>>>> >>>>>--Richard >>>>> >>>>> >>>>> >>>>>Brian Rosen wrote: >>>>>>Thanks for the reference to X.1303. >>>>>> >>>>>>I think we need to confine our discussions on this list to "authority to >>>>>>citizen" (although that wording is changing), and our use of CAP will be >>>>>>limited to that context. >>>>>> >>>>>>Brian >>>>>> >>>>>>-----Original Message----- >>>>>>From: earlywarning-bounces@ietf.org >>>>>>[mailto:earlywarning-bounces@ietf.org] >>>>>>On Behalf Of Tony Rutkowski >>>>>>Sent: Thursday, April 30, 2009 5:54 PM >>>>>>To: earlywarning@ietf.org >>>>>>Subject: [earlywarning] global CAP community >>>>>> >>>>>>Hi all, >>>>>> >>>>>>Glad to see this working group get under way. There is a large >>>>>>and diverse >>>>>>global CAP community. >>>>>> >>>>>>Because the "authority" is often (but not always as Art notes) >>>>>>government in >>>>>>nature, or implemented pursuant to government requirements, the >>>>>>intergovernmental - industry organizations like ITU-T have been >>>>>>significantly involved. At the domestic level, legislation >>>>>>like the US WARN >>>>>>Act also affect these implementations. >>>>>> >>>>>>I have attached the ITU-T X-series version of CAP 1.1. It's a >>>>>>copy of the >>>>>>OASIS version, plus a translation into ASN.1 (for those who >>>>>>love that syntax >>>>>>or find it useful for compact applications). It's also what most >>>>>>governmental authorities will reference in most jurisdictions. >>>>>> >>>>>>As the rapporteur of working group Q.4/17 in ITU-T, I'll try and stay >>>>>>involved in this IETF WG and keep you apprised of things >>>>>>happening there and >>>>>>contribute to your work. >>>>>> >>>>>>Because CAP is flexible, extensible, and ubiquitous, it's worth >>>>>>considering >>>>>>its application in diverse contexts. For example, what would >>>>>>others think >>>>>>of using CAP in conjunction with dispersing cybersecurity >>>>>>forensics (think >>>>>>IODEF or CAPEX) or vulnerability >>>>>>information? If so, what is there some larger ontology that needs >>>>>>to be developed? >>>>>> >>>>>>cheers, >>>>>>tony >>>>>> >>>>>>-- >>>>>>Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >>>>>>703.999.8270 >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>earlywarning mailing list >>>>>>earlywarning@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/earlywarning >>>>>_______________________________________________ >>>>>earlywarning mailing list >>>>>earlywarning@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/earlywarning >>>_______________________________________________ >>>earlywarning mailing list >>>earlywarning@ietf.org >>>https://www.ietf.org/mailman/listinfo/earlywarning From jgunn6@csc.com Fri May 1 13:19:50 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5873A6C51; Fri, 1 May 2009 13:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXEpjmDkua3M; Fri, 1 May 2009 13:19:49 -0700 (PDT) Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.242.83]) by core3.amsl.com (Postfix) with ESMTP id BEC123A6943; Fri, 1 May 2009 13:19:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-63.messagelabs.com!1241209268!99088074!2 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 9100 invoked from network); 1 May 2009 20:21:09 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-63.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2009 20:21:09 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n41KL8jX003352; Fri, 1 May 2009 16:21:09 -0400 In-Reply-To: <49FB4855.4070305@bbn.com> To: Richard Barnes MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Fri, 1 May 2009 16:21:06 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/01/2009 04:23:12 PM, Serialize complete at 05/01/2009 04:23:12 PM Content-Type: multipart/alternative; boundary="=_alternative 006FCB70852575A9_=" Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:19:50 -0000 This is a multipart message in MIME format. --=_alternative 006FCB70852575A9_= Content-Type: text/plain; charset="US-ASCII" earlywarning-bounces@ietf.org wrote on 05/01/2009 03:07:01 PM: > James, > > Protocols don't know about citizenship. At the protocol level, alert > consumers are just message consumers with special requirements > (immediacy, geographic targeting, etc). > Perhaps "resident". My "citizenship" and my "residence" are thousands of miles apart. Janet > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning --=_alternative 006FCB70852575A9_= Content-Type: text/html; charset="US-ASCII"



earlywarning-bounces@ietf.org wrote on 05/01/2009 03:07:01 PM:

> James,
>
> Protocols don't know about citizenship.  At the protocol level, alert
> consumers are just message consumers with special requirements
> (immediacy, geographic targeting, etc).
>
Perhaps "resident". My "citizenship" and my "residence" are thousands of miles apart.

Janet
> _______________________________________________
> earlywarning mailing list
> earlywarning@ietf.org
> https://www.ietf.org/mailman/listinfo/earlywarning
 --=_alternative 006FCB70852575A9_=-- From jgunn6@csc.com Fri May 1 13:22:44 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E079B3A708D; Fri, 1 May 2009 13:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8guGqD0yGkDm; Fri, 1 May 2009 13:22:44 -0700 (PDT) Received: from mail64.messagelabs.com (mail64.messagelabs.com [216.82.249.227]) by core3.amsl.com (Postfix) with ESMTP id D7D1C3A70D9; Fri, 1 May 2009 13:21:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-64.messagelabs.com!1241209395!99196993!3 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 10816 invoked from network); 1 May 2009 20:23:17 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-6.tower-64.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 May 2009 20:23:17 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n41KNEPw011777; Fri, 1 May 2009 16:23:17 -0400 In-Reply-To: <49FB4855.4070305@bbn.com> To: Richard Barnes MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Fri, 1 May 2009 16:23:14 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/01/2009 04:25:20 PM, Serialize complete at 05/01/2009 04:25:20 PM Content-Type: multipart/alternative; boundary="=_alternative 006FFD5F852575A9_=" Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:22:45 -0000 This is a multipart message in MIME format. --=_alternative 006FFD5F852575A9_= Content-Type: text/plain; charset="US-ASCII" earlywarning-bounces@ietf.org wrote on 05/01/2009 03:07:01 PM: > James, > > Protocols don't know about citizenship. At the protocol level, alert > consumers are just message consumers with special requirements > (immediacy, geographic targeting, etc). > > Point-to-point messaging is indeed our starting point: The point of this > working group is to take existing IETF messaging protocols (e.g., SIP) > and extend them to meet the requirements for delivering emergency messages: > -- Strong, E2E authentication and authorization of alert originators > -- E2E authentication and integrity-protection for alerts > -- Delivery based on geolocation (and other constraints) > -- Priority and preemption (?) What are you planning to preempt? Janet > -- Scalability (e.g., using multicast) > > --Richard > > > --=_alternative 006FFD5F852575A9_= Content-Type: text/html; charset="US-ASCII"

earlywarning-bounces@ietf.org wrote on 05/01/2009 03:07:01 PM:

> James,
>
> Protocols don't know about citizenship.  At the protocol level, alert
> consumers are just message consumers with special requirements
> (immediacy, geographic targeting, etc).
>
> Point-to-point messaging is indeed our starting point: The point of this
> working group is to take existing IETF messaging protocols (e.g., SIP)
> and extend them to meet the requirements for delivering emergency messages:
> -- Strong, E2E authentication and authorization of alert originators
> -- E2E authentication and integrity-protection for alerts
> -- Delivery based on geolocation (and other constraints)
> -- Priority and preemption (?)

What are you planning to preempt?

Janet

> -- Scalability (e.g., using multicast)
>
> --Richard
>
>
> --=_alternative 006FFD5F852575A9_=-- From jmpolk@cisco.com Fri May 1 14:18:13 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC4A3A691D; Fri, 1 May 2009 14:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3zF3NPee4NL; Fri, 1 May 2009 14:18:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 209063A7005; Fri, 1 May 2009 14:18:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="296767246" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 May 2009 21:19:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n41LJadG030366; Fri, 1 May 2009 14:19:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41LJaqb004538; Fri, 1 May 2009 21:19:36 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 14:19:35 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 14:19:35 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 16:19:31 -0500 To: Janet P Gunn , Richard Barnes From: "James M. Polk" In-Reply-To: References: <49FB4855.4070305@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 21:19:35.0589 (UTC) FILETIME=[870A6D50:01C9CAA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1211; t=1241212776; x=1242076776; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=kl0zJJF3dUM+Sko0k0M4S6otiMBzKRw2DzMas/08pmM=; b=1T8ccooeWed3rvIIVehvS6pn1T3qi4JjDx3iZ0Fh7wUa5SfOupxC7dzaqD sYc2xX4SO2T+pAJOx+ffMfKCi1FhreA2xzwlEojSbGh7IsbPSeN156QohyO7 iDvznhfFY5; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:18:13 -0000 At 03:23 PM 5/1/2009, Janet P Gunn wrote: >earlywarning-bounces@ietf.org wrote on 05/01/2009 03:07:01 PM: > > > James, > > > > Protocols don't know about citizenship. At the protocol level, alert > > consumers are just message consumers with special requirements > > (immediacy, geographic targeting, etc). > > > > Point-to-point messaging is indeed our starting point: The point of this > > working group is to take existing IETF messaging protocols (e.g., SIP) > > and extend them to meet the requirements for delivering emergency messages: > > -- Strong, E2E authentication and authorization of alert originators > > -- E2E authentication and integrity-protection for alerts > > -- Delivery based on geolocation (and other constraints) > > -- Priority and preemption (?) > >What are you planning to preempt? I was wondering the same thing, as priority seems natural (wrt server resources, and indication of the type of message), but this is never going to be a stream, so I don't think we'll likely have 1 message preempt another (but we may delay one message relative to another). >Janet > > > -- Scalability (e.g., using multicast) > > > > --Richard > > > > > > From trutkowski@netmagic.com Fri May 1 14:36:11 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E053E3A6929; Fri, 1 May 2009 14:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkS22uv1q16H; Fri, 1 May 2009 14:36:11 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 8CA1E3A6822; Fri, 1 May 2009 14:35:38 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KIZ00CYPIPIFDQS@vms173017.mailsrvcs.net>; Fri, 01 May 2009 16:36:55 -0500 (CDT) Message-id: <49FB6B76.5080406@netmagic.com> Date: Fri, 01 May 2009 17:36:54 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: "James M. Polk" References: <49FB4855.4070305@bbn.com> In-reply-to: Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 21:36:12 -0000 > I was wondering the same thing, as priority seems natural (wrt server > resources, and indication of the type of message), but this is never > going to be a stream, so I don't think we'll likely have 1 message > preempt another (but we may delay one message relative to another). In many cases, this will be dictated by national regulatory authorities or legislative requirements. In the U.S., for example, under the WARN Act, presidential messages preempt all others. In addition, when the FCC or other authorities specify certain NS/EP conditions, preemption actually occurs. --tony From jmpolk@cisco.com Fri May 1 15:51:08 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2644C3A67E1; Fri, 1 May 2009 15:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOVrdMmWX-pa; Fri, 1 May 2009 15:51:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1B4C03A69DA; Fri, 1 May 2009 15:50:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,280,1238976000"; d="scan'208";a="161169193" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 01 May 2009 22:52:10 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n41MqANM000514; Fri, 1 May 2009 15:52:10 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n41MqAVm002591; Fri, 1 May 2009 22:52:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 15:52:09 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.19.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 15:52:09 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 01 May 2009 17:52:05 -0500 To: trutkowski@netmagic.com From: "James M. Polk" In-Reply-To: <49FB6B76.5080406@netmagic.com> References: <49FB4855.4070305@bbn.com> <49FB6B76.5080406@netmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2009 22:52:09.0417 (UTC) FILETIME=[75615390:01C9CAAF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1132; t=1241218330; x=1242082330; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=AIhU1Z/yDiDFhrKnA6RVGhcCcVC9AdKjrQs84HVf/5o=; b=SCKEQV2yrGIwGY/uqTRhwGdd+drPjCm04WhzxiMannCz8RE2WYnuuxtE+E /6Ec0fzibCgLU/TA1uMnFRrdxzhP7enrEbR4mnA/rQeDu+jC1apdiy2YT7Za TCikV1tphT; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 22:51:08 -0000 At 04:36 PM 5/1/2009, Tony Rutkowski wrote: > > I was wondering the same thing, as priority seems natural (wrt server > > resources, and indication of the type of message), but this is never > > going to be a stream, so I don't think we'll likely have 1 message > > preempt another (but we may delay one message relative to another). >In many cases, this will be dictated by national regulatory >authorities or legislative requirements. In the U.S., for >example, under the WARN Act, presidential messages >preempt all others. In addition, when the FCC or other >authorities specify certain NS/EP conditions, preemption >actually occurs. hmmmm.... NS/EP means preemption....? I'll let Janet comment on that - since she works for NCS (who run GETS). I'm curious about this line too "In the U.S., for example, under the WARN Act, presidential messages preempt all others." The WARN act isn't about real-time communications, so why is there any need for preemption? Why not just store-and-forward (i.e., delay) the messages of lower priority than the president's? James >--tony From jgunn6@csc.com Fri May 1 18:52:00 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 443A13A67B4; Fri, 1 May 2009 18:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXKXlMe6aUYT; Fri, 1 May 2009 18:51:59 -0700 (PDT) Received: from mail168.messagelabs.com (mail168.messagelabs.com [216.82.253.195]) by core3.amsl.com (Postfix) with ESMTP id 1DAB83A6811; Fri, 1 May 2009 18:51:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-168.messagelabs.com!1241229201!7904906!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 3700 invoked from network); 2 May 2009 01:53:21 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-2.tower-168.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2009 01:53:21 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.3mp/Switch-3.3.3mp) with ESMTP id n421rKjd024078; Fri, 1 May 2009 21:53:21 -0400 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Fri, 1 May 2009 21:53:18 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/01/2009 09:55:24 PM, Serialize complete at 05/01/2009 09:55:24 PM Content-Type: multipart/alternative; boundary="=_alternative 000A5F7C852575AA_=" Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 01:52:00 -0000 This is a multipart message in MIME format. --=_alternative 000A5F7C852575AA_= Content-Type: text/plain; charset="US-ASCII" "James M. Polk" wrote on 05/01/2009 06:52:05 PM: > At 04:36 PM 5/1/2009, Tony Rutkowski wrote: > > > I was wondering the same thing, as priority seems natural (wrt server > > > resources, and indication of the type of message), but this is never > > > going to be a stream, so I don't think we'll likely have 1 message > > > preempt another (but we may delay one message relative to another). > >In many cases, this will be dictated by national regulatory > >authorities or legislative requirements. In the U.S., for > >example, under the WARN Act, presidential messages > >preempt all others. In addition, when the FCC or other > >authorities specify certain NS/EP conditions, preemption > >actually occurs. > > hmmmm.... NS/EP means preemption....? > > I'll let Janet comment on that - since she works for NCS (who run GETS). IFF the war powers act were invoked, then preemption would be permitted. But, in situations not triggering the war powers act- which is the "real world" situation we actually deal with- the Service Providers will not permit preemption of voice communication. This is not because there is an actual stated ban on preemption, but because of the concern that a person whose (life or death) call was preempted could sue under the terms of the Telecommunications Act, and they would have no defense. None of the deployed NS/EP programs I am aware of (including the ones I am not supposed to talk about) use preemption. Queueing, alternate routing, exemption from network controls, exemption from load shedding- they are all part of the NS/EP programs. But not preemption. But that is beside the point. In "earlywarning" we are talking about "messages", not "calls" or even "sessions". What is it that you are going to "preempt"? Sure, if it is a voice message you are sending, you could interrupt the message to send some other message. But then you would just resend the original message later. Delayed, but not preempted. Janet > > I'm curious about this line too > > "In the U.S., for example, under the WARN Act, > presidential messages preempt all others." > > The WARN act isn't about real-time communications, so why is there > any need for preemption? Why not just store-and-forward (i.e., delay) > the messages of lower priority than the president's? > > James > > > >--tony > --=_alternative 000A5F7C852575AA_= Content-Type: text/html; charset="US-ASCII"


"James M. Polk" <jmpolk@cisco.com> wrote on 05/01/2009 06:52:05 PM:

> At 04:36 PM 5/1/2009, Tony Rutkowski wrote:
> > > I was wondering the same thing, as priority seems natural (wrt server
> > > resources, and indication of the type of message), but this is never
> > > going to be a stream, so I don't think we'll likely have 1 message
> > > preempt another (but we may delay one message relative to another).
> >In many cases, this will be dictated by national regulatory
> >authorities or legislative requirements. In the U.S., for
> >example, under the WARN Act, presidential messages
> >preempt all others. In addition, when the FCC or other
> >authorities specify certain NS/EP conditions, preemption
> >actually occurs.
>
> hmmmm.... NS/EP means preemption....?
>
> I'll let Janet comment on that - since she works for NCS (who run GETS).

IFF the war powers act were invoked, then preemption would be permitted.

But, in situations not triggering the war powers act- which is the "real world" situation we actually deal with- the Service Providers will not permit preemption of voice communication.  This is not because there is an actual stated ban on preemption, but because of the concern that a person whose (life or death) call was preempted could sue under the terms of the Telecommunications Act, and they would have no defense.

None of the deployed NS/EP programs I am aware of (including the ones I am not supposed to talk about) use preemption.  Queueing, alternate routing, exemption from network controls, exemption from load shedding- they are all part of the NS/EP programs.  But not preemption.

But that is beside the point.

In "earlywarning" we are talking about "messages", not "calls" or even "sessions". What is it that you are going to "preempt"?  Sure, if it is a voice message you are sending, you could interrupt the message to send some other message.  But then you would just resend the original message later.  Delayed, but not preempted.
 Janet
>
> I'm curious about this line too
>
>          "In the U.S., for example, under the WARN Act,
>          presidential messages preempt all others."
>
> The WARN act isn't about real-time communications, so why is there
> any need for preemption? Why not just store-and-forward (i.e., delay)
> the messages of lower priority than the president's?
>
> James
>
>
> >--tony
>
--=_alternative 000A5F7C852575AA_=-- From Hannes.Tschofenig@gmx.net Sat May 2 02:12:44 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5032D28C10C for ; Sat, 2 May 2009 02:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM5LHLsX+TDE for ; Sat, 2 May 2009 02:12:43 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id ED7C828C1DF for ; Sat, 2 May 2009 02:12:01 -0700 (PDT) Received: (qmail invoked by alias); 02 May 2009 09:13:24 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp003) with SMTP; 02 May 2009 11:13:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/q+lsAI73qPtR4cbveSzRsmJYfCSFNhYXjOTWfN6 7cw9gymPuzSVAd From: "Hannes Tschofenig" To: "'Richard Barnes'" , "'Brian Rosen'" References: <49FA1E10.6050101@netmagic.com><088c01c9ca67$08bc9a30$1a35ce90$@net> <49FB1CFB.4050708@bbn.com> Date: Sat, 2 May 2009 12:14:59 +0300 Message-ID: <017001c9cb06$78c8aef0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnKdl16AIvq/ALoTpKgQZt2KKh/6AAj0pbg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49FB1CFB.4050708@bbn.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: earlywarning@ietf.org Subject: [earlywarning] Depricate "Authority" - was : global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 09:12:44 -0000 I agree with Richard. In my presentation during the BOF I have already used different terminology based on off-line conversations with Carl and Art about this topic. Please find our presentation here: http://www.tschofenig.priv.at/atoca/architecture.ppt I suggest to generalize the subject a bit and propose the following modifications: * replace "early warning" with "Exigent Communications" * use terminology from draft-crocker-email-arch and modify it slightly, see Slide 5 in our slide set I would like to make these changes to draft-norreys-ecrit-authority2individuals-requirements ASAP. Ciao Hannes >-----Original Message----- >From: earlywarning-bounces@ietf.org >[mailto:earlywarning-bounces@ietf.org] On Behalf Of Richard Barnes >Sent: 01 May, 2009 19:02 >To: Brian Rosen >Cc: earlywarning@ietf.org >Subject: Re: [earlywarning] global CAP community > >I wonder if it might ultimately be a good idea to deprecate >the word "authority" for the purposes of these technical >discussions, in favor of a more neutral term. "Alert >originator" or something like that. The only characteristics >of the authority/originator that this group needs to care about are > >(1) That it's the source of alerts that the system distributes > >(2) That it will need to be able to authenticate to the >distribution system (in order to support the application of >authorization policies) > >Whether the entity that fulfills those criteria is a >government, a corporation, or my Twitter feed really isn't >important, as long as the appropriate credentials and policies >have been set up. > >--Richard > > > >Brian Rosen wrote: >> Thanks for the reference to X.1303. >> >> I think we need to confine our discussions on this list to >"authority >> to citizen" (although that wording is changing), and our use of CAP >> will be limited to that context. >> >> Brian >> >> -----Original Message----- >> From: earlywarning-bounces@ietf.org >> [mailto:earlywarning-bounces@ietf.org] >> On Behalf Of Tony Rutkowski >> Sent: Thursday, April 30, 2009 5:54 PM >> To: earlywarning@ietf.org >> Subject: [earlywarning] global CAP community >> >> Hi all, >> >> Glad to see this working group get under way. There is a large and >> diverse global CAP community. >> >> Because the "authority" is often (but not always as Art notes) >> government in nature, or implemented pursuant to government >> requirements, the intergovernmental - industry organizations like >> ITU-T have been significantly involved. At the domestic level, >> legislation like the US WARN Act also affect these implementations. >> >> I have attached the ITU-T X-series version of CAP 1.1. It's >a copy of >> the OASIS version, plus a translation into ASN.1 (for those who love >> that syntax or find it useful for compact applications). It's also >> what most governmental authorities will reference in most >jurisdictions. >> >> As the rapporteur of working group Q.4/17 in ITU-T, I'll try >and stay >> involved in this IETF WG and keep you apprised of things happening >> there and contribute to your work. >> >> Because CAP is flexible, extensible, and ubiquitous, it's worth >> considering its application in diverse contexts. For example, what >> would others think of using CAP in conjunction with dispersing >> cybersecurity forensics (think IODEF or CAPEX) or vulnerability >> information? If so, what is there some larger ontology that needs >> to be developed? >> >> cheers, >> tony >> >> -- >> Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 >> 703.999.8270 >> >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > From Hannes.Tschofenig@gmx.net Sat May 2 02:47:38 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 975253A6B78 for ; Sat, 2 May 2009 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa-s-eVDAmT0 for ; Sat, 2 May 2009 02:47:37 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E01AD3A6D87 for ; Sat, 2 May 2009 02:46:56 -0700 (PDT) Received: (qmail invoked by alias); 02 May 2009 09:48:18 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp003) with SMTP; 02 May 2009 11:48:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19oJ6RBqU1oQ8sdwUVtCbKhk9kJUn9zilNW9xv1hY ToxsAbxJS30e6H From: "Hannes Tschofenig" To: Date: Sat, 2 May 2009 12:49:54 +0300 Message-ID: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnLC1hPlp66gI2dRnC1oxhGYtgWJg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.71 Subject: [earlywarning] Some further scoping issues X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 09:47:38 -0000 For the future work in this group I furthermore suggest that * we do not focus our efforts on defining an architecture used for distributing of alert messages (like we did it in ECRIT with the PhoneBCP/Framework document). Instead, we develop building blocks (like conveying CAP in SIP). I believe we will run into lots of problems with the different usages, different solutions that have been specified elsewhere already, etc. * we do not pick a single alert document format (as a mandatory-to-implement), like CAP or GeoRSS, but instead give those who deploy these mechanisms freedom. * we do not define our own alert document format (because there are other formats available already). We can always decide later to document ways how people use our stuff. Ciao Hannes From jgunn6@csc.com Sat May 2 03:25:02 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D9B3A6A8C; Sat, 2 May 2009 03:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.483 X-Spam-Level: X-Spam-Status: No, score=-6.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A34r4X1QfCl; Sat, 2 May 2009 03:25:01 -0700 (PDT) Received: from mail94.messagelabs.com (mail94.messagelabs.com [216.82.241.179]) by core3.amsl.com (Postfix) with ESMTP id 74B6E3A6893; Sat, 2 May 2009 03:25:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-12.tower-94.messagelabs.com!1241259983!74843757!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 14049 invoked from network); 2 May 2009 10:26:23 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-12.tower-94.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2009 10:26:23 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n42AQMPx016485; Sat, 2 May 2009 06:26:22 -0400 In-Reply-To: <017001c9cb06$78c8aef0$0301a8c0@nsnintra.net> To: "Hannes Tschofenig" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Sat, 2 May 2009 06:26:13 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 05/02/2009 06:28:25 AM, Serialize complete at 05/02/2009 06:28:25 AM Content-Type: multipart/alternative; boundary="=_alternative 003954D3852575AA_=" Cc: earlywarning-bounces@ietf.org, earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 10:25:02 -0000 This is a multipart message in MIME format. --=_alternative 003954D3852575AA_= Content-Type: text/plain; charset="US-ASCII" earlywarning-bounces@ietf.org wrote on 05/02/2009 05:14:59 AM: > I suggest to generalize the subject a bit and propose the following > modifications: > > * replace "early warning" with "Exigent Communications" I think that is a bad idea. How many people here know PRECISELY what "exigent" means without looking it up. You need a term that has wider comprehension. Janet --=_alternative 003954D3852575AA_= Content-Type: text/html; charset="US-ASCII"



earlywarning-bounces@ietf.org wrote on 05/02/2009 05:14:59 AM:


> I suggest to generalize the subject a bit and propose the following
> modifications:
>  
> * replace "early warning" with "Exigent Communications"
I think that is a bad idea.

How many people here know PRECISELY what "exigent" means without looking it up.

You need a term that has wider comprehension.

Janet --=_alternative 003954D3852575AA_=-- From trutkowski@netmagic.com Sat May 2 05:07:36 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13E393A679C for ; Sat, 2 May 2009 05:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeWIuOj97MvO for ; Sat, 2 May 2009 05:07:35 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 9C6FA3A688B for ; Sat, 2 May 2009 05:07:29 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KJ0001CNN2FKNVM@vms173003.mailsrvcs.net> for earlywarning@ietf.org; Sat, 02 May 2009 07:08:43 -0500 (CDT) Message-id: <49FC37C7.6050504@netmagic.com> Date: Sat, 02 May 2009 08:08:39 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Hannes Tschofenig References: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> In-reply-to: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Some further scoping issues X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 12:07:36 -0000 These seem like good admonitions. The broader scope will provide greater value to work, rather than attempting to deal a specific kind of implementation that gets into an already well-established regulatory domain. For those of you unfamiliar with the new FCC Part 10 rules specifying Commercial Mobile Alert System (CMAS) implementations, they are available at http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&rgn=div5&view=text&node=47:1.0.1.1.10&idno=47 For U.S. implementations, note that 47 CFR Sec. 10.410 requires that "Presidential Alerts preempt all other Alert Messages." ciao, --tony > For the future work in this group I furthermore suggest that > > * we do not focus our efforts on defining an architecture used for > distributing of alert messages (like we did it in ECRIT with the > PhoneBCP/Framework document). Instead, we develop building blocks (like > conveying CAP in SIP). I believe we will run into lots of problems with the > different usages, different solutions that have been specified elsewhere > already, etc. > > * we do not pick a single alert document format (as a > mandatory-to-implement), like CAP or GeoRSS, but instead give those who > deploy these mechanisms freedom. > > * we do not define our own alert document format (because there are other > formats available already). > > We can always decide later to document ways how people use our stuff. > From acb@incident.com Sat May 2 08:49:50 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA5A3A6DF7 for ; Sat, 2 May 2009 08:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGIgkPrau-X0 for ; Sat, 2 May 2009 08:49:49 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 4087E3A6DF0 for ; Sat, 2 May 2009 08:49:49 -0700 (PDT) Received: (qmail 58176 invoked from network); 2 May 2009 15:51:13 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 2 May 2009 15:51:13 -0000 X-YMail-OSG: sBoGF9UVM1ksbk9H3HlriOJ24217jrhc06vKz2njN_JJZBErDf8uQJBqAJkg0PHA6OjKVs9UHwfL.hLDDQEplNzj_iqRU0C2sYRp1B15kikaqAl2Da1K1cLQcZEfJXl7mljvO260An8ULLnYpSBN8fyRH0oPP18QHxqH9eFID0buh_Z0kC4xO8gDxvaxGyMyz5tJi53ItQbIeBh3xZhBcGSCcdW0cLI7M9uIQRyA8JMAm44KuseBo6L.anhULkOnQjCp53gJGi7qUQg- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id 88BBE1C833DC for ; Sat, 2 May 2009 08:51:11 -0700 (PDT) Message-Id: <7434877D-2255-4AFB-BD89-D6F04DFB1D8A@incident.com> From: Art Botterell To: earlywarning@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 2 May 2009 08:51:10 -0700 References: X-Mailer: Apple Mail (2.930.3) Subject: Re: [earlywarning] Depricate "Authority" - was : global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 15:49:50 -0000 On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: > How many people here know PRECISELY what "exigent" means without > looking it up. > > You need a term that has wider comprehension. Unfortunately, not many folks know precisely what "early warning" means either, although many assume they do until you press them for specifics. It seems like the current terms of reference are heavily loaded with emotional and cultural baggage. That's the problem with the word "authority"... it has several different senses and ultimately involves a subjective, or at least individual, interpretation of who and what constitutes authority (Government? Church? Academe? Culture?) "Warning" is likewise a fairly subtle notion when you really start to unpack it. In my particular public warning system we define it narrowly as "information about imminent threats to human life or health"... but other practitioners frame it differently. The word also spans the distinct domains of attention-management and information-sharing (is it a warning if folks are already aware of the subject matter?) So I'm wondering... might it be more productive to specify the particular observable characteristics we're concerned about (latency, reliability, verifiability, etc.) we're hoping to achieve rather than sloshing around in non-technical semantics? I get the sense that at least some of us are primarily concerned with the use of SIP, and although I have no personal investment in that particular approach, at least it sounds like the frame for a tractable technical problem. - Art From mdolly@att.com Sat May 2 12:37:16 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A6F3A6BC6 for ; Sat, 2 May 2009 12:37:16 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tLrb-Ybn1LQ for ; Sat, 2 May 2009 12:37:15 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id E5F983A6A0A for ; Sat, 2 May 2009 12:37:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-4.tower-167.messagelabs.com!1241293116!10059100!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 14467 invoked from network); 2 May 2009 19:38:36 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 May 2009 19:38:36 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42JcZ6x006605 for ; Sat, 2 May 2009 15:38:35 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n42JcU7S006596 for ; Sat, 2 May 2009 15:38:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 2 May 2009 15:38:30 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [earlywarning] Depricate "Authority" - was : global CAPcommunity Thread-Index: AcnLPdjSbjBNz2OYR76RKw/lllTdUwAH7lfa From: "DOLLY, MARTIN C, ATTLABS" To: , Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 19:37:16 -0000 QXV0aG9yaXR5IGlzIGdvdmVybm1lbnQNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K RnJvbTogZWFybHl3YXJuaW5nLWJvdW5jZXNAaWV0Zi5vcmcgPGVhcmx5d2FybmluZy1ib3VuY2Vz QGlldGYub3JnPg0KVG86IGVhcmx5d2FybmluZ0BpZXRmLm9yZyA8ZWFybHl3YXJuaW5nQGlldGYu b3JnPg0KU2VudDogU2F0IE1heSAwMiAxMTo1MToxMCAyMDA5DQpTdWJqZWN0OiBSZTogW2Vhcmx5 d2FybmluZ10gRGVwcmljYXRlICJBdXRob3JpdHkiIC0gd2FzIDogZ2xvYmFsIENBUGNvbW11bml0 eQ0KDQpPbiBNYXkgMiwgMjAwOSwgYXQgNS8yLzA5IDM6MjYgQU0sIEphbmV0IFAgR3VubiB3cm90 ZToNCg0KPiBIb3cgbWFueSBwZW9wbGUgaGVyZSBrbm93IFBSRUNJU0VMWSB3aGF0ICJleGlnZW50 IiBtZWFucyB3aXRob3V0ICANCj4gbG9va2luZyBpdCB1cC4NCj4NCj4gWW91IG5lZWQgYSB0ZXJt IHRoYXQgaGFzIHdpZGVyIGNvbXByZWhlbnNpb24uDQoNClVuZm9ydHVuYXRlbHksIG5vdCBtYW55 IGZvbGtzIGtub3cgcHJlY2lzZWx5IHdoYXQgImVhcmx5IHdhcm5pbmciICANCm1lYW5zIGVpdGhl ciwgYWx0aG91Z2ggbWFueSBhc3N1bWUgdGhleSBkbyB1bnRpbCB5b3UgcHJlc3MgdGhlbSBmb3Ig IA0Kc3BlY2lmaWNzLg0KDQpJdCBzZWVtcyBsaWtlIHRoZSBjdXJyZW50IHRlcm1zIG9mIHJlZmVy ZW5jZSBhcmUgaGVhdmlseSBsb2FkZWQgd2l0aCAgDQplbW90aW9uYWwgYW5kIGN1bHR1cmFsIGJh Z2dhZ2UuICBUaGF0J3MgdGhlIHByb2JsZW0gd2l0aCB0aGUgd29yZCAgDQoiYXV0aG9yaXR5Ii4u LiBpdCBoYXMgc2V2ZXJhbCBkaWZmZXJlbnQgc2Vuc2VzIGFuZCB1bHRpbWF0ZWx5IGludm9sdmVz ICANCmEgc3ViamVjdGl2ZSwgb3IgYXQgbGVhc3QgaW5kaXZpZHVhbCwgaW50ZXJwcmV0YXRpb24g b2Ygd2hvIGFuZCB3aGF0ICANCmNvbnN0aXR1dGVzIGF1dGhvcml0eSAoR292ZXJubWVudD8gQ2h1 cmNoPyBBY2FkZW1lPyBDdWx0dXJlPykNCg0KIldhcm5pbmciIGlzIGxpa2V3aXNlIGEgZmFpcmx5 IHN1YnRsZSBub3Rpb24gd2hlbiB5b3UgcmVhbGx5IHN0YXJ0IHRvICANCnVucGFjayBpdC4gIElu IG15IHBhcnRpY3VsYXIgcHVibGljIHdhcm5pbmcgc3lzdGVtIHdlIGRlZmluZSBpdCAgDQpuYXJy b3dseSBhcyAiaW5mb3JtYXRpb24gYWJvdXQgaW1taW5lbnQgdGhyZWF0cyB0byBodW1hbiBsaWZl IG9yICANCmhlYWx0aCIuLi4gYnV0IG90aGVyIHByYWN0aXRpb25lcnMgZnJhbWUgaXQgZGlmZmVy ZW50bHkuICBUaGUgd29yZCAgDQphbHNvIHNwYW5zIHRoZSBkaXN0aW5jdCBkb21haW5zIG9mIGF0 dGVudGlvbi1tYW5hZ2VtZW50IGFuZCAgDQppbmZvcm1hdGlvbi1zaGFyaW5nIChpcyBpdCBhIHdh cm5pbmcgaWYgZm9sa3MgYXJlIGFscmVhZHkgYXdhcmUgb2YgdGhlICANCnN1YmplY3QgbWF0dGVy PykNCg0KU28gSSdtIHdvbmRlcmluZy4uLiBtaWdodCBpdCBiZSBtb3JlIHByb2R1Y3RpdmUgdG8g c3BlY2lmeSB0aGUgIA0KcGFydGljdWxhciBvYnNlcnZhYmxlIGNoYXJhY3RlcmlzdGljcyB3ZSdy ZSBjb25jZXJuZWQgYWJvdXQgKGxhdGVuY3ksICANCnJlbGlhYmlsaXR5LCB2ZXJpZmlhYmlsaXR5 LCBldGMuKSB3ZSdyZSBob3BpbmcgdG8gYWNoaWV2ZSByYXRoZXIgdGhhbiAgDQpzbG9zaGluZyBh cm91bmQgaW4gbm9uLXRlY2huaWNhbCBzZW1hbnRpY3M/DQoNCkkgZ2V0IHRoZSBzZW5zZSB0aGF0 IGF0IGxlYXN0IHNvbWUgb2YgdXMgYXJlIHByaW1hcmlseSBjb25jZXJuZWQgd2l0aCAgDQp0aGUg dXNlIG9mIFNJUCwgYW5kIGFsdGhvdWdoIEkgaGF2ZSBubyBwZXJzb25hbCBpbnZlc3RtZW50IGlu IHRoYXQgIA0KcGFydGljdWxhciBhcHByb2FjaCwgYXQgbGVhc3QgaXQgc291bmRzIGxpa2UgdGhl IGZyYW1lIGZvciBhIHRyYWN0YWJsZSAgDQp0ZWNobmljYWwgcHJvYmxlbS4NCg0KLSBBcnQNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQplYXJseXdhcm5p bmcgbWFpbGluZyBsaXN0DQplYXJseXdhcm5pbmdAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZWFybHl3YXJuaW5nDQo= From acb@incident.com Sat May 2 12:46:40 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E900E3A6E3B for ; Sat, 2 May 2009 12:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02060oFbIqh0 for ; Sat, 2 May 2009 12:46:40 -0700 (PDT) Received: from smtp117.sbc.mail.sp1.yahoo.com (smtp117.sbc.mail.sp1.yahoo.com [69.147.64.90]) by core3.amsl.com (Postfix) with SMTP id 279923A6A1D for ; Sat, 2 May 2009 12:45:51 -0700 (PDT) Received: (qmail 95773 invoked from network); 2 May 2009 19:47:15 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 2 May 2009 19:47:15 -0000 X-YMail-OSG: tqpFZmsVM1kyYdyIjrdcCVj7BxyXsj6SgW7mnKct93UaiEjDjj201jBN.1Sb.YYvE6w0LrTbv0Qmx2ymEMs0MvAL6hv0j0KWP5vlov0aDj9uIJqZVrv4tXELtJm3_QP5acKnAwoL3DcozkpCMoXGflvBfP7rvYgvuAUpJFoT8PeiIH_ijHL5q2i1qgMSXIdX80ZS4srOUJwZtvg1K5hqNaH40MBRyUAFnjBveso0KOXJU89w0W3NLCCxxvf.k38s2DujuNXpiHSlNp_V2W36V1mJdsFv311nCwrVd5R_IGDzR6E- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id 102D91C85498; Sat, 2 May 2009 12:47:13 -0700 (PDT) Message-Id: <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> From: Art Botterell To: "DOLLY, MARTIN C, ATTLABS" In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 2 May 2009 12:47:10 -0700 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> X-Mailer: Apple Mail (2.930.3) Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2009 19:46:41 -0000 If so, why not say "government"? On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: > Authority is government > > ----- Original Message ----- > From: earlywarning-bounces@ietf.org > To: earlywarning@ietf.org > Sent: Sat May 02 11:51:10 2009 > Subject: Re: [earlywarning] Depricate "Authority" - was : global > CAPcommunity > > On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: > >> How many people here know PRECISELY what "exigent" means without >> looking it up. >> >> You need a term that has wider comprehension. > > Unfortunately, not many folks know precisely what "early warning" > means either, although many assume they do until you press them for > specifics. > > It seems like the current terms of reference are heavily loaded with > emotional and cultural baggage. That's the problem with the word > "authority"... it has several different senses and ultimately involves > a subjective, or at least individual, interpretation of who and what > constitutes authority (Government? Church? Academe? Culture?) > > "Warning" is likewise a fairly subtle notion when you really start to > unpack it. In my particular public warning system we define it > narrowly as "information about imminent threats to human life or > health"... but other practitioners frame it differently. The word > also spans the distinct domains of attention-management and > information-sharing (is it a warning if folks are already aware of the > subject matter?) > > So I'm wondering... might it be more productive to specify the > particular observable characteristics we're concerned about (latency, > reliability, verifiability, etc.) we're hoping to achieve rather than > sloshing around in non-technical semantics? > > I get the sense that at least some of us are primarily concerned with > the use of SIP, and although I have no personal investment in that > particular approach, at least it sounds like the frame for a tractable > technical problem. > > - Art > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From carlberg@g11.org.uk Sun May 3 06:12:16 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812FD3A6DE5 for ; Sun, 3 May 2009 06:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiQeOWEYRd2Q for ; Sun, 3 May 2009 06:12:15 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 628363A6F02 for ; Sun, 3 May 2009 06:12:15 -0700 (PDT) Received: from c-98-218-170-127.hsd1.va.comcast.net ([98.218.170.127]:65535 helo=[192.168.1.120]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0bVe-0008Pc-Cg; Sun, 03 May 2009 13:13:34 +0000 Message-Id: <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> From: ken carlberg To: Art Botterell In-Reply-To: <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 09:13:34 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 13:12:16 -0000 a good point. What the previous poster failed to elaborate on is that other SDO's like the ITU have made the association of authority == government, and given us terms and classification of communication models comprising: citizen-to-citizen, citizen-to-authority, authority-to-authority, and authority-to-citizen which is why we are seeing this terminology creep up on this list. one could take the approach that the IETF will go its own way, but I think it will be more constructive to acknowledge what's already gained traction and explore other terms. and in this specific case, something other than "authority" if we want to expand the target model. -ken On May 2, 2009, at 3:47 PM, Art Botterell wrote: > If so, why not say "government"? > > On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: > >> Authority is government >> >> ----- Original Message ----- >> From: earlywarning-bounces@ietf.org >> To: earlywarning@ietf.org >> Sent: Sat May 02 11:51:10 2009 >> Subject: Re: [earlywarning] Depricate "Authority" - was : global >> CAPcommunity >> >> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: >> >>> How many people here know PRECISELY what "exigent" means without >>> looking it up. >>> >>> You need a term that has wider comprehension. >> >> Unfortunately, not many folks know precisely what "early warning" >> means either, although many assume they do until you press them for >> specifics. >> >> It seems like the current terms of reference are heavily loaded with >> emotional and cultural baggage. That's the problem with the word >> "authority"... it has several different senses and ultimately >> involves >> a subjective, or at least individual, interpretation of who and what >> constitutes authority (Government? Church? Academe? Culture?) >> >> "Warning" is likewise a fairly subtle notion when you really start to >> unpack it. In my particular public warning system we define it >> narrowly as "information about imminent threats to human life or >> health"... but other practitioners frame it differently. The word >> also spans the distinct domains of attention-management and >> information-sharing (is it a warning if folks are already aware of >> the >> subject matter?) >> >> So I'm wondering... might it be more productive to specify the >> particular observable characteristics we're concerned about (latency, >> reliability, verifiability, etc.) we're hoping to achieve rather than >> sloshing around in non-technical semantics? >> >> I get the sense that at least some of us are primarily concerned with >> the use of SIP, and although I have no personal investment in that >> particular approach, at least it sounds like the frame for a >> tractable >> technical problem. >> >> - Art >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From carlberg@g11.org.uk Sun May 3 06:47:11 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8923B28C225 for ; Sun, 3 May 2009 06:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jtGlbppiJF7 for ; Sun, 3 May 2009 06:47:10 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 20F4828C118 for ; Sun, 3 May 2009 06:47:09 -0700 (PDT) Received: from c-98-218-170-127.hsd1.va.comcast.net ([98.218.170.127]:49453 helo=[192.168.1.120]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0c3Q-00050c-5w; Sun, 03 May 2009 13:48:28 +0000 Message-Id: From: ken carlberg To: James M. Polk In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 09:48:21 -0400 References: <49FB4855.4070305@bbn.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 13:47:11 -0000 On May 1, 2009, at 5:19 PM, James M. Polk wrote: >> What are you planning to preempt? > > I was wondering the same thing, as priority seems natural (wrt > server resources, and indication of the type of message), but this > is never going to be a stream, so I don't think we'll likely have 1 > message preempt another (but we may delay one message relative to > another). I would agree on the general case, but some constrained environments would require preemption, with possible subsequent transmission of the preempted session. as an example, any alerting system that includes meteor scatter communication links definitely needs preemption, and one could probably extend this to a number of LMR systems as well. the key thing to keep in mind is that some alerting systems may be disjoint in the variation of communication mechanisms being deployed, and in turn, that radioactive word of preemption may not be ubiquitously applied. -ken From acb@incident.com Sun May 3 09:32:20 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1B73A70DC for ; Sun, 3 May 2009 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FQ93QBEFwsD for ; Sun, 3 May 2009 09:32:19 -0700 (PDT) Received: from n10.bullet.mail.mud.yahoo.com (n10.bullet.mail.mud.yahoo.com [209.191.125.208]) by core3.amsl.com (Postfix) with SMTP id 9CE1F3A70E8 for ; Sun, 3 May 2009 09:31:33 -0700 (PDT) Received: from [68.142.200.224] by n10.bullet.mail.mud.yahoo.com with NNFMP; 03 May 2009 16:32:57 -0000 Received: from [68.142.201.249] by t5.bullet.mud.yahoo.com with NNFMP; 03 May 2009 16:32:57 -0000 Received: from [127.0.0.1] by omp410.mail.mud.yahoo.com with NNFMP; 03 May 2009 16:32:57 -0000 X-Yahoo-Newman-Id: 218577.65383.bm@omp410.mail.mud.yahoo.com Received: (qmail 61739 invoked from network); 3 May 2009 16:32:56 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp106.sbc.mail.sp1.yahoo.com with SMTP; 3 May 2009 16:32:56 -0000 X-YMail-OSG: 9.Awj1YVM1l0NHfgFgbT0t1JVv0Kxpm6kYeJMh0yBPqYk2j6zFOIiUen33aDjGBgmMp_5fMbmajogqXkj1Se8oGjcvxsO.FCH9Hsv1axRGo3adhYGdfee1WyGvnexlqrHBhXT0zLDu.V479GowafPPkEHmWumHhD.xuhexkiC4vDpujpBAmPtwwuH8lXORLlcanm4b.Dox50b2OL7y7F5i020zwIrEks0jOjrDZRDt3WIQx5GJFVTMCiwehq7ZzDJUDvSr7HO7UF0Tg- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id B11061C8AAEB for ; Sun, 3 May 2009 09:32:54 -0700 (PDT) Message-Id: From: Art Botterell To: earlywarning@ietf.org In-Reply-To: <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 09:32:54 -0700 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> X-Mailer: Apple Mail (2.930.3) Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 16:32:20 -0000 We can justify the term "authority" by appeal to authority (ITU, etc.) but I'm not sure that brings us any closer to an implementable spec. The problem arises when we try to build from inherently fuzzy terms like "authority" and "warning" to specific technical requirements. It sounds like what we're really talking about is transport of infrequent one-to-many communications of particular importance and urgency. - Art On May 3, 2009, at 5/3/09 6:13 AM, ken carlberg wrote: > a good point. What the previous poster failed to elaborate on is > that other SDO's like the ITU have made the association of authority > == government, and given us terms and classification of > communication models comprising: > > citizen-to-citizen, citizen-to-authority, > authority-to-authority, and authority-to-citizen > > which is why we are seeing this terminology creep up on this list. > one could take the approach that the IETF will go its own way, but I > think it will be more constructive to acknowledge what's already > gained traction and explore other terms. and in this specific case, > something other than "authority" if we want to expand the target > model. > > -ken > > > > On May 2, 2009, at 3:47 PM, Art Botterell wrote: > >> If so, why not say "government"? >> >> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: >> >>> Authority is government >>> >>> From trutkowski@netmagic.com Sun May 3 10:04:37 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559703A7113 for ; Sun, 3 May 2009 10:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJ-7rV25DRx9 for ; Sun, 3 May 2009 10:04:31 -0700 (PDT) Received: from vms173017pub.verizon.net (vms173017pub.verizon.net [206.46.173.17]) by core3.amsl.com (Postfix) with ESMTP id 03BA73A6917 for ; Sun, 3 May 2009 10:04:12 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173017.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KJ20061QVGQHDR3@vms173017.mailsrvcs.net> for earlywarning@ietf.org; Sun, 03 May 2009 12:05:19 -0500 (CDT) Message-id: <49FDCECA.8050909@netmagic.com> Date: Sun, 03 May 2009 13:05:14 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Art Botterell References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> In-reply-to: Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 17:04:37 -0000 Hi Art, > We can justify the term "authority" by appeal to authority (ITU, etc.) > but I'm not sure that brings us any closer to an implementable spec. > The problem arises when we try to build from inherently fuzzy terms > like "authority" and "warning" to specific technical requirements. The quick ITU-T answer is likely to be that this is a national matter. Rec. X.1303 encompasses a broad array of potential implementations. > constructive to acknowledge what's already gained traction and explore > other terms. and in this specific case, something other than > "authority" if we want to expand the target model. This is the way to go. --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From acb@incident.com Sun May 3 10:12:45 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D983A7116 for ; Sun, 3 May 2009 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOpu6uMQG4qF for ; Sun, 3 May 2009 10:12:39 -0700 (PDT) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 0A85628C26A for ; Sun, 3 May 2009 10:10:55 -0700 (PDT) Received: (qmail 27251 invoked from network); 3 May 2009 17:12:17 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 3 May 2009 17:12:17 -0000 X-YMail-OSG: 3.gCRUIVM1k3jGtwHjA327bc_Y7wfuoqi.CGPydaXSryeM0pzqu3i1Rb2RLyjJfujETuZ6HCSgEdJilZxd6i51WNZEQYJkHtU9xzVQ9WpFrd8Eg48CsrlN4HWr3a8t00vDPS01uGsP5kymB6t9lTS0PmE4MdF7Jp0hn8ZKgnA1BLMY_FUGTsd5YJTV9mHyp5ED0FEvVz52..AtIfLwNoJfqLVHgQYmSWJcYuRPGPwjT4BifCxmcloXzhwaeoPsWcbkic2Dkp_MM0We4- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id A0D531C8AE95; Sun, 3 May 2009 10:12:15 -0700 (PDT) Message-Id: <6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> From: Art Botterell To: trutkowski@netmagic.com In-Reply-To: <49FDCECA.8050909@netmagic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 3 May 2009 10:12:15 -0700 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <49FDCECA.8050909@netmagic.com> X-Mailer: Apple Mail (2.930.3) Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 17:12:45 -0000 Tony - Not sure I follow you... how would developing technical requirements be a national matter? Or more to the point, if it is, then what are we doing here? As for X.1303/CAP... that's a content standard. Seems like the issue here is transport, about which the CAP spec is aggressively agnostic. But again, seems like we're all over the map on our assumptions. Are we, in fact, talking transport, or what? - Art On May 3, 2009, at 5/3/09 10:05 AM, Tony Rutkowski wrote: > Hi Art, >> We can justify the term "authority" by appeal to authority (ITU, >> etc.) >> but I'm not sure that brings us any closer to an implementable spec. >> The problem arises when we try to build from inherently fuzzy terms >> like "authority" and "warning" to specific technical requirements. > The quick ITU-T answer is likely to be that this is a national matter. > > Rec. X.1303 encompasses a broad array of potential implementations. >> constructive to acknowledge what's already gained traction and >> explore >> other terms. and in this specific case, something other than >> "authority" if we want to expand the target model. > This is the way to go. > > --tony > > -- > Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 > 703.999.8270 > From trutkowski@netmagic.com Sun May 3 10:23:21 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 744BE3A6A4B for ; Sun, 3 May 2009 10:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULbOLT6gMglI for ; Sun, 3 May 2009 10:23:20 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by core3.amsl.com (Postfix) with ESMTP id 988ED3A6EA7 for ; Sun, 3 May 2009 10:23:17 -0700 (PDT) Received: from [192.168.1.3] ([72.86.34.21]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KJ200BSGWD2F6H3@vms173003.mailsrvcs.net> for earlywarning@ietf.org; Sun, 03 May 2009 12:24:42 -0500 (CDT) Message-id: <49FDD355.1050807@netmagic.com> Date: Sun, 03 May 2009 13:24:37 -0400 From: Tony Rutkowski Organization: Netmagic Associates User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-version: 1.0 To: Art Botterell References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <49FDCECA.8050909@netmagic.com> <6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> In-reply-to: <6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: trutkowski@netmagic.com List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2009 17:23:21 -0000 > Not sure I follow you... how would developing technical requirements > be a national matter? Or more to the point, if it is, then what are > we doing here? Hi Art, My reference was with the idea that the ITU would somehow be defining who "authorities" were for the purposes of specific national implementations where "authority" needed to be designated. Provisions such as the FCC's Part 10 rules specify specify this. The better approach is the more generic one that you advocate. --tony -- Tony Rutkowski | Netmagic Associates LLC | Ashburn VA | mob: +1 703.999.8270 From Martin.Thomson@andrew.com Sun May 3 18:23:19 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E76B3A6FE5 for ; Sun, 3 May 2009 18:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRLXJ3ejS4bW for ; Sun, 3 May 2009 18:23:13 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 0E6A33A685D for ; Sun, 3 May 2009 18:22:56 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_03_20_45_14 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 03 May 2009 20:45:14 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 May 2009 20:24:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 3 May 2009 20:24:19 -0500 Message-ID: In-Reply-To: <49FDD355.1050807@netmagic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [earlywarning] Deprecate "Authority" - was : global CAPcommunity Thread-Index: AcnMFA/GJ0G3nvtMTSig8ox8CwcdSQAPgQ+Q References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com><4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><49FDCECA.8050909@netmagic.com><6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> <49FDD355.1050807@netmagic.com> From: "Thomson, Martin" To: , "Art Botterell" X-OriginalArrivalTime: 04 May 2009 01:24:21.0549 (UTC) FILETIME=[0D6195D0:01C9CC57] Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 01:23:19 -0000 SSB3b3JyeSB0aGF0IHRoaXMgZGlzY3Vzc2lvbiBoYXMgbG9zdCBmb2N1cy4gIEFyZSB3ZSB0YWxr aW5nIGFib3V0IHRlcm1zIGZvciB1c2UgaW4gcmVsYXRpb24gdG8gYSBwcm90b2NvbCwgb3IgdGVy bXMgaW4gcmVsYXRpb24gdG8gcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIG5hbWluZyAobWFya2V0aW5n KT8gIFRoZXkgY2FuIGJlIHNlcGFyYXRlZC4NCg0KVGhlIHRlcm1zIHRoYXQgSGFubmVzIHByb3Bv c2VzIChBdXRob3IgYW5kIFJlY2lwaWVudCkgd291bGQgYmUgcXVpdGUgc3VpdGFibGUgZm9yIHVz ZSBpbiBkZXNjcmliaW5nIGEgcHJvdG9jb2wgYW5kIGFyY2hpdGVjdHVyZS4NCg0KSXMgdGhpcyBy ZWFsbHkgdGhlIHZlbnVlIGZvciBkZWNpZGluZyB3aG8gYXBwbGllcyB0aGlzIHByb3RvY29sIHNv bHV0aW9uPyAgTm90IHRoYXQgSSdtIHN1Z2dlc3Rpbmcgd2UgZGVzaWduIGluIGEgdmFjdXVtLCBi dXQgd2UgZWFjaCBoYXZlIGEgZmFpciBpZGVhIG9mIHdoYXQgdGhlIGdvYWxzIGFyZTsgYW5kIEkg dHJ1bHkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVyZSBhcmUgbWFqb3IgZGlmZmVyZW5jZXMgb2Ygb3Bp bmlvbi4gIFRoZSBzdWJqZWN0aXZlIGRlZmluaXRpb24gb2YgImF1dGhvcml0eSIgbmVlZCBub3Qg YmUgYSBiYXJyaWVyIHRvIHByb2dyZXNzLg0KDQpJJ20gaGFwcHkgd2l0aCBtYXJrZXRpbmcgd2l0 aCB2YWd1ZSB0ZXJtcyBsaWtlICJhdXRob3JpdHktdG8tY2l0aXplbiIgb3IgImVhcmx5IHdhcm5p bmciIGFuZCBoYXZpbmcgc2VwYXJhdGUgdGVybXMgaW4gcHJvdG9jb2wgbGFuZC4gIFRoYXQncyBi ZWVuIHN1Y2Nlc3NmdWwgaW4gdGhlIHBhc3Q7IHRoZSBhYnN0cmFjdGlvbiBhbGxvd3MgZm9yIGEg bGl0dGxlIGZsZXhpYmlsaXR5IGluIGludGVycHJldGF0aW9uLiAgVGhhdCBmbGV4aWJpbGl0eSBp cyBzb21ldGltZXMgdXNlZnVsLg0KDQpJIHRlbmQgdG8gYWdyZWUgd2l0aCBBcnQgdGhhdCB3ZSBj YW4gc3BlbmQgYSBsb3Qgb2YgdGltZSBvbiB0aGUgbm9uLXRlY2huaWNhbCBzdHVmZi4gIE1heWJl IGFic3RyYWN0aW9uIG9mZmVycyB1cyBhIHdheSB0byBtYWtlIHByb2Nlc3Mgb24gdGhlIHRlY2hu aWNhbCBzaWRlIHdoaWxlIHdlICJzbG9zaCBhcm91bmQiIG9uIHRoZSBmdXp6eSBpc3N1ZXMuDQoN Ci0tTWFydGluDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU aGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkN CmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFu eSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From rbarnes@bbn.com Mon May 4 01:07:14 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143133A69D8 for ; Mon, 4 May 2009 01:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCx9+Iij1bcs for ; Mon, 4 May 2009 01:07:08 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1CEC93A6F71 for ; Mon, 4 May 2009 01:05:49 -0700 (PDT) Received: from [128.89.254.176] by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1M0tCh-00054H-Ew; Mon, 04 May 2009 04:07:11 -0400 Message-ID: <49FEA209.5080900@bbn.com> Date: Mon, 04 May 2009 10:06:33 +0200 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Thomson, Martin" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com><4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><49FDCECA.8050909@netmagic.com><6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> <49FDD355.1050807@netmagic.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 08:07:14 -0000 +1 Also, under the "marketing" header, it will probably be useful to put together some mapping between the more general terms we'll use for protocol development and the specific terms used, e.g., by ITU-T. --Richard Thomson, Martin wrote: > I worry that this discussion has lost focus. Are we talking about terms for use in relation to a protocol, or terms in relation to problem statement and naming (marketing)? They can be separated. > > The terms that Hannes proposes (Author and Recipient) would be quite suitable for use in describing a protocol and architecture. > > Is this really the venue for deciding who applies this protocol solution? Not that I'm suggesting we design in a vacuum, but we each have a fair idea of what the goals are; and I truly don't think that there are major differences of opinion. The subjective definition of "authority" need not be a barrier to progress. > > I'm happy with marketing with vague terms like "authority-to-citizen" or "early warning" and having separate terms in protocol land. That's been successful in the past; the abstraction allows for a little flexibility in interpretation. That flexibility is sometimes useful. > > I tend to agree with Art that we can spend a lot of time on the non-technical stuff. Maybe abstraction offers us a way to make process on the technical side while we "slosh around" on the fuzzy issues. > > --Martin > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From br@brianrosen.net Mon May 4 05:41:52 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DE7F28C145 for ; Mon, 4 May 2009 05:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDGmlKx9Sn2V for ; Mon, 4 May 2009 05:41:51 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 240D828C168 for ; Mon, 4 May 2009 05:41:35 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0xVV-0004Ul-II; Mon, 04 May 2009 07:42:53 -0500 From: "Brian Rosen" To: "'ken carlberg'" , "'Art Botterell'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> In-Reply-To: <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> Date: Mon, 4 May 2009 08:42:52 -0400 Message-ID: <0d3101c9ccb5$d98e7a70$8cab6f50$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnL8PnIornn1ys4QWixIOuIpIf+XAAxCidQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:41:52 -0000 As with any IETF effort, limiting scope is useful to get progress in a reasonable time. With this effort, we have tried to limit the scope of "authority". It would be okay with me if we did limit it to government initially, although eventually I suspect we will expand it. I am very comfortable leaving the terminology as is: authority to citizen. I think we can reasonably explain that authority is initially government (national, state/province/region/, and local). We can reasonably explain that citizen includes residents and visitors. I'd like to keep the discussion more on the scope than on the terminology. Brian -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of ken carlberg Sent: Sunday, May 03, 2009 9:14 AM To: Art Botterell Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity a good point. What the previous poster failed to elaborate on is that other SDO's like the ITU have made the association of authority == government, and given us terms and classification of communication models comprising: citizen-to-citizen, citizen-to-authority, authority-to-authority, and authority-to-citizen which is why we are seeing this terminology creep up on this list. one could take the approach that the IETF will go its own way, but I think it will be more constructive to acknowledge what's already gained traction and explore other terms. and in this specific case, something other than "authority" if we want to expand the target model. -ken On May 2, 2009, at 3:47 PM, Art Botterell wrote: > If so, why not say "government"? > > On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: > >> Authority is government >> >> ----- Original Message ----- >> From: earlywarning-bounces@ietf.org >> To: earlywarning@ietf.org >> Sent: Sat May 02 11:51:10 2009 >> Subject: Re: [earlywarning] Depricate "Authority" - was : global >> CAPcommunity >> >> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: >> >>> How many people here know PRECISELY what "exigent" means without >>> looking it up. >>> >>> You need a term that has wider comprehension. >> >> Unfortunately, not many folks know precisely what "early warning" >> means either, although many assume they do until you press them for >> specifics. >> >> It seems like the current terms of reference are heavily loaded with >> emotional and cultural baggage. That's the problem with the word >> "authority"... it has several different senses and ultimately >> involves >> a subjective, or at least individual, interpretation of who and what >> constitutes authority (Government? Church? Academe? Culture?) >> >> "Warning" is likewise a fairly subtle notion when you really start to >> unpack it. In my particular public warning system we define it >> narrowly as "information about imminent threats to human life or >> health"... but other practitioners frame it differently. The word >> also spans the distinct domains of attention-management and >> information-sharing (is it a warning if folks are already aware of >> the >> subject matter?) >> >> So I'm wondering... might it be more productive to specify the >> particular observable characteristics we're concerned about (latency, >> reliability, verifiability, etc.) we're hoping to achieve rather than >> sloshing around in non-technical semantics? >> >> I get the sense that at least some of us are primarily concerned with >> the use of SIP, and although I have no personal investment in that >> particular approach, at least it sounds like the frame for a >> tractable >> technical problem. >> >> - Art >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning _______________________________________________ earlywarning mailing list earlywarning@ietf.org https://www.ietf.org/mailman/listinfo/earlywarning From br@brianrosen.net Mon May 4 05:43:48 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A0F3A7026 for ; Mon, 4 May 2009 05:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxmtrHzmoS4L for ; Mon, 4 May 2009 05:43:47 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 494733A701A for ; Mon, 4 May 2009 05:43:47 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0xXe-0004e0-1L; Mon, 04 May 2009 07:45:06 -0500 From: "Brian Rosen" To: "'ken carlberg'" , "'James M. Polk'" References: <49FB4855.4070305@bbn.com> In-Reply-To: Date: Mon, 4 May 2009 08:45:05 -0400 Message-ID: <0d3201c9ccb6$28857980$79906c80$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnL9dsY5Mjw9Tn4TaOxhC1e8MNH3wAwAOFw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 12:43:48 -0000 Right now, I'd prefer that we assume that messages are short enough that the complexity of preemption is worse that the delay of transmission. I wouldn't mind priority if there was a queue of alerts to be sent, but the notion that we preempt is, I think, not worth it. Brian -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of ken carlberg Sent: Sunday, May 03, 2009 9:48 AM To: James M. Polk Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community On May 1, 2009, at 5:19 PM, James M. Polk wrote: >> What are you planning to preempt? > > I was wondering the same thing, as priority seems natural (wrt > server resources, and indication of the type of message), but this > is never going to be a stream, so I don't think we'll likely have 1 > message preempt another (but we may delay one message relative to > another). I would agree on the general case, but some constrained environments would require preemption, with possible subsequent transmission of the preempted session. as an example, any alerting system that includes meteor scatter communication links definitely needs preemption, and one could probably extend this to a number of LMR systems as well. the key thing to keep in mind is that some alerting systems may be disjoint in the variation of communication mechanisms being deployed, and in turn, that radioactive word of preemption may not be ubiquitously applied. -ken _______________________________________________ earlywarning mailing list earlywarning@ietf.org https://www.ietf.org/mailman/listinfo/earlywarning From hgs@cs.columbia.edu Mon May 4 06:18:52 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39943A7032 for ; Mon, 4 May 2009 06:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T69udltD2yhv for ; Mon, 4 May 2009 06:18:51 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 8BA203A702F for ; Mon, 4 May 2009 06:18:51 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n44DK2lA016363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 09:20:02 -0400 (EDT) Message-Id: <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <0d3101c9ccb5$d98e7a70$8cab6f50$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 09:20:01 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:18:52 -0000 This distinction is unlikely to work in the US, at least, as there are many quasi-governmental entities. Classical example: some of the largest scale notification systems today are deployed by college campuses, particularly after the Virginia Tech shooting. There is no technical reason why such function should be available to state colleges and universities, but not to private institutions (which, in the US, are in no way governed by the Federal or state government). Same is true for large school districts, which can be either run by the city/county or, say, the Catholic Church. Henning On May 4, 2009, at 8:42 AM, Brian Rosen wrote: > As with any IETF effort, limiting scope is useful to get progress in a > reasonable time. With this effort, we have tried to limit the scope > of > "authority". It would be okay with me if we did limit it to > government > initially, although eventually I suspect we will expand it. > > I am very comfortable leaving the terminology as is: authority to > citizen. > I think we can reasonably explain that authority is initially > government > (national, state/province/region/, and local). We can reasonably > explain > that citizen includes residents and visitors. > > I'd like to keep the discussion more on the scope than on the > terminology. > > Brian > > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org > ] > On Behalf Of ken carlberg > Sent: Sunday, May 03, 2009 9:14 AM > To: Art Botterell > Cc: earlywarning@ietf.org > Subject: Re: [earlywarning] Depricate "Authority" - was : global > CAPcommunity > > a good point. What the previous poster failed to elaborate on is that > other SDO's like the ITU have made the association of authority == > government, and given us terms and classification of communication > models comprising: > > citizen-to-citizen, citizen-to-authority, > authority-to-authority, and authority-to-citizen > > which is why we are seeing this terminology creep up on this list. > one could take the approach that the IETF will go its own way, but I > think it will be more constructive to acknowledge what's already > gained traction and explore other terms. and in this specific case, > something other than "authority" if we want to expand the target > model. > > -ken > > > > On May 2, 2009, at 3:47 PM, Art Botterell wrote: > >> If so, why not say "government"? >> >> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: >> >>> Authority is government >>> >>> ----- Original Message ----- >>> From: earlywarning-bounces@ietf.org >>> To: earlywarning@ietf.org >>> Sent: Sat May 02 11:51:10 2009 >>> Subject: Re: [earlywarning] Depricate "Authority" - was : global >>> CAPcommunity >>> >>> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: >>> >>>> How many people here know PRECISELY what "exigent" means without >>>> looking it up. >>>> >>>> You need a term that has wider comprehension. >>> >>> Unfortunately, not many folks know precisely what "early warning" >>> means either, although many assume they do until you press them for >>> specifics. >>> >>> It seems like the current terms of reference are heavily loaded with >>> emotional and cultural baggage. That's the problem with the word >>> "authority"... it has several different senses and ultimately >>> involves >>> a subjective, or at least individual, interpretation of who and what >>> constitutes authority (Government? Church? Academe? Culture?) >>> >>> "Warning" is likewise a fairly subtle notion when you really start >>> to >>> unpack it. In my particular public warning system we define it >>> narrowly as "information about imminent threats to human life or >>> health"... but other practitioners frame it differently. The word >>> also spans the distinct domains of attention-management and >>> information-sharing (is it a warning if folks are already aware of >>> the >>> subject matter?) >>> >>> So I'm wondering... might it be more productive to specify the >>> particular observable characteristics we're concerned about >>> (latency, >>> reliability, verifiability, etc.) we're hoping to achieve rather >>> than >>> sloshing around in non-technical semantics? >>> >>> I get the sense that at least some of us are primarily concerned >>> with >>> the use of SIP, and although I have no personal investment in that >>> particular approach, at least it sounds like the frame for a >>> tractable >>> technical problem. >>> >>> - Art >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > From br@brianrosen.net Mon May 4 06:34:16 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1B8D3A700B for ; Mon, 4 May 2009 06:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTOmiMd0c4Dp for ; Mon, 4 May 2009 06:34:16 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id DB6E23A6F6A for ; Mon, 4 May 2009 06:34:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0yKU-0001cF-DQ; Mon, 04 May 2009 08:35:34 -0500 From: "Brian Rosen" To: "'Art Botterell'" , References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> In-Reply-To: Date: Mon, 4 May 2009 09:35:33 -0400 Message-ID: <0d4e01c9ccbd$3534fc80$9f9ef580$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnMDOuHcOwKMXmiRK+AnWvJznVyUQAr84Fw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 13:34:16 -0000 It's probably not quite that simple, but generally, yes, I think we're mostly concerned with how a message in a defined format (CAP) gets from the authority to the citizen. I don't think anyone is arguing we aren't leveraging the CAP work. There are undoubtedly issues with doing content the IETF way, as we usually deal up front with issues like a wide range of devices with different capabilities that need to render the alert, as well as language issues, etc. So, it's not JUST transport. Brian -----Original Message----- From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] On Behalf Of Art Botterell Sent: Sunday, May 03, 2009 12:33 PM To: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity We can justify the term "authority" by appeal to authority (ITU, etc.) but I'm not sure that brings us any closer to an implementable spec. The problem arises when we try to build from inherently fuzzy terms like "authority" and "warning" to specific technical requirements. It sounds like what we're really talking about is transport of infrequent one-to-many communications of particular importance and urgency. - Art On May 3, 2009, at 5/3/09 6:13 AM, ken carlberg wrote: > a good point. What the previous poster failed to elaborate on is > that other SDO's like the ITU have made the association of authority > == government, and given us terms and classification of > communication models comprising: > > citizen-to-citizen, citizen-to-authority, > authority-to-authority, and authority-to-citizen > > which is why we are seeing this terminology creep up on this list. > one could take the approach that the IETF will go its own way, but I > think it will be more constructive to acknowledge what's already > gained traction and explore other terms. and in this specific case, > something other than "authority" if we want to expand the target > model. > > -ken > > > > On May 2, 2009, at 3:47 PM, Art Botterell wrote: > >> If so, why not say "government"? >> >> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: >> >>> Authority is government >>> >>> _______________________________________________ earlywarning mailing list earlywarning@ietf.org https://www.ietf.org/mailman/listinfo/earlywarning From br@brianrosen.net Mon May 4 07:01:10 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1653A691C for ; Mon, 4 May 2009 07:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bo7waNZ04r+r for ; Mon, 4 May 2009 07:01:09 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0B8F628C112 for ; Mon, 4 May 2009 07:00:44 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0yk0-0004Jk-CP; Mon, 04 May 2009 09:01:57 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> In-Reply-To: <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> Date: Mon, 4 May 2009 10:01:55 -0400 Message-ID: <0d5e01c9ccc0$e4966b20$adc34160$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnMuwkTgyVF+zTfTA20h4+zNty0+gABA7gA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 14:01:10 -0000 Finally, a meaty subject; terminology really doesn't get us very far. This is important; really narrowing scope. Let's take a look at how far do we want to go: National Government with major warning - impending attack Regional Government with life threatening event - Tornado or flash flood Local Government with life threatening event - hazmat spill Local Government with important, but not threatening event - major traffic tieup Local Government with useful event - public school closing State Government College with life threatening event - school shooting Private College with life threatening event - school shooting Private elementary school with useful event - school closing Enterprise with life threatening event - hazmat spill Enterprise with useful event - building closing due to weather It's clear to me that all of these are very useful alerts. The question becomes, which of these should be in scope for the first charter? It seems to me that the issue of authorization is the biggie here, and if we started out limiting to government, even local government, it gets a lot easier. Once you allow a non-government entity to notify using the mechanism, we make the authorization decision much more difficult. I don't see an in-between way to slice the above list other than government/non government unless you say that the government can authorize other entities and you are relying on that authorization. I think the wishes of the networks that are transporting the alerts come into play; they would want a bright line on authorization. I suspect that once you have an authorized entity that can create an alert, what it gets to use that authorization for is a less interesting (to the IETF) issue. If you can issue alerts, you can issue any kind of alert. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, May 04, 2009 9:20 AM To: Brian Rosen Cc: 'ken carlberg'; 'Art Botterell'; earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity This distinction is unlikely to work in the US, at least, as there are many quasi-governmental entities. Classical example: some of the largest scale notification systems today are deployed by college campuses, particularly after the Virginia Tech shooting. There is no technical reason why such function should be available to state colleges and universities, but not to private institutions (which, in the US, are in no way governed by the Federal or state government). Same is true for large school districts, which can be either run by the city/county or, say, the Catholic Church. Henning On May 4, 2009, at 8:42 AM, Brian Rosen wrote: > As with any IETF effort, limiting scope is useful to get progress in a > reasonable time. With this effort, we have tried to limit the scope > of > "authority". It would be okay with me if we did limit it to > government > initially, although eventually I suspect we will expand it. > > I am very comfortable leaving the terminology as is: authority to > citizen. > I think we can reasonably explain that authority is initially > government > (national, state/province/region/, and local). We can reasonably > explain > that citizen includes residents and visitors. > > I'd like to keep the discussion more on the scope than on the > terminology. > > Brian > > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org > ] > On Behalf Of ken carlberg > Sent: Sunday, May 03, 2009 9:14 AM > To: Art Botterell > Cc: earlywarning@ietf.org > Subject: Re: [earlywarning] Depricate "Authority" - was : global > CAPcommunity > > a good point. What the previous poster failed to elaborate on is that > other SDO's like the ITU have made the association of authority == > government, and given us terms and classification of communication > models comprising: > > citizen-to-citizen, citizen-to-authority, > authority-to-authority, and authority-to-citizen > > which is why we are seeing this terminology creep up on this list. > one could take the approach that the IETF will go its own way, but I > think it will be more constructive to acknowledge what's already > gained traction and explore other terms. and in this specific case, > something other than "authority" if we want to expand the target > model. > > -ken > > > > On May 2, 2009, at 3:47 PM, Art Botterell wrote: > >> If so, why not say "government"? >> >> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: >> >>> Authority is government >>> >>> ----- Original Message ----- >>> From: earlywarning-bounces@ietf.org >>> To: earlywarning@ietf.org >>> Sent: Sat May 02 11:51:10 2009 >>> Subject: Re: [earlywarning] Depricate "Authority" - was : global >>> CAPcommunity >>> >>> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: >>> >>>> How many people here know PRECISELY what "exigent" means without >>>> looking it up. >>>> >>>> You need a term that has wider comprehension. >>> >>> Unfortunately, not many folks know precisely what "early warning" >>> means either, although many assume they do until you press them for >>> specifics. >>> >>> It seems like the current terms of reference are heavily loaded with >>> emotional and cultural baggage. That's the problem with the word >>> "authority"... it has several different senses and ultimately >>> involves >>> a subjective, or at least individual, interpretation of who and what >>> constitutes authority (Government? Church? Academe? Culture?) >>> >>> "Warning" is likewise a fairly subtle notion when you really start >>> to >>> unpack it. In my particular public warning system we define it >>> narrowly as "information about imminent threats to human life or >>> health"... but other practitioners frame it differently. The word >>> also spans the distinct domains of attention-management and >>> information-sharing (is it a warning if folks are already aware of >>> the >>> subject matter?) >>> >>> So I'm wondering... might it be more productive to specify the >>> particular observable characteristics we're concerned about >>> (latency, >>> reliability, verifiability, etc.) we're hoping to achieve rather >>> than >>> sloshing around in non-technical semantics? >>> >>> I get the sense that at least some of us are primarily concerned >>> with >>> the use of SIP, and although I have no personal investment in that >>> particular approach, at least it sounds like the frame for a >>> tractable >>> technical problem. >>> >>> - Art >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > From creed@opengeospatial.org Mon May 4 07:38:20 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49763A6B29 for ; Mon, 4 May 2009 07:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zkPTHXGV4B2 for ; Mon, 4 May 2009 07:38:19 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [208.44.53.140]) by core3.amsl.com (Postfix) with ESMTP id C56A73A6A04 for ; Mon, 4 May 2009 07:38:19 -0700 (PDT) Received: from CarlandSusieOf (c-75-71-192-203.hsd1.co.comcast.net [75.71.192.203]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3) with ESMTP id n44EdXNj025279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 10:39:42 -0400 Message-ID: <5424B67B99E444B68800C4342470DBA4@CarlandSusieOf> From: "Carl Reed" To: "Thomson, Martin" , , "Art Botterell" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com><4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><49FDCECA.8050909@netmagic.com><6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com><49FDD355.1050807@netmagic.com> In-Reply-To: Date: Mon, 4 May 2009 08:36:54 -0600 Organization: OGC 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.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Virus-Scanned: ClamAV 0.92.1/9325/Mon May 4 08:17:20 2009 on mail.opengeospatial.org X-Virus-Status: Clean Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 14:38:20 -0000 Martin - Thanks for this perspective. I also was beginning to worry about mixing "apples and oranges" in this discussion. The rules of use and distribution of an alert and the alert payload itself are two different (but related) animals. As an example, GeoRSS is used in numerous consumer, unrestricted alerting applications. No thought to security, authentication, quality, etc. At the other extreme, GeoRSS is now also used in a secure Intelnet application. Obviously very different use cases with very, very different requirements for authentication and security. And different vocabularies/semantics. But the identical payload info model, schemas and so forth. Same with CAP. Whether a Presidential alert has priority or not is not relevant to the CAP info model and structure. What is important in terms of where the authentication is performed, the priority setting, and so forth is the actual alerting architecture and infrastructure. Carl ----- Original Message ----- From: "Thomson, Martin" To: ; "Art Botterell" Cc: Sent: Sunday, May 03, 2009 7:24 PM Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity >I worry that this discussion has lost focus. Are we talking about terms >for use in relation to a protocol, or terms in relation to problem >statement and naming (marketing)? They can be separated. > > The terms that Hannes proposes (Author and Recipient) would be quite > suitable for use in describing a protocol and architecture. > > Is this really the venue for deciding who applies this protocol solution? > Not that I'm suggesting we design in a vacuum, but we each have a fair > idea of what the goals are; and I truly don't think that there are major > differences of opinion. The subjective definition of "authority" need not > be a barrier to progress. > > I'm happy with marketing with vague terms like "authority-to-citizen" or > "early warning" and having separate terms in protocol land. That's been > successful in the past; the abstraction allows for a little flexibility in > interpretation. That flexibility is sometimes useful. > > I tend to agree with Art that we can spend a lot of time on the > non-technical stuff. Maybe abstraction offers us a way to make process on > the technical side while we "slosh around" on the fuzzy issues. > > --Martin > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From hgs@cs.columbia.edu Mon May 4 07:41:41 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5063A7069 for ; Mon, 4 May 2009 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DMdyKqUaVWd for ; Mon, 4 May 2009 07:41:40 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id F0FC83A6E70 for ; Mon, 4 May 2009 07:41:37 -0700 (PDT) Received: from Upstairs.home (pool-96-242-40-88.nwrknj.fios.verizon.net [96.242.40.88] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n44Egtf0013783 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 10:42:55 -0400 (EDT) Message-Id: <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <0d5e01c9ccc0$e4966b20$adc34160$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 10:42:55 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 14:41:42 -0000 Why is authorization easier for government? A school, university or company generally knows all of its students and employees, and can thus easily, relatively speaking, provide their public key to them ahead of time, so that an alert can be trivially verified as to its authenticity. For that, it doesn't matter whether the organization is run by a government (say, the Port Authority of NY&NJ) or a private entity (Columbia University). (I guess sending alerts to GM and Citibank would still be ok...). I'm ignoring the problem of university/ company visitors, as most existing alert systems don't deal with them, and reasonably rely on the "regulars" to tell them what's going on. The case of alerting is much harder for entities who need to reach everyone who happens to be in their territory, such as a county. They have to distribute some cryptographic material to everybody, including visitors, without knowing who they are. Thus, the operative difference seem much more of a "closed" vs. "open" membership, rather than whether the entity operating the alert has a seal and calls it itself county or state government. Henning On May 4, 2009, at 10:01 AM, Brian Rosen wrote: > Finally, a meaty subject; terminology really doesn't get us very > far. This > is important; really narrowing scope. > > Let's take a look at how far do we want to go: > > National Government with major warning - impending attack > Regional Government with life threatening event - Tornado or flash > flood > Local Government with life threatening event - hazmat spill > Local Government with important, but not threatening event - major > traffic > tieup > Local Government with useful event - public school closing > State Government College with life threatening event - school shooting > Private College with life threatening event - school shooting > Private elementary school with useful event - school closing > Enterprise with life threatening event - hazmat spill > Enterprise with useful event - building closing due to weather > > It's clear to me that all of these are very useful alerts. The > question > becomes, which of these should be in scope for the first charter? > > It seems to me that the issue of authorization is the biggie here, > and if we > started out limiting to government, even local government, it gets a > lot > easier. Once you allow a non-government entity to notify using the > mechanism, we make the authorization decision much more difficult. > I don't > see an in-between way to slice the above list other than government/ > non > government unless you say that the government can authorize other > entities > and you are relying on that authorization. > > I think the wishes of the networks that are transporting the alerts > come > into play; they would want a bright line on authorization. > > I suspect that once you have an authorized entity that can create an > alert, > what it gets to use that authorization for is a less interesting (to > the > IETF) issue. If you can issue alerts, you can issue any kind of > alert. > > Brian > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, May 04, 2009 9:20 AM > To: Brian Rosen > Cc: 'ken carlberg'; 'Art Botterell'; earlywarning@ietf.org > Subject: Re: [earlywarning] Depricate "Authority" - was : global > CAPcommunity > > This distinction is unlikely to work in the US, at least, as there are > many quasi-governmental entities. Classical example: some of the > largest scale notification systems today are deployed by college > campuses, particularly after the Virginia Tech shooting. There is no > technical reason why such function should be available to state > colleges and universities, but not to private institutions (which, in > the US, are in no way governed by the Federal or state government). > Same is true for large school districts, which can be either run by > the city/county or, say, the Catholic Church. > > Henning > > On May 4, 2009, at 8:42 AM, Brian Rosen wrote: > >> As with any IETF effort, limiting scope is useful to get progress >> in a >> reasonable time. With this effort, we have tried to limit the scope >> of >> "authority". It would be okay with me if we did limit it to >> government >> initially, although eventually I suspect we will expand it. >> >> I am very comfortable leaving the terminology as is: authority to >> citizen. >> I think we can reasonably explain that authority is initially >> government >> (national, state/province/region/, and local). We can reasonably >> explain >> that citizen includes residents and visitors. >> >> I'd like to keep the discussion more on the scope than on the >> terminology. >> >> Brian >> >> -----Original Message----- >> From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org >> ] >> On Behalf Of ken carlberg >> Sent: Sunday, May 03, 2009 9:14 AM >> To: Art Botterell >> Cc: earlywarning@ietf.org >> Subject: Re: [earlywarning] Depricate "Authority" - was : global >> CAPcommunity >> >> a good point. What the previous poster failed to elaborate on is >> that >> other SDO's like the ITU have made the association of authority == >> government, and given us terms and classification of communication >> models comprising: >> >> citizen-to-citizen, citizen-to-authority, >> authority-to-authority, and authority-to-citizen >> >> which is why we are seeing this terminology creep up on this list. >> one could take the approach that the IETF will go its own way, but I >> think it will be more constructive to acknowledge what's already >> gained traction and explore other terms. and in this specific case, >> something other than "authority" if we want to expand the target >> model. >> >> -ken >> >> >> >> On May 2, 2009, at 3:47 PM, Art Botterell wrote: >> >>> If so, why not say "government"? >>> >>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: >>> >>>> Authority is government >>>> >>>> ----- Original Message ----- >>>> From: earlywarning-bounces@ietf.org >>>> To: earlywarning@ietf.org >>>> Sent: Sat May 02 11:51:10 2009 >>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global >>>> CAPcommunity >>>> >>>> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: >>>> >>>>> How many people here know PRECISELY what "exigent" means without >>>>> looking it up. >>>>> >>>>> You need a term that has wider comprehension. >>>> >>>> Unfortunately, not many folks know precisely what "early warning" >>>> means either, although many assume they do until you press them for >>>> specifics. >>>> >>>> It seems like the current terms of reference are heavily loaded >>>> with >>>> emotional and cultural baggage. That's the problem with the word >>>> "authority"... it has several different senses and ultimately >>>> involves >>>> a subjective, or at least individual, interpretation of who and >>>> what >>>> constitutes authority (Government? Church? Academe? Culture?) >>>> >>>> "Warning" is likewise a fairly subtle notion when you really start >>>> to >>>> unpack it. In my particular public warning system we define it >>>> narrowly as "information about imminent threats to human life or >>>> health"... but other practitioners frame it differently. The word >>>> also spans the distinct domains of attention-management and >>>> information-sharing (is it a warning if folks are already aware of >>>> the >>>> subject matter?) >>>> >>>> So I'm wondering... might it be more productive to specify the >>>> particular observable characteristics we're concerned about >>>> (latency, >>>> reliability, verifiability, etc.) we're hoping to achieve rather >>>> than >>>> sloshing around in non-technical semantics? >>>> >>>> I get the sense that at least some of us are primarily concerned >>>> with >>>> the use of SIP, and although I have no personal investment in that >>>> particular approach, at least it sounds like the frame for a >>>> tractable >>>> technical problem. >>>> >>>> - Art >>>> _______________________________________________ >>>> earlywarning mailing list >>>> earlywarning@ietf.org >>>> https://www.ietf.org/mailman/listinfo/earlywarning >>> >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> > > From br@brianrosen.net Mon May 4 08:03:24 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3963A6A04 for ; Mon, 4 May 2009 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smpepQV4P5xp for ; Mon, 4 May 2009 08:03:23 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id D24583A6B9A for ; Mon, 4 May 2009 08:03:22 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M0zih-00025m-Qp; Mon, 04 May 2009 10:04:40 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> In-Reply-To: <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> Date: Mon, 4 May 2009 11:04:44 -0400 Message-ID: <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnMxphyFRY7lbe2QQW1XQOVwt6ebwAALyCg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 15:03:24 -0000 I think it's easier for the networks which have to allow these alerts (and treat them in some way we need to define) to know who the government entities are. That does bring up the issue that multiple entities need to authenticate the alert source. You are focused on the recipients, I mentioned the networks. We don't know yet who might be operating the message routing infrastructure, but it certainly is likely the network operators and, as in ecrit, there is the access network and the "calling" (VoIP/IM/...) network/service provider. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, May 04, 2009 10:43 AM To: Brian Rosen Cc: 'ken carlberg'; 'Art Botterell'; earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity Why is authorization easier for government? A school, university or company generally knows all of its students and employees, and can thus easily, relatively speaking, provide their public key to them ahead of time, so that an alert can be trivially verified as to its authenticity. For that, it doesn't matter whether the organization is run by a government (say, the Port Authority of NY&NJ) or a private entity (Columbia University). (I guess sending alerts to GM and Citibank would still be ok...). I'm ignoring the problem of university/ company visitors, as most existing alert systems don't deal with them, and reasonably rely on the "regulars" to tell them what's going on. The case of alerting is much harder for entities who need to reach everyone who happens to be in their territory, such as a county. They have to distribute some cryptographic material to everybody, including visitors, without knowing who they are. Thus, the operative difference seem much more of a "closed" vs. "open" membership, rather than whether the entity operating the alert has a seal and calls it itself county or state government. Henning On May 4, 2009, at 10:01 AM, Brian Rosen wrote: > Finally, a meaty subject; terminology really doesn't get us very > far. This > is important; really narrowing scope. > > Let's take a look at how far do we want to go: > > National Government with major warning - impending attack > Regional Government with life threatening event - Tornado or flash > flood > Local Government with life threatening event - hazmat spill > Local Government with important, but not threatening event - major > traffic > tieup > Local Government with useful event - public school closing > State Government College with life threatening event - school shooting > Private College with life threatening event - school shooting > Private elementary school with useful event - school closing > Enterprise with life threatening event - hazmat spill > Enterprise with useful event - building closing due to weather > > It's clear to me that all of these are very useful alerts. The > question > becomes, which of these should be in scope for the first charter? > > It seems to me that the issue of authorization is the biggie here, > and if we > started out limiting to government, even local government, it gets a > lot > easier. Once you allow a non-government entity to notify using the > mechanism, we make the authorization decision much more difficult. > I don't > see an in-between way to slice the above list other than government/ > non > government unless you say that the government can authorize other > entities > and you are relying on that authorization. > > I think the wishes of the networks that are transporting the alerts > come > into play; they would want a bright line on authorization. > > I suspect that once you have an authorized entity that can create an > alert, > what it gets to use that authorization for is a less interesting (to > the > IETF) issue. If you can issue alerts, you can issue any kind of > alert. > > Brian > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, May 04, 2009 9:20 AM > To: Brian Rosen > Cc: 'ken carlberg'; 'Art Botterell'; earlywarning@ietf.org > Subject: Re: [earlywarning] Depricate "Authority" - was : global > CAPcommunity > > This distinction is unlikely to work in the US, at least, as there are > many quasi-governmental entities. Classical example: some of the > largest scale notification systems today are deployed by college > campuses, particularly after the Virginia Tech shooting. There is no > technical reason why such function should be available to state > colleges and universities, but not to private institutions (which, in > the US, are in no way governed by the Federal or state government). > Same is true for large school districts, which can be either run by > the city/county or, say, the Catholic Church. > > Henning > > On May 4, 2009, at 8:42 AM, Brian Rosen wrote: > >> As with any IETF effort, limiting scope is useful to get progress >> in a >> reasonable time. With this effort, we have tried to limit the scope >> of >> "authority". It would be okay with me if we did limit it to >> government >> initially, although eventually I suspect we will expand it. >> >> I am very comfortable leaving the terminology as is: authority to >> citizen. >> I think we can reasonably explain that authority is initially >> government >> (national, state/province/region/, and local). We can reasonably >> explain >> that citizen includes residents and visitors. >> >> I'd like to keep the discussion more on the scope than on the >> terminology. >> >> Brian >> >> -----Original Message----- >> From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org >> ] >> On Behalf Of ken carlberg >> Sent: Sunday, May 03, 2009 9:14 AM >> To: Art Botterell >> Cc: earlywarning@ietf.org >> Subject: Re: [earlywarning] Depricate "Authority" - was : global >> CAPcommunity >> >> a good point. What the previous poster failed to elaborate on is >> that >> other SDO's like the ITU have made the association of authority == >> government, and given us terms and classification of communication >> models comprising: >> >> citizen-to-citizen, citizen-to-authority, >> authority-to-authority, and authority-to-citizen >> >> which is why we are seeing this terminology creep up on this list. >> one could take the approach that the IETF will go its own way, but I >> think it will be more constructive to acknowledge what's already >> gained traction and explore other terms. and in this specific case, >> something other than "authority" if we want to expand the target >> model. >> >> -ken >> >> >> >> On May 2, 2009, at 3:47 PM, Art Botterell wrote: >> >>> If so, why not say "government"? >>> >>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C, ATTLABS wrote: >>> >>>> Authority is government >>>> >>>> ----- Original Message ----- >>>> From: earlywarning-bounces@ietf.org >>>> To: earlywarning@ietf.org >>>> Sent: Sat May 02 11:51:10 2009 >>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global >>>> CAPcommunity >>>> >>>> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: >>>> >>>>> How many people here know PRECISELY what "exigent" means without >>>>> looking it up. >>>>> >>>>> You need a term that has wider comprehension. >>>> >>>> Unfortunately, not many folks know precisely what "early warning" >>>> means either, although many assume they do until you press them for >>>> specifics. >>>> >>>> It seems like the current terms of reference are heavily loaded >>>> with >>>> emotional and cultural baggage. That's the problem with the word >>>> "authority"... it has several different senses and ultimately >>>> involves >>>> a subjective, or at least individual, interpretation of who and >>>> what >>>> constitutes authority (Government? Church? Academe? Culture?) >>>> >>>> "Warning" is likewise a fairly subtle notion when you really start >>>> to >>>> unpack it. In my particular public warning system we define it >>>> narrowly as "information about imminent threats to human life or >>>> health"... but other practitioners frame it differently. The word >>>> also spans the distinct domains of attention-management and >>>> information-sharing (is it a warning if folks are already aware of >>>> the >>>> subject matter?) >>>> >>>> So I'm wondering... might it be more productive to specify the >>>> particular observable characteristics we're concerned about >>>> (latency, >>>> reliability, verifiability, etc.) we're hoping to achieve rather >>>> than >>>> sloshing around in non-technical semantics? >>>> >>>> I get the sense that at least some of us are primarily concerned >>>> with >>>> the use of SIP, and although I have no personal investment in that >>>> particular approach, at least it sounds like the frame for a >>>> tractable >>>> technical problem. >>>> >>>> - Art >>>> _______________________________________________ >>>> earlywarning mailing list >>>> earlywarning@ietf.org >>>> https://www.ietf.org/mailman/listinfo/earlywarning >>> >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning >> > > From hgs@cs.columbia.edu Mon May 4 09:00:22 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF29328C1C6 for ; Mon, 4 May 2009 09:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwGdbPTBoP-J for ; Mon, 4 May 2009 09:00:21 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id C49BC28C12B for ; Mon, 4 May 2009 09:00:21 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n44G1bNF027924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 12:01:39 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 12:01:38 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:00:23 -0000 On May 4, 2009, at 11:04 AM, Brian Rosen wrote: > I think it's easier for the networks which have to allow these > alerts (and > treat them in some way we need to define) to know who the government > entities are. I'm not sure I understand what you mean by "networks". I can see that this might be possible for SMS, but how would a SIP MESSAGE-delivering server know that (or care)? > > > That does bring up the issue that multiple entities need to > authenticate the > alert source. You are focused on the recipients, I mentioned the > networks. > We don't know yet who might be operating the message routing > infrastructure, Are you talking SIP proxies (or XMPP servers, etc.) or some other entity? > > but it certainly is likely the network operators Why? This seems much more like an application-layer function to me, and just like ECRIT made the wise decision to separate application and network layer operators, we should do the same. > and, as in ecrit, there is > the access network and the "calling" (VoIP/IM/...) network/service > provider. > > Brian From br@brianrosen.net Mon May 4 09:29:18 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345643A6D49 for ; Mon, 4 May 2009 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8IOWz9BslOA for ; Mon, 4 May 2009 09:29:17 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 59B703A6D16 for ; Mon, 4 May 2009 09:29:17 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M113n-0002zV-QW; Mon, 04 May 2009 11:30:33 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> In-Reply-To: Date: Mon, 4 May 2009 12:30:34 -0400 Message-ID: <0da801c9ccd5$a9506b50$fbf141f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM0ZgrLv1kSE/XT3KgKVUiNPVihQAAqogw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:29:18 -0000 Although I hope we end up with an opt-in subscription option, the minimum required here is a broadcast. That requires some entity to direct the broadcast, based on location. That in turn means that we have the network operators, probably BOTH the access network (who knows the location) and the alert application service provider. The latter could be some public entity, but I think it's unlikely. More likely is that it's some SP that already provides a service like texting. It may be that the access network also provides such a service, don't know, but I do hope we keep the access network operator separate from that SP in our work. Then, they could be operated by the same entity or different entities. The latter probably does run some kind of SIP server/XMPP server or whatever we use for transport and routing. Whomever it is, it will need to authenticate and authorize alert senders independent of end devices authentication and authorization. I think starting with governments makes authentication (and authorization) easier. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, May 04, 2009 12:02 PM To: Brian Rosen Cc: 'ken carlberg'; 'Art Botterell'; earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity On May 4, 2009, at 11:04 AM, Brian Rosen wrote: > I think it's easier for the networks which have to allow these > alerts (and > treat them in some way we need to define) to know who the government > entities are. I'm not sure I understand what you mean by "networks". I can see that this might be possible for SMS, but how would a SIP MESSAGE-delivering server know that (or care)? > > > That does bring up the issue that multiple entities need to > authenticate the > alert source. You are focused on the recipients, I mentioned the > networks. > We don't know yet who might be operating the message routing > infrastructure, Are you talking SIP proxies (or XMPP servers, etc.) or some other entity? > > but it certainly is likely the network operators Why? This seems much more like an application-layer function to me, and just like ECRIT made the wise decision to separate application and network layer operators, we should do the same. > and, as in ecrit, there is > the access network and the "calling" (VoIP/IM/...) network/service > provider. > > Brian From carlberg@g11.org.uk Mon May 4 09:56:50 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402393A7092 for ; Mon, 4 May 2009 09:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoUarxkuCUhH for ; Mon, 4 May 2009 09:56:49 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 649BB3A6E3C for ; Mon, 4 May 2009 09:56:49 -0700 (PDT) Received: from c-98-218-170-127.hsd1.va.comcast.net ([98.218.170.127]:62618 helo=[192.168.1.120]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M11UT-00052t-JT; Mon, 04 May 2009 16:58:05 +0000 Message-Id: From: ken carlberg To: "Brian Rosen" In-Reply-To: <0da801c9ccd5$a9506b50$fbf141f0$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 12:58:05 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> <0da801c9ccd5$a9506b50$fbf141f0$@net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 16:56:50 -0000 On May 4, 2009, at 12:30 PM, Brian Rosen wrote: > Although I hope we end up with an opt-in subscription option, the > minimum > required here is a broadcast. could you be a little more precise? Does this means that if some transit network prefers an application layer solution (let's say in the form of application layer multicast -- ie, unicast-only dissemination via a collection of servers) and chooses not to support a network layer broadcast (or multicast) solution, they are out of the picture? > That requires some entity to direct the > broadcast, based on location. That in turn means that we have the > network > operators, probably BOTH the access network (who knows the location) > and the > alert application service provider. The latter could be some public > entity, > but I think it's unlikely. More likely is that it's some SP that > already > provides a service like texting. It may be that the access network > also > provides such a service, don't know, but I do hope we keep the access > network operator separate from that SP in our work. Then, they > could be > operated by the same entity or different entities. The latter > probably does > run some kind of SIP server/XMPP server or whatever we use for > transport and > routing. > > Whomever it is, it will need to authenticate and authorize alert > senders > independent of end devices authentication and authorization. I think > starting with governments makes authentication (and authorization) > easier. I'm with Henning in still wondering what is it technically (or even policy) that makes authentication/authorization "easier" for governments than some other non-government enitity/organization. -ken From hgs@cs.columbia.edu Mon May 4 10:14:54 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECECF3A7125 for ; Mon, 4 May 2009 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AURdy6-tFyPg for ; Mon, 4 May 2009 10:14:54 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 857EE3A70AA for ; Mon, 4 May 2009 10:14:51 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n44HG5IR006569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 13:16:05 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: ken carlberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 13:16:06 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> <0da801c9ccd5$a9506b50$fbf141f0$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 17:14:55 -0000 My general concern is that we seem to be making general statements like "need government" that are driven by assumptions of the technical realization that we haven't really discussed. That seems like a somewhat unusual way to deal with engineering requirements and charters. The danger is that such statements then get applied to situations where they make little sense. If I subscribe, via sips, to a SIP event notification and have the notifiers public key, none of these considerations apply, for example. Henning On May 4, 2009, at 12:58 PM, ken carlberg wrote: > > On May 4, 2009, at 12:30 PM, Brian Rosen wrote: > >> Although I hope we end up with an opt-in subscription option, the >> minimum >> required here is a broadcast. > > could you be a little more precise? Does this means that if some > transit network prefers an application layer solution (let's say in > the form of application layer multicast -- ie, unicast-only > dissemination via a collection of servers) and chooses not to > support a network layer broadcast (or multicast) solution, they are > out of the picture? > >> That requires some entity to direct the >> broadcast, based on location. That in turn means that we have the >> network >> operators, probably BOTH the access network (who knows the >> location) and the >> alert application service provider. The latter could be some >> public entity, >> but I think it's unlikely. More likely is that it's some SP that >> already >> provides a service like texting. It may be that the access network >> also >> provides such a service, don't know, but I do hope we keep the access >> network operator separate from that SP in our work. Then, they >> could be >> operated by the same entity or different entities. The latter >> probably does >> run some kind of SIP server/XMPP server or whatever we use for >> transport and >> routing. >> >> Whomever it is, it will need to authenticate and authorize alert >> senders >> independent of end devices authentication and authorization. I think >> starting with governments makes authentication (and authorization) >> easier. > > I'm with Henning in still wondering what is it technically (or even > policy) that makes authentication/authorization "easier" for > governments than some other non-government enitity/organization. > > -ken > > From br@brianrosen.net Mon May 4 10:47:12 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38C53A7019 for ; Mon, 4 May 2009 10:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrv6ybks91O4 for ; Mon, 4 May 2009 10:47:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BE72E3A706E for ; Mon, 4 May 2009 10:47:09 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M12HB-0005CU-In; Mon, 04 May 2009 12:48:25 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ken carlberg'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> <0da801c9ccd5$a9506b50$fbf141f0$@net> In-Reply-To: Date: Mon, 4 May 2009 13:48:26 -0400 Message-ID: <0dc501c9cce0$896fb5b0$9c4f2110$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM2/61S2qFn1bHS4KZz/H8fb1PigAAHtlA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 17:47:12 -0000 It would help to go back to the charter language. The current proposal is (in part): The class of alerts that are of interest to this working group are those sent by authorized agents, primarily government agents. The mechanisms that result from this work may be applicable to a wider group of authorized agents, but our current work is focused on emergency alerts from governments. Nevertheless, we desire to design this mechanism so that it can be used by national, regional or local authorities and cover alerts for impending Tsunamis which might affect most of a county down to a road closing due to an automobile accident. A critical element of the work are the mechanisms that assure that only authorized agents can send alerts. The recipients of these alerts are the wide range of devices connected to the Internet and private IP networks which humans may have "at hand" to get such events, as well as automatons who may take action based on the alerts. This implies that the content of the alert contains some information which is intended to be consumed by humans, and some which is intended to be consumed by automatons. Ideally, the alerts would contain, or refer to media other than text media (cf audio and/or video), but the present work is restricted to human readable text, which may be mechanically rendered by the device in other forms (text to speech for example). Which devices should get alerts is primarily driven by location. The first set of recipients that must be catered for are those within the area affected by the alert. In many jurisdictions, there are regulations the define whether recipients within the affected area have opt-in or opt-out capability, but the protocols we will define will include both opt in and opt out mechanisms. This work builds on existing IETF geopriv location work. Another class of recipients that are in scope of the work are explicit opt-in subscriptions which ask for alerts that are sent to an associated party. An example of such a subscription would be "send me alerts which are sent too my daughter based on her location". Both of these classes of recipients must operate at Internet scale, which is one of the major challenges to the work. Many tools have been developed within the IETF to scale messaging, which will be exploited by this effort. Examples include multicast. The work must function on the networks we have, however, and as such must take into account what is actually deployed, or could reasonably be deployed. --- end of proposed charter language --- The charter, like any charter, attempts to limit scope, without presenting cast in concrete solutions. I think if we tried to handle too wide a range of alert generators, we would have problems, both in getting a charter approved and in getting the work done. I too would LIKE to handle a wider range of alert generators. However, I think limiting scope to primarily government agents is a helpful thing for the first charter. Similarly, we have to handle the "broadcast" situation, and I don't mean the word to imply multicast, but rather the notion that everyone gets the alert if they are in the affected area, with the possibility that opt-out is not allowed. The mechanism by which we get the alert to all devices in the affected area is TBD. While I think having every notifier's public key is a nice solution to an authentication problem, it might be hard to arrange. Among other things, you have to be able to get off a plane and get alerts from local authorities. Right now, I don't want to discuss solutions, but charter language, and I'd rather have narrow scope. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Monday, May 04, 2009 1:16 PM To: ken carlberg Cc: Brian Rosen; 'Art Botterell'; earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity My general concern is that we seem to be making general statements like "need government" that are driven by assumptions of the technical realization that we haven't really discussed. That seems like a somewhat unusual way to deal with engineering requirements and charters. The danger is that such statements then get applied to situations where they make little sense. If I subscribe, via sips, to a SIP event notification and have the notifiers public key, none of these considerations apply, for example. Henning On May 4, 2009, at 12:58 PM, ken carlberg wrote: > > On May 4, 2009, at 12:30 PM, Brian Rosen wrote: > >> Although I hope we end up with an opt-in subscription option, the >> minimum >> required here is a broadcast. > > could you be a little more precise? Does this means that if some > transit network prefers an application layer solution (let's say in > the form of application layer multicast -- ie, unicast-only > dissemination via a collection of servers) and chooses not to > support a network layer broadcast (or multicast) solution, they are > out of the picture? > >> That requires some entity to direct the >> broadcast, based on location. That in turn means that we have the >> network >> operators, probably BOTH the access network (who knows the >> location) and the >> alert application service provider. The latter could be some >> public entity, >> but I think it's unlikely. More likely is that it's some SP that >> already >> provides a service like texting. It may be that the access network >> also >> provides such a service, don't know, but I do hope we keep the access >> network operator separate from that SP in our work. Then, they >> could be >> operated by the same entity or different entities. The latter >> probably does >> run some kind of SIP server/XMPP server or whatever we use for >> transport and >> routing. >> >> Whomever it is, it will need to authenticate and authorize alert >> senders >> independent of end devices authentication and authorization. I think >> starting with governments makes authentication (and authorization) >> easier. > > I'm with Henning in still wondering what is it technically (or even > policy) that makes authentication/authorization "easier" for > governments than some other non-government enitity/organization. > > -ken > > From hardie@qualcomm.com Mon May 4 10:58:10 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 299653A6AC6 for ; Mon, 4 May 2009 10:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEE2OQGaIpCa for ; Mon, 4 May 2009 10:58:09 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1E0FA3A69FC for ; Mon, 4 May 2009 10:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1241459975; x=1272995975; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<0dc501c9cce0$896fb5b0$9 c4f2110$@net>|References:=20<14C85D6CCBE92743AF33663BF5D2 4EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com>=0D=0A=20<4C3C5B 6D-81D5-4B63-A1F1-6429A9980AED@incident.com>=0D=0A=20<2B2 1B310-A861-4D01-87DC-3229EF95965A@g11.org.uk>=0D=0A=20<0d 3101c9ccb5$d98e7a70$8cab6f50$@net>=0D=0A=20<31F5CFB3-6434 -4414-926C-1659A0AE4C93@cs.columbia.edu>=0D=0A=20<0d5e01c 9ccc0$e4966b20$adc34160$@net>=0D=0A=20<97F83B40-E741-4A83 -A2CE-CF64181757DB@cs.columbia.edu>=0D=0A=20<0d6501c9ccc9 $aa6469d0$ff2d3d70$@net>=0D=0A=20=0D=0A=20<0da801c9ccd5$a950 6b50$fbf141f0$@net>=0D=0A=20=0D=0A=20=0D=0A=20<0dc501c9cce0$896fb5b0 $9c4f2110$@net>|Date:=20Mon,=204=20May=202009=2010:59:25 =20-0700|To:=20Brian=20Rosen=20,=0D=0A =20=20=20=20=20=20=20=20"'Henning=20Schulzrinne'"=0D=0A =09,=0D=0A=20=20=20=20=20=20=20=20"' ken=20carlberg'"=20|From:=20Ted=20Ha rdie=20|Subject:=20charter=20text |CC:=20"earlywarning@ietf.org"=20 |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5605"=3B=20 a=3D"17752301"; bh=ozGyxgXL2FNdOrGp0WSE6qXlDw2xw1c/b9QMbGWYNaw=; b=QSYrqzsMdoQFgukJjm+OeSioa41mMeAWeaw7aq9AA3CParBLtipHG6V3 W36mWMnyEs5b/M1Ci6KUhxDPZTNXUmMlYkKDbiloplXrhvObKkab6SCmO MSVC0LhBKYuNsfKQV7NzgdlgGXPy6sFhzYXj6DFbPz5VpbTMMHSYIcG4u o=; X-IronPort-AV: E=McAfee;i="5300,2777,5605"; a="17752301" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2009 10:59:28 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n44HxSvk014153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 10:59:28 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n44HxSkK015951 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 May 2009 10:59:28 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 4 May 2009 10:59:28 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 10:59:27 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <0dc501c9cce0$896fb5b0$9c4f2110$@net> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> <0da801c9ccd5$a9506b50$fbf141f0$@net> <0dc501c9cce0$896fb5b0$9c4f2110$@net> Date: Mon, 4 May 2009 10:59:25 -0700 To: Brian Rosen , "'Henning Schulzrinne'" , "'ken carlberg'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "earlywarning@ietf.org" Subject: [earlywarning] charter text X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 17:58:10 -0000 At 10:48 AM -0700 5/4/09, Brian Rosen wrote: >It would help to go back to the charter language. >Another class of recipients that are in scope of the work are explicit >opt-in subscriptions which ask for alerts that are sent to an associated >party. An example of such a subscription would be "send me alerts which are >sent too my daughter based on her location". This seems to imply that the system must track whether or not an alert was sent to your daughter (and hence her opt-in state), rather than simply saying "send me alerts for the follow area, in which I am not currently present". It is then up to you to designate the area. This is simple. The "track your daughter" system is hard, and it has serious privacy consequences. If you simply want your daughter's user agent to echo alerts to you, I think that is also possible--but it would be separate from this system entirely and its opt-in characteristics are clearly different.. regards, Ted From jmpolk@cisco.com Mon May 4 10:59:04 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9739B3A6C1E for ; Mon, 4 May 2009 10:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrlznFomH1Hv for ; Mon, 4 May 2009 10:58:57 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 81FAB3A6B6C for ; Mon, 4 May 2009 10:58:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238976000"; d="scan'208";a="74545087" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 04 May 2009 18:00:23 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n44I0NVR010605; Mon, 4 May 2009 11:00:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n44I0Nd9022189; Mon, 4 May 2009 18:00:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 11:00:23 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.17.58]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 11:00:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 May 2009 13:00:19 -0500 To: trutkowski@netmagic.com, Hannes Tschofenig From: "James M. Polk" In-Reply-To: <49FC37C7.6050504@netmagic.com> References: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> <49FC37C7.6050504@netmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 May 2009 18:00:22.0940 (UTC) FILETIME=[31F22DC0:01C9CCE2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2042; t=1241460023; x=1242324023; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20Some=20further=20scopi ng=20issues |Sender:=20; bh=v4cPcAxAm5LdfA4h2d6SN5LjnEY+uZvGpAZt+ZI3Gds=; b=GWLuKPbHDY2WNpEcMve/Bjrni5u/NXFku6TGZuxIqYhuurgH0Ff8tggJhD qudAcCxfZI5SZuhj7HefaVtiHMFWu9ER7lNQI86mSu9lAiLdSo5wV3Ljrlod +1As+I/4cy; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Some further scoping issues X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 17:59:04 -0000 At 07:08 AM 5/2/2009, Tony Rutkowski wrote: >These seem like good admonitions. The broader scope will provide >greater value to work, rather than attempting to deal a specific kind >of implementation that gets into an already well-established regulatory >domain. > >For those of you unfamiliar with the new FCC Part 10 rules specifying >Commercial Mobile Alert System (CMAS) implementations, they are available at >http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&rgn=div5&view=text&node=47:1.0.1.1.10&idno=47 >For U.S. implementations, note that 47 CFR Sec. 10.410 requires that >"Presidential >Alerts preempt all other Alert Messages." Again, Tony, can you explain to many of us (if not to all of us) why a *message* needs to preempt (i.e., delete) another *message*, and not merely delay the non-presidential *message* until the presidential message is sent (i.e., hold in memory until there is no message of higher priority)? I'm thinking we're talking past each other. James >ciao, >--tony > > For the future work in this group I furthermore suggest that > > > > * we do not focus our efforts on defining an architecture used for > > distributing of alert messages (like we did it in ECRIT with the > > PhoneBCP/Framework document). Instead, we develop building blocks (like > > conveying CAP in SIP). I believe we will run into lots of problems with the > > different usages, different solutions that have been specified elsewhere > > already, etc. > > > > * we do not pick a single alert document format (as a > > mandatory-to-implement), like CAP or GeoRSS, but instead give those who > > deploy these mechanisms freedom. > > > > * we do not define our own alert document format (because there are other > > formats available already). > > > > We can always decide later to document ways how people use our stuff. > > > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From jmpolk@cisco.com Mon May 4 11:47:49 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C19B63A6AB6 for ; Mon, 4 May 2009 11:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDpcC6dSDMYL for ; Mon, 4 May 2009 11:47:48 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B24543A684F for ; Mon, 4 May 2009 11:47:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,292,1238976000"; d="scan'208";a="161653111" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 04 May 2009 18:49:14 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n44InEGu009815; Mon, 4 May 2009 11:49:14 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n44InE5b018760; Mon, 4 May 2009 18:49:14 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 11:49:14 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.17.58]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 11:49:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 May 2009 13:49:12 -0500 To: "Brian Rosen" , "'ken carlberg'" From: "James M. Polk" In-Reply-To: <0d3201c9ccb6$28857980$79906c80$@net> References: <49FB4855.4070305@bbn.com> <0d3201c9ccb6$28857980$79906c80$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 May 2009 18:49:14.0156 (UTC) FILETIME=[05163EC0:01C9CCE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3334; t=1241462954; x=1242326954; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=bDlWt5S/0/Fhgqgz4qgMf9vJ472miNYtkaMMzYoImDk=; b=SLR0fpcnlCDsNDcaxfFT8bl/JdMrYuwn1Oc0fDVdLVRaBnWuGrYURqg43W hFUvSD/fpXyu5XKSTVDuhNBsjGp8y3KFkm4m1BmbIyHnBje+MSx8/S7Azv6w PHT+BdtrZe; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 18:47:49 -0000 Brian (all) I'm really confused wrt the messages and preemption -- what are we talking about here? Is this real-time streaming or not? If not, the lower priority messages get delayed until the higher priority messages clear the queue, right? Imagine a network where there are only early warning messages (putting aside the discussion about "early warning" perhaps not being the best phrase at the moment - that's a separate discussion), if each messages is marked with a DSCP, and the appropriate DSCP for the type of message (i.e., presidential gets the highest, whatever's next - gets the next highest DSCP, and so on) -- how *can't* this work? Each message is exactly one messages long -- unless we're talking about something like MSRP -- which no one has brought up yet -- and I'd like to hear the justification for IM in this case, and not a subscription based approach. Given that each message is only 1 (ONE) message long, and knowing the physics of only being able to transmit one message at a time from any one interface, how can't a scheduler and a queue solve this (as long as what gets put into the queue is put into the right queue to begin with)? In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the one message being transmitted is delayed until it comes up in the queue. There is never a reason for a deletion of a message (unless there is a timer associated within a message - in which case, this timer getting to ZERO isn't a preemption event, it's a starvation event). James At 07:45 AM 5/4/2009, Brian Rosen wrote: >Right now, I'd prefer that we assume that messages are short enough that the >complexity of preemption is worse that the delay of transmission. I >wouldn't mind priority if there was a queue of alerts to be sent, but the >notion that we preempt is, I think, not worth it. > >Brian > >-----Original Message----- >From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org] >On Behalf Of ken carlberg >Sent: Sunday, May 03, 2009 9:48 AM >To: James M. Polk >Cc: earlywarning@ietf.org >Subject: Re: [earlywarning] global CAP community > > >On May 1, 2009, at 5:19 PM, James M. Polk wrote: > > >> What are you planning to preempt? > > > > I was wondering the same thing, as priority seems natural (wrt > > server resources, and indication of the type of message), but this > > is never going to be a stream, so I don't think we'll likely have 1 > > message preempt another (but we may delay one message relative to > > another). > >I would agree on the general case, but some constrained environments >would require preemption, with possible subsequent transmission of the >preempted session. as an example, any alerting system that includes >meteor scatter communication links definitely needs preemption, and >one could probably extend this to a number of LMR systems as well. > >the key thing to keep in mind is that some alerting systems may be >disjoint in the variation of communication mechanisms being deployed, >and in turn, that radioactive word of preemption may not be >ubiquitously applied. > >-ken > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From hardie@qualcomm.com Mon May 4 12:19:17 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D4128C167 for ; Mon, 4 May 2009 12:19:17 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf2Flsh+5CrE for ; Mon, 4 May 2009 12:19:16 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 53C7E28C111 for ; Mon, 4 May 2009 12:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1241464842; x=1273000842; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<0ddb01c9ccea$08db67a0$1 a9236e0$@net>|References:=20<14C85D6CCBE92743AF33663BF5D2 4EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com>=0D=0A=20<4C3C5B 6D-81D5-4B63-A1F1-6429A9980AED@incident.com>=0D=0A=20<2B2 1B310-A861-4D01-87DC-3229EF95965A@g11.org.uk>=0D=0A=20<0d 3101c9ccb5$d98e7a70$8cab6f50$@net>=0D=0A=20<31F5CFB3-6434 -4414-926C-1659A0AE4C93@cs.columbia.edu>=0D=0A=20<0d5e01c 9ccc0$e4966b20$adc34160$@net>=0D=0A=20<97F83B40-E741-4A83 -A2CE-CF64181757DB@cs.columbia.edu>=0D=0A=20<0d6501c9ccc9 $aa6469d0$ff2d3d70$@net>=0D=0A=20=0D=0A=20<0da801c9ccd5$a950 6b50$fbf141f0$@net>=0D=0A=20=0D=0A=20=0D=0A=20<0dc501c9cce0$896fb5b0 $9c4f2110$@net>=0D=0A=20=0D=0A=20<0ddb01c9ccea$08db67a0$1a9236e0$@net> |Date:=20Mon,=204=20May=202009=2012:20:38=20-0700|To:=20B rian=20Rosen=20,=0D=0A=20=20=20=20=20 =20=20=20"'Henning=20Schulzrinne'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'ken=20carlberg'" =20|From:=20Ted=20Hardie=20|Subject:=20RE:=20charter=20text|CC:=20"early warning@ietf.org"=20|Content-Type: =20text/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20 E=3DMcAfee=3Bi=3D"5300,2777,5605"=3B=20a=3D"17756253"; bh=ZE0WWQ06WQK4KDWxmlTq1OrX3NNvrEOBdBH1hcJmUQA=; b=bh4OGYteJabrYSesTjqiad16TggdPXNMz80P89enz0DJb048l5YqYBoL JkBSC328TOfGGOOgZfZPms+A3msd+ITWGCavrl7KdW7XP3eg5X4lwqWte 10VhT2AzHnxAtvTZ3tJ7vX83iFdwVdE9ikz7fqANyXc3vjvYqlRQV3DUk I=; X-IronPort-AV: E=McAfee;i="5300,2777,5605"; a="17756253" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 May 2009 12:20:42 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n44JKfCJ026210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 May 2009 12:20:42 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n44JKfVm010343 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 May 2009 12:20:41 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 4 May 2009 12:20:41 -0700 Received: from [10.227.68.132] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 4 May 2009 12:20:41 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <0ddb01c9ccea$08db67a0$1a9236e0$@net> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> <0da801c9ccd5$a9506b50$fbf141f0$@net> <0dc501c9cce0$896fb5b0$9c4f2110$@net> <0ddb01c9ccea$08db67a0$1a9236e0$@net> Date: Mon, 4 May 2009 12:20:38 -0700 To: Brian Rosen , "'Henning Schulzrinne'" , "'ken carlberg'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "earlywarning@ietf.org" Subject: Re: [earlywarning] charter text X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:19:17 -0000 At 11:56 AM -0700 5/4/09, Brian Rosen wrote: >I don't care how we get there. > >The notion of the system "tracking" my daughter doesn't bother me as long as >all we're getting out of that is the same alerts. >We're not really tracking, we're replicating an alert that went to her. Let's say your daughter failed to opt-in to the Tsunami warning because she was on the U.S. East Coast, and they are incredibly rare. You, being the dad, opt-in globally to all warnings. You will get a warning of the Tsunami when the Canary Island's volcano slides, even if your daughter did not opt-in. Why would you make a mandatory tie of your choices about what warnings to get to the ones your daughter made? [Why is this choice being put into the charter, in other words?] As for you not worrying about the system tracking your daughter, I'm glad to hear it, but I don't think we can ignore the problem in the charter. If you tie the warnings to an individual, you have to transition the warnings as the individual moves around, which gives you a way of tracking the individual. If you suddenly see Kansas Tornado watches, when you are expecting your daughter to be Ohio, you are getting information the daughter may not have wanted you to have. >"Send me alerts from this place" isn't really right, but it might be another >useful thing to have. I think it is the right choice, honestly. If your daughter wants to share her location with you, she can do that with standard presence mechanisms. You can subscribe and eliminate alert requests based on that without forcing the back-end systems to track the individual and what alerts are being received. regards, Ted >Brian > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Monday, May 04, 2009 1:59 PM >To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg' >Cc: earlywarning@ietf.org >Subject: charter text > >At 10:48 AM -0700 5/4/09, Brian Rosen wrote: >>It would help to go back to the charter language. > > > >>Another class of recipients that are in scope of the work are explicit >>opt-in subscriptions which ask for alerts that are sent to an associated >>party. An example of such a subscription would be "send me alerts which >are >>sent too my daughter based on her location". > >This seems to imply that the system must track whether or not >an alert was sent to your daughter (and hence her opt-in state), >rather than simply saying "send me alerts for the follow area, >in which I am not currently present". It is then up to you to designate >the area. This is simple. The "track your daughter" system is hard, >and it has serious privacy consequences. > >If you simply want your daughter's user agent to echo alerts to you, >I think that is also possible--but it would be separate from this system >entirely and its opt-in characteristics are clearly different.. > > regards, > Ted From carlberg@g11.org.uk Mon May 4 12:23:55 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0823A693E for ; Mon, 4 May 2009 12:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aawk6NNbi+Le for ; Mon, 4 May 2009 12:23:54 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E82163A68A3 for ; Mon, 4 May 2009 12:23:53 -0700 (PDT) Received: from c-98-218-170-127.hsd1.va.comcast.net ([98.218.170.127]:63818 helo=[192.168.1.120]) by portland.eukhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1M13mr-0007hF-M7; Mon, 04 May 2009 19:25:13 +0000 Message-Id: <7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> From: ken carlberg To: "James M. Polk" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 15:25:14 -0400 References: <49FB4855.4070305@bbn.com> <0d3201c9ccb6$28857980$79906c80$@net> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:23:55 -0000 James, My working assumption was that this effort was not constrained to real- time streaming, but I'll support Brian's theme of adding a more narrow scope if folks choose to just deal with only that type. As for preemption, ages ago I worked on a system, for one arm of the government, that *required* preemption as an option because parts of the system could include bandwidth constrained environments. And the problem was accentuated by notifications that could extend for minutes at a time, which was considered an unacceptable period of time to wait. So that raises another question, which part of the government (or which government with its individual rules/regulations) are we talking about? As for modern times, picture crawlers in use today that send out long messages (eg, the list of school and event snow related closings in large cities) that run for several minutes. I'd imagine that it would be desirable to preempt that "session" by another authenticated source that had a more important message to distribute than in waiting for the first message to drain out. I'm also quite sympathetic to Brian's desire to limit the scope. On the other hand, I'm concerned that we'll be continually bogged down with comments/positions relating to specific laws and regulations from governments if that remains the sole target of the source of alerts. In a sense, we have already experienced that in the past few days. -ken On May 4, 2009, at 2:49 PM, James M. Polk wrote: > Brian (all) > > I'm really confused > > wrt the messages and preemption -- what are we talking about here? > > Is this real-time streaming or not? > > If not, the lower priority messages get delayed until the higher > priority messages clear the queue, right? > > Imagine a network where there are only early warning messages > (putting aside the discussion about "early warning" perhaps not > being the best phrase at the moment - that's a separate discussion), > if each messages is marked with a DSCP, and the appropriate DSCP for > the type of message (i.e., presidential gets the highest, whatever's > next - gets the next highest DSCP, and so on) -- how *can't* this > work? > > Each message is exactly one messages long -- unless we're talking > about something like MSRP -- which no one has brought up yet -- and > I'd like to hear the justification for IM in this case, and not a > subscription based approach. > > Given that each message is only 1 (ONE) message long, and knowing > the physics of only being able to transmit one message at a time > from any one interface, how can't a scheduler and a queue solve this > (as long as what gets put into the queue is put into the right queue > to begin with)? > > In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the > one message being transmitted is delayed until it comes up in the > queue. There is never a reason for a deletion of a message (unless > there is a timer associated within a message - in which case, this > timer getting to ZERO isn't a preemption event, it's a starvation > event). > > James > > At 07:45 AM 5/4/2009, Brian Rosen wrote: >> Right now, I'd prefer that we assume that messages are short enough >> that the >> complexity of preemption is worse that the delay of transmission. I >> wouldn't mind priority if there was a queue of alerts to be sent, >> but the >> notion that we preempt is, I think, not worth it. >> >> Brian >> >> -----Original Message----- >> From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org >> ] >> On Behalf Of ken carlberg >> Sent: Sunday, May 03, 2009 9:48 AM >> To: James M. Polk >> Cc: earlywarning@ietf.org >> Subject: Re: [earlywarning] global CAP community >> >> >> On May 1, 2009, at 5:19 PM, James M. Polk wrote: >> >> >> What are you planning to preempt? >> > >> > I was wondering the same thing, as priority seems natural (wrt >> > server resources, and indication of the type of message), but this >> > is never going to be a stream, so I don't think we'll likely have 1 >> > message preempt another (but we may delay one message relative to >> > another). >> >> I would agree on the general case, but some constrained environments >> would require preemption, with possible subsequent transmission of >> the >> preempted session. as an example, any alerting system that includes >> meteor scatter communication links definitely needs preemption, and >> one could probably extend this to a number of LMR systems as well. >> >> the key thing to keep in mind is that some alerting systems may be >> disjoint in the variation of communication mechanisms being deployed, >> and in turn, that radioactive word of preemption may not be >> ubiquitously applied. >> >> -ken >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > From br@brianrosen.net Mon May 4 12:39:57 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2B828C1BC for ; Mon, 4 May 2009 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8TmdaBhvdIk for ; Mon, 4 May 2009 12:39:56 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9568828C186 for ; Mon, 4 May 2009 12:39:56 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M142I-0001M9-1a; Mon, 04 May 2009 14:41:12 -0500 From: "Brian Rosen" To: "'ken carlberg'" , "'James M. Polk'" References: <49FB4855.4070305@bbn.com> <0d3201c9ccb6$28857980$79906c80$@net> <7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> In-Reply-To: <7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> Date: Mon, 4 May 2009 15:41:17 -0400 Message-ID: <0df401c9ccf0$4dea2e20$e9be8a60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM7gtD1v4vnSHzSo6l5vGplWMupgAAgf7g Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:39:57 -0000 I think we're sending an alert, not a media stream. The alert can have a URI in it that may point to a media stream, but it's not in the alert itself. I'm hoping the size of the alert is small enough that preemption is not worthwhile. We'll see. Brian -----Original Message----- From: ken carlberg [mailto:carlberg@g11.org.uk] Sent: Monday, May 04, 2009 3:25 PM To: James M. Polk Cc: Brian Rosen; earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community James, My working assumption was that this effort was not constrained to real- time streaming, but I'll support Brian's theme of adding a more narrow scope if folks choose to just deal with only that type. As for preemption, ages ago I worked on a system, for one arm of the government, that *required* preemption as an option because parts of the system could include bandwidth constrained environments. And the problem was accentuated by notifications that could extend for minutes at a time, which was considered an unacceptable period of time to wait. So that raises another question, which part of the government (or which government with its individual rules/regulations) are we talking about? As for modern times, picture crawlers in use today that send out long messages (eg, the list of school and event snow related closings in large cities) that run for several minutes. I'd imagine that it would be desirable to preempt that "session" by another authenticated source that had a more important message to distribute than in waiting for the first message to drain out. I'm also quite sympathetic to Brian's desire to limit the scope. On the other hand, I'm concerned that we'll be continually bogged down with comments/positions relating to specific laws and regulations from governments if that remains the sole target of the source of alerts. In a sense, we have already experienced that in the past few days. -ken On May 4, 2009, at 2:49 PM, James M. Polk wrote: > Brian (all) > > I'm really confused > > wrt the messages and preemption -- what are we talking about here? > > Is this real-time streaming or not? > > If not, the lower priority messages get delayed until the higher > priority messages clear the queue, right? > > Imagine a network where there are only early warning messages > (putting aside the discussion about "early warning" perhaps not > being the best phrase at the moment - that's a separate discussion), > if each messages is marked with a DSCP, and the appropriate DSCP for > the type of message (i.e., presidential gets the highest, whatever's > next - gets the next highest DSCP, and so on) -- how *can't* this > work? > > Each message is exactly one messages long -- unless we're talking > about something like MSRP -- which no one has brought up yet -- and > I'd like to hear the justification for IM in this case, and not a > subscription based approach. > > Given that each message is only 1 (ONE) message long, and knowing > the physics of only being able to transmit one message at a time > from any one interface, how can't a scheduler and a queue solve this > (as long as what gets put into the queue is put into the right queue > to begin with)? > > In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the > one message being transmitted is delayed until it comes up in the > queue. There is never a reason for a deletion of a message (unless > there is a timer associated within a message - in which case, this > timer getting to ZERO isn't a preemption event, it's a starvation > event). > > James > > At 07:45 AM 5/4/2009, Brian Rosen wrote: >> Right now, I'd prefer that we assume that messages are short enough >> that the >> complexity of preemption is worse that the delay of transmission. I >> wouldn't mind priority if there was a queue of alerts to be sent, >> but the >> notion that we preempt is, I think, not worth it. >> >> Brian >> >> -----Original Message----- >> From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org >> ] >> On Behalf Of ken carlberg >> Sent: Sunday, May 03, 2009 9:48 AM >> To: James M. Polk >> Cc: earlywarning@ietf.org >> Subject: Re: [earlywarning] global CAP community >> >> >> On May 1, 2009, at 5:19 PM, James M. Polk wrote: >> >> >> What are you planning to preempt? >> > >> > I was wondering the same thing, as priority seems natural (wrt >> > server resources, and indication of the type of message), but this >> > is never going to be a stream, so I don't think we'll likely have 1 >> > message preempt another (but we may delay one message relative to >> > another). >> >> I would agree on the general case, but some constrained environments >> would require preemption, with possible subsequent transmission of >> the >> preempted session. as an example, any alerting system that includes >> meteor scatter communication links definitely needs preemption, and >> one could probably extend this to a number of LMR systems as well. >> >> the key thing to keep in mind is that some alerting systems may be >> disjoint in the variation of communication mechanisms being deployed, >> and in turn, that radioactive word of preemption may not be >> ubiquitously applied. >> >> -ken >> >> _______________________________________________ >> earlywarning mailing list >> earlywarning@ietf.org >> https://www.ietf.org/mailman/listinfo/earlywarning > From spencer@wonderhamster.org Mon May 4 12:50:21 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3B43A6BCE for ; Mon, 4 May 2009 12:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_20=-0.74, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkAA-BmriW3D for ; Mon, 4 May 2009 12:50:19 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A0DA03A6B9A for ; Mon, 4 May 2009 12:50:19 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1M14C41GMs-000d0j; Mon, 04 May 2009 15:51:21 -0400 Message-ID: From: "Spencer Dawkins" To: "Brian Rosen" , "'Henning Schulzrinne'" , "'ken carlberg'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><0d3101c9ccb5$d98e7a70$8cab6f50$@net><31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu><0d5e01c9ccc0$e4966b20$adc34160$@net><97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu><0d6501c9ccc9$aa6469d0$ff2d3d70$@net><0da801c9ccd5$a9506b50$fbf141f0$@net> <0dc501c9cce0$896fb5b0$9c4f2110$@net> Date: Mon, 4 May 2009 14:50:55 -0500 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 Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+Wb7FxpSgoef78ND7k7oUIzl5MVXxWL878lfM xGjC3IFxnxvJiFvv9D8DzG2eH9iRf7KdeBGS237tOS5TsETxeP PqnacFBvUQ4GPUL3OE/8R4J8boRoffe9d0O+P3y+3E= Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:50:21 -0000 If the following isn't helpful, please ignore, but ... > While I think having every notifier's public key is a nice solution to an > authentication problem, it might be hard to arrange. Among other things, > you have to be able to get off a plane and get alerts from local > authorities. Right now, I don't want to discuss solutions, but charter > language, and I'd rather have narrow scope. > > Brian I am sympathetic to the notion of solving a limited problem set, but I'm having a difficult time trying to understand the security model here - when you get off a plane, and you don't have the local notifier's public key, and you get an alert, how do you know you can believe it? I may be misunderstanding, but part of this discussion sounds like we might rely on the fact that all notifiers are governments as a way of ensuring that you can trust the alerts you get, and I'm not sure what your mobile device is supposed to do when you turn it on - when you get an alert, how do you know it comes from a government? You guys may have all this well in hand, and Spencer just needs to catch up, but I'm concerned that we're talking about deferring security considerations in order to have a smaller scope for the work, and that might not be the right tradeoff to make... Thanks, Spencer From spencer@wonderhamster.org Mon May 4 12:52:28 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723F63A6B9A for ; Mon, 4 May 2009 12:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU5kTSAl-iLQ for ; Mon, 4 May 2009 12:52:27 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4A88D3A6AE2 for ; Mon, 4 May 2009 12:52:27 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M14EW0HvZ-000gAq; Mon, 04 May 2009 15:53:53 -0400 Message-ID: From: "Spencer Dawkins" To: "Brian Rosen" , "'ken carlberg'" , "'James M. Polk'" References: <49FB4855.4070305@bbn.com><0d3201c9ccb6$28857980$79906c80$@net><7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> <0df401c9ccf0$4dea2e20$e9be8a60$@net> Date: Mon, 4 May 2009 14:53:27 -0500 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 Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/PI3u971aFtnUe23270q/NpTs/SXJ0FunHXZh ed+Uv80eGFnZK8zVeRmaq8FhaI/M2BATqC89rlhHax9On+4gCE zhp4SoJbwlgJc7/ra80gaiDTAJhCr2xZC9pkJUrS+k= Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:52:28 -0000 This suggestion seems very reasonable to me. I'm also assuming that you can send out a multi-minute crawl line without taking multiple minutes to do that, but that doesn't matter if the alert doesn't carry much data itself... Thanks, Spencer >I think we're sending an alert, not a media stream. The alert can have a > URI in it that may point to a media stream, but it's not in the alert > itself. > > I'm hoping the size of the alert is small enough that preemption is not > worthwhile. We'll see. > > Brian > > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] > Sent: Monday, May 04, 2009 3:25 PM > To: James M. Polk > Cc: Brian Rosen; earlywarning@ietf.org > Subject: Re: [earlywarning] global CAP community > > James, > > My working assumption was that this effort was not constrained to real- > time streaming, but I'll support Brian's theme of adding a more narrow > scope if folks choose to just deal with only that type. As for > preemption, ages ago I worked on a system, for one arm of the > government, that *required* preemption as an option because parts of > the system could include bandwidth constrained environments. And the > problem was accentuated by notifications that could extend for > minutes at a time, which was considered an unacceptable period of time > to wait. So that raises another question, which part of the > government (or which government with its individual rules/regulations) > are we talking about? > > As for modern times, picture crawlers in use today that send out long > messages (eg, the list of school and event snow related closings in > large cities) that run for several minutes. I'd imagine that it would > be desirable to preempt that "session" by another authenticated > source that had a more important message to distribute than in waiting > for the first message to drain out. > > I'm also quite sympathetic to Brian's desire to limit the scope. On > the other hand, I'm concerned that we'll be continually bogged down > with comments/positions relating to specific laws and regulations from > governments if that remains the sole target of the source of alerts. > In a sense, we have already experienced that in the past few days. > > -ken > > > On May 4, 2009, at 2:49 PM, James M. Polk wrote: > >> Brian (all) >> >> I'm really confused >> >> wrt the messages and preemption -- what are we talking about here? >> >> Is this real-time streaming or not? >> >> If not, the lower priority messages get delayed until the higher >> priority messages clear the queue, right? >> >> Imagine a network where there are only early warning messages >> (putting aside the discussion about "early warning" perhaps not >> being the best phrase at the moment - that's a separate discussion), >> if each messages is marked with a DSCP, and the appropriate DSCP for >> the type of message (i.e., presidential gets the highest, whatever's >> next - gets the next highest DSCP, and so on) -- how *can't* this >> work? >> >> Each message is exactly one messages long -- unless we're talking >> about something like MSRP -- which no one has brought up yet -- and >> I'd like to hear the justification for IM in this case, and not a >> subscription based approach. >> >> Given that each message is only 1 (ONE) message long, and knowing >> the physics of only being able to transmit one message at a time >> from any one interface, how can't a scheduler and a queue solve this >> (as long as what gets put into the queue is put into the right queue >> to begin with)? >> >> In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the >> one message being transmitted is delayed until it comes up in the >> queue. There is never a reason for a deletion of a message (unless >> there is a timer associated within a message - in which case, this >> timer getting to ZERO isn't a preemption event, it's a starvation >> event). >> >> James >> >> At 07:45 AM 5/4/2009, Brian Rosen wrote: >>> Right now, I'd prefer that we assume that messages are short enough >>> that the >>> complexity of preemption is worse that the delay of transmission. I >>> wouldn't mind priority if there was a queue of alerts to be sent, >>> but the >>> notion that we preempt is, I think, not worth it. >>> >>> Brian >>> >>> -----Original Message----- >>> From: earlywarning-bounces@ietf.org >>> [mailto:earlywarning-bounces@ietf.org > >>> ] >>> On Behalf Of ken carlberg >>> Sent: Sunday, May 03, 2009 9:48 AM >>> To: James M. Polk >>> Cc: earlywarning@ietf.org >>> Subject: Re: [earlywarning] global CAP community >>> >>> >>> On May 1, 2009, at 5:19 PM, James M. Polk wrote: >>> >>> >> What are you planning to preempt? >>> > >>> > I was wondering the same thing, as priority seems natural (wrt >>> > server resources, and indication of the type of message), but this >>> > is never going to be a stream, so I don't think we'll likely have 1 >>> > message preempt another (but we may delay one message relative to >>> > another). >>> >>> I would agree on the general case, but some constrained environments >>> would require preemption, with possible subsequent transmission of >>> the >>> preempted session. as an example, any alerting system that includes >>> meteor scatter communication links definitely needs preemption, and >>> one could probably extend this to a number of LMR systems as well. >>> >>> the key thing to keep in mind is that some alerting systems may be >>> disjoint in the variation of communication mechanisms being deployed, >>> and in turn, that radioactive word of preemption may not be >>> ubiquitously applied. >>> >>> -ken >>> >>> _______________________________________________ >>> earlywarning mailing list >>> earlywarning@ietf.org >>> https://www.ietf.org/mailman/listinfo/earlywarning >> > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > From jmpolk@cisco.com Mon May 4 12:58:20 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D933A6C14 for ; Mon, 4 May 2009 12:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnpeWKaLcvsW for ; Mon, 4 May 2009 12:58:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 083C43A6C0F for ; Mon, 4 May 2009 12:58:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,293,1238976000"; d="scan'208";a="180627455" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 19:59:45 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n44JxjU8014433; Mon, 4 May 2009 12:59:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n44Jxjjt021494; Mon, 4 May 2009 19:59:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 12:59:45 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.17.58]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 12:59:44 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 May 2009 14:25:03 -0500 To: "Thomson, Martin" , , "Art Botterell" From: "James M. Polk" In-Reply-To: References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <49FDCECA.8050909@netmagic.com> <6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> <49FDD355.1050807@netmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 May 2009 19:59:44.0548 (UTC) FILETIME=[DE98D640:01C9CCF2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2565; t=1241467185; x=1242331185; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20Deprecate=20=22Authori ty=22=20-=20was=20=3A=20global=0A=20=20CAPcommunity |Sender:=20; bh=8rMSj/PPni9cZOE6yj7/qcDlloi4BrnHeJ76Zp9i030=; b=2QIihpWEy8g2U5eW+yxungGiIz2whDqb1sDK7udgI9HhcDDSFNhcxuidDj YLxRqqsUZGPn9VldX/gbSjUy0fTvMvFP9TTRzO4pTawsypNZTcaKIEPQdV1u fH9VmgqkHe; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:58:20 -0000 At 08:24 PM 5/3/2009, Thomson, Martin wrote: >I worry that this discussion has lost focus. Are we talking about >terms for use in relation to a protocol, or terms in relation to >problem statement and naming (marketing)? They can be separated. > >The terms that Hannes proposes (Author and Recipient) would be quite >suitable for use in describing a protocol and architecture. Martin (and Hannes) - my concern about these two terms is they normally do not appear together. Say, down the road, when we have "author" realized, do we classify an "authorized author". Many will find that not rolling off the tongue well. "Recipient" is fine with me, but it is more often partnered with "sender" or "originator". Meaning, down the road, we can have "authorized senders" or "authorized originators". these word pairs appear to me to be more clear. At the end of the day, having a terminology section to the beginning requirements doc (or just a terminology doc) should suffice wrt any confusion, I should think. James >Is this really the venue for deciding who applies this protocol >solution? Not that I'm suggesting we design in a vacuum, but we >each have a fair idea of what the goals are; and I truly don't think >that there are major differences of opinion. The subjective >definition of "authority" need not be a barrier to progress. > >I'm happy with marketing with vague terms like >"authority-to-citizen" or "early warning" and having separate terms >in protocol land. That's been successful in the past; the >abstraction allows for a little flexibility in interpretation. That >flexibility is sometimes useful. > >I tend to agree with Art that we can spend a lot of time on the >non-technical stuff. Maybe abstraction offers us a way to make >process on the technical side while we "slosh around" on the fuzzy issues. > >--Martin > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning From br@brianrosen.net Mon May 4 12:58:55 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8F93A6C0F for ; Mon, 4 May 2009 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1TuTNfxJm-V for ; Mon, 4 May 2009 12:58:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id C30743A63C9 for ; Mon, 4 May 2009 12:58:52 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M14Kd-0003bh-Od; Mon, 04 May 2009 15:00:08 -0500 From: "Brian Rosen" To: "'Spencer Dawkins'" , "'Henning Schulzrinne'" , "'ken carlberg'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><0d3101c9ccb5$d98e7a70$8cab6f50$@net><31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu><0d5e01c9ccc0$e4966b20$adc34160$@net><97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu><0d6501c9ccc9$aa6469d0$ff2d3d70$@net><0da801c9ccd5$a9506b50$fbf141f0$@net> <0dc501c9cce0$896fb5b0$9c4f2110$@net> In-Reply-To: Date: Mon, 4 May 2009 16:00:15 -0400 Message-ID: <0e0101c9ccf2$f32770d0$d9765270$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM8bMO2L4uW6g2QVm6FAsKazihtAAAGDlw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 19:58:55 -0000 We haven't figured any of this out. Henning proposed something that sounded like preloaded keys. I don't think that works. I think you need some kind of discovery process. Just saying "government" doesn't really solve any of this, buy it MIGHT simplify things. Brian -----Original Message----- From: Spencer Dawkins [mailto:spencer@wonderhamster.org] Sent: Monday, May 04, 2009 3:51 PM To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg' Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity If the following isn't helpful, please ignore, but ... > While I think having every notifier's public key is a nice solution to an > authentication problem, it might be hard to arrange. Among other things, > you have to be able to get off a plane and get alerts from local > authorities. Right now, I don't want to discuss solutions, but charter > language, and I'd rather have narrow scope. > > Brian I am sympathetic to the notion of solving a limited problem set, but I'm having a difficult time trying to understand the security model here - when you get off a plane, and you don't have the local notifier's public key, and you get an alert, how do you know you can believe it? I may be misunderstanding, but part of this discussion sounds like we might rely on the fact that all notifiers are governments as a way of ensuring that you can trust the alerts you get, and I'm not sure what your mobile device is supposed to do when you turn it on - when you get an alert, how do you know it comes from a government? You guys may have all this well in hand, and Spencer just needs to catch up, but I'm concerned that we're talking about deferring security considerations in order to have a smaller scope for the work, and that might not be the right tradeoff to make... Thanks, Spencer From jmpolk@cisco.com Mon May 4 13:04:20 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9279028C228 for ; Mon, 4 May 2009 13:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3B-JFoIXwIS for ; Mon, 4 May 2009 13:04:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7903528C223 for ; Mon, 4 May 2009 13:04:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,293,1238976000"; d="scan'208";a="180631758" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 20:05:45 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n44K5j6a028100; Mon, 4 May 2009 13:05:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n44K5juv029248; Mon, 4 May 2009 20:05:45 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 13:05:45 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.17.58]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 13:05:44 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 May 2009 15:06:00 -0500 To: "Brian Rosen" , "'ken carlberg'" From: "James M. Polk" In-Reply-To: <0df401c9ccf0$4dea2e20$e9be8a60$@net> References: <49FB4855.4070305@bbn.com> <0d3201c9ccb6$28857980$79906c80$@net> <7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> <0df401c9ccf0$4dea2e20$e9be8a60$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 May 2009 20:05:44.0970 (UTC) FILETIME=[B56CDEA0:01C9CCF3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5907; t=1241467545; x=1242331545; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=Jqz6fBDsvOjCJW1KBa9grLqnzED26MCT11iN/rbjrKk=; b=gq0b3OFLFJ111FbHAKQ/NEjwjrkEMWWxStX1LcjExbh62XQDnBt5Ba9E4n dPExPmrBmhir6JNri0OZkbrvs8COgVWzAmnSlfGeQbzQd8mdt0iFCFAisXmJ NYmp/345N0; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:04:20 -0000 At 02:41 PM 5/4/2009, Brian Rosen wrote: >I think we're sending an alert, not a media stream. The alert can have a >URI in it that may point to a media stream, but it's not in the alert >itself. > >I'm hoping the size of the alert is small enough that preemption is not >worthwhile. We'll see. then we are in agreement here, as I too believe the CAP message will have a URI to any scrolling message on the UI (i.e. TV - to Ken's point) >Brian > >-----Original Message----- >From: ken carlberg [mailto:carlberg@g11.org.uk] >Sent: Monday, May 04, 2009 3:25 PM >To: James M. Polk >Cc: Brian Rosen; earlywarning@ietf.org >Subject: Re: [earlywarning] global CAP community > >James, > >My working assumption was that this effort was not constrained to real- >time streaming, but I'll support Brian's theme of adding a more narrow >scope if folks choose to just deal with only that type. As for >preemption, ages ago I worked on a system, for one arm of the >government, that *required* preemption as an option because parts of >the system could include bandwidth constrained environments. And the >problem was accentuated by notifications that could extend for >minutes at a time, which was considered an unacceptable period of time >to wait. So that raises another question, which part of the >government (or which government with its individual rules/regulations) >are we talking about? > >As for modern times, picture crawlers in use today that send out long >messages (eg, the list of school and event snow related closings in >large cities) that run for several minutes. I'd imagine that it would >be desirable to preempt that "session" by another authenticated >source that had a more important message to distribute than in waiting >for the first message to drain out. > >I'm also quite sympathetic to Brian's desire to limit the scope. On >the other hand, I'm concerned that we'll be continually bogged down >with comments/positions relating to specific laws and regulations from >governments if that remains the sole target of the source of alerts. >In a sense, we have already experienced that in the past few days. > >-ken > > >On May 4, 2009, at 2:49 PM, James M. Polk wrote: > > > Brian (all) > > > > I'm really confused > > > > wrt the messages and preemption -- what are we talking about here? > > > > Is this real-time streaming or not? > > > > If not, the lower priority messages get delayed until the higher > > priority messages clear the queue, right? > > > > Imagine a network where there are only early warning messages > > (putting aside the discussion about "early warning" perhaps not > > being the best phrase at the moment - that's a separate discussion), > > if each messages is marked with a DSCP, and the appropriate DSCP for > > the type of message (i.e., presidential gets the highest, whatever's > > next - gets the next highest DSCP, and so on) -- how *can't* this > > work? > > > > Each message is exactly one messages long -- unless we're talking > > about something like MSRP -- which no one has brought up yet -- and > > I'd like to hear the justification for IM in this case, and not a > > subscription based approach. > > > > Given that each message is only 1 (ONE) message long, and knowing > > the physics of only being able to transmit one message at a time > > from any one interface, how can't a scheduler and a queue solve this > > (as long as what gets put into the queue is put into the right queue > > to begin with)? > > > > In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the > > one message being transmitted is delayed until it comes up in the > > queue. There is never a reason for a deletion of a message (unless > > there is a timer associated within a message - in which case, this > > timer getting to ZERO isn't a preemption event, it's a starvation > > event). > > > > James > > > > At 07:45 AM 5/4/2009, Brian Rosen wrote: > >> Right now, I'd prefer that we assume that messages are short enough > >> that the > >> complexity of preemption is worse that the delay of transmission. I > >> wouldn't mind priority if there was a queue of alerts to be sent, > >> but the > >> notion that we preempt is, I think, not worth it. > >> > >> Brian > >> > >> -----Original Message----- > >> From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org > >> ] > >> On Behalf Of ken carlberg > >> Sent: Sunday, May 03, 2009 9:48 AM > >> To: James M. Polk > >> Cc: earlywarning@ietf.org > >> Subject: Re: [earlywarning] global CAP community > >> > >> > >> On May 1, 2009, at 5:19 PM, James M. Polk wrote: > >> > >> >> What are you planning to preempt? > >> > > >> > I was wondering the same thing, as priority seems natural (wrt > >> > server resources, and indication of the type of message), but this > >> > is never going to be a stream, so I don't think we'll likely have 1 > >> > message preempt another (but we may delay one message relative to > >> > another). > >> > >> I would agree on the general case, but some constrained environments > >> would require preemption, with possible subsequent transmission of > >> the > >> preempted session. as an example, any alerting system that includes > >> meteor scatter communication links definitely needs preemption, and > >> one could probably extend this to a number of LMR systems as well. > >> > >> the key thing to keep in mind is that some alerting systems may be > >> disjoint in the variation of communication mechanisms being deployed, > >> and in turn, that radioactive word of preemption may not be > >> ubiquitously applied. > >> > >> -ken > >> > >> _______________________________________________ > >> earlywarning mailing list > >> earlywarning@ietf.org > >> https://www.ietf.org/mailman/listinfo/earlywarning > > From jmpolk@cisco.com Mon May 4 13:07:16 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D11B3A6911 for ; Mon, 4 May 2009 13:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YC0scR2PVpxk for ; Mon, 4 May 2009 13:07:15 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F03643A6BF4 for ; Mon, 4 May 2009 13:07:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,293,1238976000"; d="scan'208";a="180633558" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 May 2009 20:08:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n44K8ffd001475; Mon, 4 May 2009 13:08:41 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n44K8fNr015075; Mon, 4 May 2009 20:08:41 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 13:08:41 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.17.58]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 May 2009 13:08:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 May 2009 15:08:51 -0500 To: "Spencer Dawkins" , "Brian Rosen" , "'ken carlberg'" From: "James M. Polk" In-Reply-To: References: <49FB4855.4070305@bbn.com> <0d3201c9ccb6$28857980$79906c80$@net> <7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> <0df401c9ccf0$4dea2e20$e9be8a60$@net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 May 2009 20:08:37.0906 (UTC) FILETIME=[1C80CF20:01C9CCF4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6552; t=1241467721; x=1242331721; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[earlywarning]=20global=20CAP=20communi ty |Sender:=20; bh=gMFTmF6OEFGcIJPB2JIpn4C5HrtelUn7or4xV+cjPq0=; b=ewM/Ge0YAvyaS4aZYfumdSI6QDNcPdcxSPRVIp8l5sqJRrEW5WKdYoEGOC URFkIfCGHIPvPZPbv8B/1UyYqAhEsqLFtJ8/6twAutQouSXivizaAE/W0yrj 2O6dgQ+ne7; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:07:16 -0000 At 02:53 PM 5/4/2009, Spencer Dawkins wrote: >This suggestion seems very reasonable to me. > >I'm also assuming that you can send out a multi-minute crawl line >without taking multiple minutes to do that, but that doesn't matter >if the alert doesn't carry much data itself... taking this out some more, I believe it is perfectly reasonable to have any scrolling message interrupted for a higher priority message, but that's not the CAP message getting preempted. I further believe that once this more important message is done, the scrolling message that was there will resume (or at least have the option of resuming). >Thanks, > >Spencer > > >>I think we're sending an alert, not a media stream. The alert can have a >>URI in it that may point to a media stream, but it's not in the alert >>itself. >> >>I'm hoping the size of the alert is small enough that preemption is not >>worthwhile. We'll see. >> >>Brian >> >>-----Original Message----- >>From: ken carlberg [mailto:carlberg@g11.org.uk] >>Sent: Monday, May 04, 2009 3:25 PM >>To: James M. Polk >>Cc: Brian Rosen; earlywarning@ietf.org >>Subject: Re: [earlywarning] global CAP community >> >>James, >> >>My working assumption was that this effort was not constrained to real- >>time streaming, but I'll support Brian's theme of adding a more narrow >>scope if folks choose to just deal with only that type. As for >>preemption, ages ago I worked on a system, for one arm of the >>government, that *required* preemption as an option because parts of >>the system could include bandwidth constrained environments. And the >>problem was accentuated by notifications that could extend for >>minutes at a time, which was considered an unacceptable period of time >>to wait. So that raises another question, which part of the >>government (or which government with its individual rules/regulations) >>are we talking about? >> >>As for modern times, picture crawlers in use today that send out long >>messages (eg, the list of school and event snow related closings in >>large cities) that run for several minutes. I'd imagine that it would >>be desirable to preempt that "session" by another authenticated >>source that had a more important message to distribute than in waiting >>for the first message to drain out. >> >>I'm also quite sympathetic to Brian's desire to limit the scope. On >>the other hand, I'm concerned that we'll be continually bogged down >>with comments/positions relating to specific laws and regulations from >>governments if that remains the sole target of the source of alerts. >>In a sense, we have already experienced that in the past few days. >> >>-ken >> >> >>On May 4, 2009, at 2:49 PM, James M. Polk wrote: >> >>>Brian (all) >>> >>>I'm really confused >>> >>>wrt the messages and preemption -- what are we talking about here? >>> >>>Is this real-time streaming or not? >>> >>>If not, the lower priority messages get delayed until the higher >>>priority messages clear the queue, right? >>> >>>Imagine a network where there are only early warning messages >>>(putting aside the discussion about "early warning" perhaps not >>>being the best phrase at the moment - that's a separate discussion), >>>if each messages is marked with a DSCP, and the appropriate DSCP for >>>the type of message (i.e., presidential gets the highest, whatever's >>>next - gets the next highest DSCP, and so on) -- how *can't* this >>>work? >>> >>>Each message is exactly one messages long -- unless we're talking >>>about something like MSRP -- which no one has brought up yet -- and >>>I'd like to hear the justification for IM in this case, and not a >>>subscription based approach. >>> >>>Given that each message is only 1 (ONE) message long, and knowing >>>the physics of only being able to transmit one message at a time >>>from any one interface, how can't a scheduler and a queue solve this >>>(as long as what gets put into the queue is put into the right queue >>>to begin with)? >>> >>>In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the >>>one message being transmitted is delayed until it comes up in the >>>queue. There is never a reason for a deletion of a message (unless >>>there is a timer associated within a message - in which case, this >>>timer getting to ZERO isn't a preemption event, it's a starvation >>>event). >>> >>>James >>> >>>At 07:45 AM 5/4/2009, Brian Rosen wrote: >>>>Right now, I'd prefer that we assume that messages are short enough >>>>that the >>>>complexity of preemption is worse that the delay of transmission. I >>>>wouldn't mind priority if there was a queue of alerts to be sent, >>>>but the >>>>notion that we preempt is, I think, not worth it. >>>> >>>>Brian >>>> >>>>-----Original Message----- >>>>From: earlywarning-bounces@ietf.org [mailto:earlywarning-bounces@ietf.org >>>> > >>>> >>> ] >>>>On Behalf Of ken carlberg >>>>Sent: Sunday, May 03, 2009 9:48 AM >>>>To: James M. Polk >>>>Cc: earlywarning@ietf.org >>>>Subject: Re: [earlywarning] global CAP community >>>> >>>> >>>>On May 1, 2009, at 5:19 PM, James M. Polk wrote: >>>> >>>> >> What are you planning to preempt? >>>> > >>>> > I was wondering the same thing, as priority seems natural (wrt >>>> > server resources, and indication of the type of message), but this >>>> > is never going to be a stream, so I don't think we'll likely have 1 >>>> > message preempt another (but we may delay one message relative to >>>> > another). >>>> >>>>I would agree on the general case, but some constrained environments >>>>would require preemption, with possible subsequent transmission of >>>>the >>>>preempted session. as an example, any alerting system that includes >>>>meteor scatter communication links definitely needs preemption, and >>>>one could probably extend this to a number of LMR systems as well. >>>> >>>>the key thing to keep in mind is that some alerting systems may be >>>>disjoint in the variation of communication mechanisms being deployed, >>>>and in turn, that radioactive word of preemption may not be >>>>ubiquitously applied. >>>> >>>>-ken >>>> >>>>_______________________________________________ >>>>earlywarning mailing list >>>>earlywarning@ietf.org >>>>https://www.ietf.org/mailman/listinfo/earlywarning >> >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > From spencer@wonderhamster.org Mon May 4 13:11:56 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CD83A6B1F for ; Mon, 4 May 2009 13:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28zKdUhmnvrL for ; Mon, 4 May 2009 13:11:56 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D5DC93A6904 for ; Mon, 4 May 2009 13:11:55 -0700 (PDT) Received: from S73602b (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1M14XM3IOv-000g44; Mon, 04 May 2009 16:13:21 -0400 Message-ID: From: "Spencer Dawkins" To: "Brian Rosen" , "'ken carlberg'" , "James M. Polk" References: <49FB4855.4070305@bbn.com> <0d3201c9ccb6$28857980$79906c80$@net> <7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk> <0df401c9ccf0$4dea2e20$e9be8a60$@net> Date: Mon, 4 May 2009 15:12:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1+VoWJ5e2nmR9Dz9WBKYRXY+9L5A6RSFmRr9YR Q2xUiFc1RxDY/2npS8QR9FZO4SHcRJfDQwyMbj9OUBBpbRODuw uD8IMJ41ITFkcLx+oU8Wv/m6Sr34//yOECWlseEb2c= Cc: earlywarning@ietf.org Subject: Re: [earlywarning] global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 20:11:56 -0000 Hi, James, Yes, and thank you for saying this explictly... I had assumed what you said but didn't include that in my note. Spencer > taking this out some more, I believe it is perfectly reasonable to have > any scrolling message interrupted for a higher priority message, but > that's not the CAP message getting preempted. I further believe that once > this more important message is done, the scrolling message that was there > will resume (or at least have the option of resuming). From br@brianrosen.net Mon May 4 14:03:37 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500773A6DA1 for ; Mon, 4 May 2009 14:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99yfKF2vhqlh for ; Mon, 4 May 2009 14:03:36 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7C1B53A69FC for ; Mon, 4 May 2009 14:03:36 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M13Kx-0004na-Ld; Mon, 04 May 2009 13:56:23 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'ken carlberg'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> <0d6501c9ccc9$aa6469d0$ff2d3d70$@net> <0da801c9ccd5$a9506b50$fbf141f0$@net> <0dc501c9cce0$896fb5b0$9c4f2110$@net> In-Reply-To: Date: Mon, 4 May 2009 14:56:26 -0400 Message-ID: <0ddb01c9ccea$08db67a0$1a9236e0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnM4haQFJ173JnbSaS9deqXKdUQZgABwTlQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: earlywarning@ietf.org Subject: Re: [earlywarning] charter text X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:03:37 -0000 I don't care how we get there. The notion of the system "tracking" my daughter doesn't bother me as long as all we're getting out of that is the same alerts. We're not really tracking, we're replicating an alert that went to her. "Send me alerts from this place" isn't really right, but it might be another useful thing to have. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Monday, May 04, 2009 1:59 PM To: Brian Rosen; 'Henning Schulzrinne'; 'ken carlberg' Cc: earlywarning@ietf.org Subject: charter text At 10:48 AM -0700 5/4/09, Brian Rosen wrote: >It would help to go back to the charter language. >Another class of recipients that are in scope of the work are explicit >opt-in subscriptions which ask for alerts that are sent to an associated >party. An example of such a subscription would be "send me alerts which are >sent too my daughter based on her location". This seems to imply that the system must track whether or not an alert was sent to your daughter (and hence her opt-in state), rather than simply saying "send me alerts for the follow area, in which I am not currently present". It is then up to you to designate the area. This is simple. The "track your daughter" system is hard, and it has serious privacy consequences. If you simply want your daughter's user agent to echo alerts to you, I think that is also possible--but it would be separate from this system entirely and its opt-in characteristics are clearly different.. regards, Ted From hgs@cs.columbia.edu Mon May 4 14:34:42 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5EF3A68C9 for ; Mon, 4 May 2009 14:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDGaBlGwNq8Y for ; Mon, 4 May 2009 14:34:41 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 730763A6B29 for ; Mon, 4 May 2009 14:34:41 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n44LZtrN018995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 May 2009 17:35:56 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Brian Rosen In-Reply-To: <0e0101c9ccf2$f32770d0$d9765270$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 17:35:55 -0400 References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><0d3101c9ccb5$d98e7a70$8cab6f50$@net><31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu><0d5e01c9ccc0$e4966b20$adc34160$@net><97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu><0d6501c9ccc9$aa6469d0$ff2d3d70$@net><0da801c9ccd5$a9506b50$fbf141f0$@net> <0dc501c9cce0$896fb5b0$9c4f2110$@net> <0e0101c9ccf2$f32770d0$d9765270$@net> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 21:34:42 -0000 On May 4, 2009, at 4:00 PM, Brian Rosen wrote: > We haven't figured any of this out. Henning proposed something that > sounded > like preloaded keys. I don't think that works. I was talking about a specific scenario, namely where the notifier knows the destination. Students in a university and employees in a company are examples - they already routinely download keying material for various other reasons, such as browsing internal web pages. You don't even need to preload keying material. This isn't that much harder than signing S/MIME email, after all, as long as I have a pre- configured entry that says "messages signed by alerts@columbia.edu are genuine". It's not that hard for the signer to get a personal public/ private key pair from an existing CA. This would not work for the "stepping off a plane" case, although a very similar mechanism might: get the legitimate alerter(s) via LoST. As long as the CA is known, i.e., is one of the ones built into the device, this is then again like S/MIME, except easier, since the number of parties that need to get public/private keypairs is probably a few thousand, not hundreds of millions. No new infrastructure is needed, either. We shouldn't make this harder than it is. Henning From Martin.Thomson@andrew.com Mon May 4 15:49:48 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9060D3A6D26 for ; Mon, 4 May 2009 15:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4hN2nkAGdES for ; Mon, 4 May 2009 15:49:47 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id AC28F3A684F for ; Mon, 4 May 2009 15:49:47 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_05_04_18_12_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 May 2009 18:12:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 May 2009 17:51:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 4 May 2009 17:51:11 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [earlywarning] Deprecate "Authority" - was : global CAPcommunity Thread-Index: AcnM8uBYRXtvPpreSzW6/yDdZpM7SAAF49FQ References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <49FDCECA.8050909@netmagic.com> <6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com> <49FDD355.1050807@netmagic.com> From: "Thomson, Martin" To: "James M. Polk" , , "Art Botterell" X-OriginalArrivalTime: 04 May 2009 22:51:13.0369 (UTC) FILETIME=[D3365490:01C9CD0A] Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2009 22:49:48 -0000 SSBkb24ndCBjYXJlIGlmIHdlIGNhbGwgdGhlbSAiY2F0aG9kZSIgYW5kICJhbm9kZSIgYXMgbG9u ZyBhcyB3ZSBkb24ndCBzcGVuZCB0aW1lIG9uIG5hbWVzIHdoZW4gd2UgY291bGQgYmUgZGVzaWdu aW5nIHNvbHV0aW9ucy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK YW1lcyBNLiBQb2xrIFttYWlsdG86am1wb2xrQGNpc2NvLmNvbV0NCj4gU2VudDogVHVlc2RheSwg NSBNYXkgMjAwOSA1OjI1IEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IHRydXRrb3dza2lAbmV0 bWFnaWMuY29tOyBBcnQgQm90dGVyZWxsDQo+IENjOiBlYXJseXdhcm5pbmdAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtlYXJseXdhcm5pbmddIERlcHJlY2F0ZSAiQXV0aG9yaXR5IiAtIHdhcyA6 IGdsb2JhbA0KPiBDQVBjb21tdW5pdHkNCj4gDQo+IEF0IDA4OjI0IFBNIDUvMy8yMDA5LCBUaG9t c29uLCBNYXJ0aW4gd3JvdGU6DQo+ID5JIHdvcnJ5IHRoYXQgdGhpcyBkaXNjdXNzaW9uIGhhcyBs b3N0IGZvY3VzLiAgQXJlIHdlIHRhbGtpbmcgYWJvdXQNCj4gPnRlcm1zIGZvciB1c2UgaW4gcmVs YXRpb24gdG8gYSBwcm90b2NvbCwgb3IgdGVybXMgaW4gcmVsYXRpb24gdG8NCj4gPnByb2JsZW0g c3RhdGVtZW50IGFuZCBuYW1pbmcgKG1hcmtldGluZyk/ICBUaGV5IGNhbiBiZSBzZXBhcmF0ZWQu DQo+ID4NCj4gPlRoZSB0ZXJtcyB0aGF0IEhhbm5lcyBwcm9wb3NlcyAoQXV0aG9yIGFuZCBSZWNp cGllbnQpIHdvdWxkIGJlIHF1aXRlDQo+ID5zdWl0YWJsZSBmb3IgdXNlIGluIGRlc2NyaWJpbmcg YSBwcm90b2NvbCBhbmQgYXJjaGl0ZWN0dXJlLg0KPiANCj4gTWFydGluIChhbmQgSGFubmVzKSAt IG15IGNvbmNlcm4gYWJvdXQgdGhlc2UgdHdvIHRlcm1zIGlzIHRoZXkNCj4gbm9ybWFsbHkgZG8g bm90IGFwcGVhciB0b2dldGhlci4NCj4gDQo+IFNheSwgZG93biB0aGUgcm9hZCwgd2hlbiB3ZSBo YXZlICJhdXRob3IiIHJlYWxpemVkLCBkbyB3ZSBjbGFzc2lmeSBhbg0KPiAiYXV0aG9yaXplZCBh dXRob3IiLiBNYW55IHdpbGwgZmluZCB0aGF0IG5vdCByb2xsaW5nIG9mZiB0aGUgdG9uZ3VlDQo+ IHdlbGwuDQo+IA0KPiAiUmVjaXBpZW50IiBpcyBmaW5lIHdpdGggbWUsIGJ1dCBpdCBpcyBtb3Jl IG9mdGVuIHBhcnRuZXJlZCB3aXRoDQo+ICJzZW5kZXIiIG9yICJvcmlnaW5hdG9yIi4NCj4gDQo+ IE1lYW5pbmcsIGRvd24gdGhlIHJvYWQsIHdlIGNhbiBoYXZlICJhdXRob3JpemVkIHNlbmRlcnMi IG9yDQo+ICJhdXRob3JpemVkIG9yaWdpbmF0b3JzIi4NCj4gDQo+IHRoZXNlIHdvcmQgcGFpcnMg YXBwZWFyIHRvIG1lIHRvIGJlIG1vcmUgY2xlYXIuDQo+IA0KPiBBdCB0aGUgZW5kIG9mIHRoZSBk YXksIGhhdmluZyBhIHRlcm1pbm9sb2d5IHNlY3Rpb24gdG8gdGhlIGJlZ2lubmluZw0KPiByZXF1 aXJlbWVudHMgZG9jIChvciBqdXN0IGEgdGVybWlub2xvZ3kgZG9jKSBzaG91bGQgc3VmZmljZSB3 cnQgYW55DQo+IGNvbmZ1c2lvbiwgSSBzaG91bGQgdGhpbmsuDQo+IA0KPiBKYW1lcw0KPiANCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZv ciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVn ZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVz ZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From Hannes.Tschofenig@gmx.net Sat May 9 02:22:45 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF83E3A6D52 for ; Sat, 9 May 2009 02:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiITies7tffK for ; Sat, 9 May 2009 02:22:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6C27D3A6CD6 for ; Sat, 9 May 2009 02:22:43 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2009 09:24:11 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp058) with SMTP; 09 May 2009 11:24:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+vsmdvFgevWuF3uFq4dRBUbXZvlllQcPGYzoDGdY 8XS/793VtFoEQ/ From: "Hannes Tschofenig" To: "'James M. Polk'" , "'Thomson, Martin'" , , "'Art Botterell'" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com><4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com><2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk><49FDCECA.8050909@netmagic.com><6B9EF3A4-6E7B-465A-84F4-C6C8B1D65D82@incident.com><49FDD355.1050807@netmagic.com> Date: Sat, 9 May 2009 12:25:48 +0300 Message-ID: <009301c9d088$247b4d80$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcnM8uHYhCoPsa/QQmGFwN1pjy6QkwDlSNDg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: earlywarning@ietf.org Subject: Re: [earlywarning] Deprecate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 09:22:46 -0000 Hi James, I took the terminology from the email architecture. I don't think we need to always add authorized in front of it as this would hopefully be the secure communication is the normal case. Ciao Hannes >-----Original Message----- >From: earlywarning-bounces@ietf.org >[mailto:earlywarning-bounces@ietf.org] On Behalf Of James M. Polk >Sent: 04 May, 2009 22:25 >To: Thomson, Martin; trutkowski@netmagic.com; Art Botterell >Cc: earlywarning@ietf.org >Subject: Re: [earlywarning] Deprecate "Authority" - was : >global CAPcommunity > >At 08:24 PM 5/3/2009, Thomson, Martin wrote: >>I worry that this discussion has lost focus. Are we talking about >>terms for use in relation to a protocol, or terms in relation to >>problem statement and naming (marketing)? They can be separated. >> >>The terms that Hannes proposes (Author and Recipient) would be quite >>suitable for use in describing a protocol and architecture. > >Martin (and Hannes) - my concern about these two terms is they >normally do not appear together. > >Say, down the road, when we have "author" realized, do we >classify an "authorized author". Many will find that not >rolling off the tongue well. > >"Recipient" is fine with me, but it is more often partnered >with "sender" or "originator". > >Meaning, down the road, we can have "authorized senders" or >"authorized originators". > >these word pairs appear to me to be more clear. > >At the end of the day, having a terminology section to the >beginning requirements doc (or just a terminology doc) should >suffice wrt any confusion, I should think. > >James > > >>Is this really the venue for deciding who applies this protocol >>solution? Not that I'm suggesting we design in a vacuum, but we each >>have a fair idea of what the goals are; and I truly don't think that >>there are major differences of opinion. The subjective definition of >>"authority" need not be a barrier to progress. >> >>I'm happy with marketing with vague terms like "authority-to-citizen" >>or "early warning" and having separate terms in protocol >land. That's >>been successful in the past; the abstraction allows for a little >>flexibility in interpretation. That flexibility is sometimes useful. >> >>I tend to agree with Art that we can spend a lot of time on the >>non-technical stuff. Maybe abstraction offers us a way to >make process >>on the technical side while we "slosh around" on the fuzzy issues. >> >>--Martin >> >> >>-------------------------------------------------------------- >--------- >>------------------------- This message is for the designated >recipient >>only and may contain privileged, proprietary, or otherwise private >>information. >>If you have received it in error, please notify the sender >immediately >>and delete the original. Any unauthorized use of this email is >>prohibited. >>-------------------------------------------------------------- >--------- >>------------------------- >>[mf2] >>_______________________________________________ >>earlywarning mailing list >>earlywarning@ietf.org >>https://www.ietf.org/mailman/listinfo/earlywarning > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > From Hannes.Tschofenig@gmx.net Sat May 9 02:26:45 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC7D28C229 for ; Sat, 9 May 2009 02:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvXc742aDrqq for ; Sat, 9 May 2009 02:26:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5CF1328C236 for ; Sat, 9 May 2009 02:26:05 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2009 09:27:33 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp024) with SMTP; 09 May 2009 11:27:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/l6QhX6O3lvR+cEjGS3FyT7p1u/E/5qhAuukxOO3 zd53K88gF2HIBu From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , References: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> Date: Sat, 9 May 2009 12:29:11 +0300 Message-ID: <009401c9d088$9cd898a0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> Thread-Index: AcnLC1hPlp66gI2dRnC1oxhGYtgWJgFeXM2w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: Re: [earlywarning] Some further scoping issues X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 09:26:45 -0000 Hi all, I did not receive a lot of feedback on the important aspect of scoping the work in this upcoming group. Please take a briefly look at it. Based on the mailing list discussion in a different thread I would also like to add: * Are we really interested in focusing on a particular security deployment model? I don't think so. For example, alerts that are sent from a particular entity, such as a government, only. Technically this does not make a lot of sense and is too far into the deployment choices of certain entities. * We also do not make specific restrictions regarding the type of alerts (e.g., alerts about a tornado vs. early school closing) as the semantic largely comes from the content of the alert -- something we will not define anyway. There may be some technical requirements that some folks might want to discuss, such as delivery mechanisms to deal with potential congestion and so on. That's fine for me. * Excluding discussions about the type of device and the available user interface also seems to make sense to me. This appears to be more issues with a specific architecture that, as stated below, would not be in our scope. Ciao Hannes PS: Another pragmatic way to scope the work is to focus on the things that have actually been proposed already rather than speculating about things. >From what I can tell there isn't a huge amount of work being proposed in terms of documents. When new proposals come along then one can make a judgement again to determine whether this is something the group is interested in. >-----Original Message----- >From: earlywarning-bounces@ietf.org >[mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes Tschofenig >Sent: 02 May, 2009 12:50 >To: earlywarning@ietf.org >Subject: [earlywarning] Some further scoping issues > >For the future work in this group I furthermore suggest that > >* we do not focus our efforts on defining an architecture used >for distributing of alert messages (like we did it in ECRIT >with the PhoneBCP/Framework document). Instead, we develop >building blocks (like conveying CAP in SIP). I believe we will >run into lots of problems with the different usages, different >solutions that have been specified elsewhere already, etc. > >* we do not pick a single alert document format (as a >mandatory-to-implement), like CAP or GeoRSS, but instead give >those who deploy these mechanisms freedom. > >* we do not define our own alert document format (because >there are other formats available already). > >We can always decide later to document ways how people use our stuff. > >Ciao >Hannes > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > From Hannes.Tschofenig@gmx.net Sat May 9 02:37:51 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3913A6D2E for ; Sat, 9 May 2009 02:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIJOHBm6+8vt for ; Sat, 9 May 2009 02:37:49 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 16C7B3A6781 for ; Sat, 9 May 2009 02:37:48 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2009 09:39:17 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 09 May 2009 11:39:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+sj3VsqN+sF/yY9m/XrML/IW4hm+wGLPSalc4SyW ikg0x+il37BrgW From: "Hannes Tschofenig" To: "'James M. Polk'" , "'Brian Rosen'" , "'ken carlberg'" References: <49FB4855.4070305@bbn.com><0d3201c9ccb6$28857980$79906c80$@net><7D4E5F6A-F849-406E-B93A-34ED51B87881@g11.org.uk><0df401c9ccf0$4dea2e20$e9be8a60$@net> Date: Sat, 9 May 2009 12:40:54 +0300 Message-ID: <009501c9d08a$40315950$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcnM87hst1syXfeQQ5ioe+/2QMcR3wDlPKZg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: earlywarning@ietf.org Subject: [earlywarning] Additional Information in an Alert -- was RE: global CAP community X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 09:37:51 -0000 Hi all, alerts can contain all sorts of content (see CAP and GeoRSS) that points to more information in different formats (audio, video, text, html, etc.). This is something we do not really have to worry about since this work is done already elsewhere. An example? See http://www.geowebguru.com/articles/108-technical-overview-georss Ciao Hannes >-----Original Message----- >From: earlywarning-bounces@ietf.org >[mailto:earlywarning-bounces@ietf.org] On Behalf Of James M. Polk >Sent: 04 May, 2009 23:06 >To: Brian Rosen; 'ken carlberg' >Cc: earlywarning@ietf.org >Subject: Re: [earlywarning] global CAP community > >At 02:41 PM 5/4/2009, Brian Rosen wrote: >>I think we're sending an alert, not a media stream. The >alert can have >>a URI in it that may point to a media stream, but it's not in >the alert >>itself. >> >>I'm hoping the size of the alert is small enough that >preemption is not >>worthwhile. We'll see. > >then we are in agreement here, as I too believe the CAP >message will have a URI to any scrolling message on the UI >(i.e. TV - to Ken's point) > > >>Brian >> >>-----Original Message----- >>From: ken carlberg [mailto:carlberg@g11.org.uk] >>Sent: Monday, May 04, 2009 3:25 PM >>To: James M. Polk >>Cc: Brian Rosen; earlywarning@ietf.org >>Subject: Re: [earlywarning] global CAP community >> >>James, >> >>My working assumption was that this effort was not >constrained to real- >>time streaming, but I'll support Brian's theme of adding a more narrow >>scope if folks choose to just deal with only that type. As for >>preemption, ages ago I worked on a system, for one arm of the >>government, that *required* preemption as an option because parts of >>the system could include bandwidth constrained environments. And the >>problem was accentuated by notifications that could extend for >>minutes at a time, which was considered an unacceptable period of time >>to wait. So that raises another question, which part of the >>government (or which government with its individual rules/regulations) >>are we talking about? >> >>As for modern times, picture crawlers in use today that send out long >>messages (eg, the list of school and event snow related closings in >>large cities) that run for several minutes. I'd imagine that it would >>be desirable to preempt that "session" by another authenticated >>source that had a more important message to distribute than in waiting >>for the first message to drain out. >> >>I'm also quite sympathetic to Brian's desire to limit the scope. On >>the other hand, I'm concerned that we'll be continually bogged down >>with comments/positions relating to specific laws and regulations from >>governments if that remains the sole target of the source of alerts. >>In a sense, we have already experienced that in the past few days. >> >>-ken >> >> >>On May 4, 2009, at 2:49 PM, James M. Polk wrote: >> >> > Brian (all) >> > >> > I'm really confused >> > >> > wrt the messages and preemption -- what are we talking about here? >> > >> > Is this real-time streaming or not? >> > >> > If not, the lower priority messages get delayed until the higher >> > priority messages clear the queue, right? >> > >> > Imagine a network where there are only early warning messages >> > (putting aside the discussion about "early warning" perhaps not >> > being the best phrase at the moment - that's a separate >discussion), >> > if each messages is marked with a DSCP, and the >appropriate DSCP for >> > the type of message (i.e., presidential gets the highest, >whatever's >> > next - gets the next highest DSCP, and so on) -- how *can't* this >> > work? >> > >> > Each message is exactly one messages long -- unless we're talking >> > about something like MSRP -- which no one has brought up yet -- and >> > I'd like to hear the justification for IM in this case, and not a >> > subscription based approach. >> > >> > Given that each message is only 1 (ONE) message long, and knowing >> > the physics of only being able to transmit one message at a time >> > from any one interface, how can't a scheduler and a queue >solve this >> > (as long as what gets put into the queue is put into the >right queue >> > to begin with)? >> > >> > In IM (i.e., MESSAGEs), as well as NOTIFYs - everything behind the >> > one message being transmitted is delayed until it comes up in the >> > queue. There is never a reason for a deletion of a message (unless >> > there is a timer associated within a message - in which case, this >> > timer getting to ZERO isn't a preemption event, it's a starvation >> > event). >> > >> > James >> > >> > At 07:45 AM 5/4/2009, Brian Rosen wrote: >> >> Right now, I'd prefer that we assume that messages are >short enough >> >> that the >> >> complexity of preemption is worse that the delay of >transmission. I >> >> wouldn't mind priority if there was a queue of alerts to be sent, >> >> but the >> >> notion that we preempt is, I think, not worth it. >> >> >> >> Brian >> >> >> >> -----Original Message----- >> >> From: earlywarning-bounces@ietf.org >[mailto:earlywarning-bounces@ietf.org >> >> ] >> >> On Behalf Of ken carlberg >> >> Sent: Sunday, May 03, 2009 9:48 AM >> >> To: James M. Polk >> >> Cc: earlywarning@ietf.org >> >> Subject: Re: [earlywarning] global CAP community >> >> >> >> >> >> On May 1, 2009, at 5:19 PM, James M. Polk wrote: >> >> >> >> >> What are you planning to preempt? >> >> > >> >> > I was wondering the same thing, as priority seems natural (wrt >> >> > server resources, and indication of the type of >message), but this >> >> > is never going to be a stream, so I don't think we'll >likely have 1 >> >> > message preempt another (but we may delay one message >relative to >> >> > another). >> >> >> >> I would agree on the general case, but some constrained >environments >> >> would require preemption, with possible subsequent transmission of >> >> the >> >> preempted session. as an example, any alerting system >that includes >> >> meteor scatter communication links definitely needs >preemption, and >> >> one could probably extend this to a number of LMR systems as well. >> >> >> >> the key thing to keep in mind is that some alerting systems may be >> >> disjoint in the variation of communication mechanisms >being deployed, >> >> and in turn, that radioactive word of preemption may not be >> >> ubiquitously applied. >> >> >> >> -ken >> >> >> >> _______________________________________________ >> >> earlywarning mailing list >> >> earlywarning@ietf.org >> >> https://www.ietf.org/mailman/listinfo/earlywarning >> > > >_______________________________________________ >earlywarning mailing list >earlywarning@ietf.org >https://www.ietf.org/mailman/listinfo/earlywarning > From br@brianrosen.net Mon May 11 05:53:55 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CB83A6F53 for ; Mon, 11 May 2009 05:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7i8nGbAMs9G for ; Mon, 11 May 2009 05:53:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9881C3A6D7E for ; Mon, 11 May 2009 05:53:54 -0700 (PDT) Received: from [209.173.57.233] (helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1M3V2M-0000Qs-0W; Mon, 11 May 2009 07:55:18 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , References: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> <009401c9d088$9cd898a0$0301a8c0@nsnintra.net> In-Reply-To: <009401c9d088$9cd898a0$0301a8c0@nsnintra.net> Date: Mon, 11 May 2009 08:55:27 -0400 Message-ID: <055d01c9d237$c4265310$4c72f930$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnLC1hPlp66gI2dRnC1oxhGYtgWJgFeXM2wAGyG2bA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [earlywarning] Some further scoping issues X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 12:53:55 -0000 I don't think we can do this. The biggest problem in this whole effort is the security. This mechanism could, in theory, send alerts to billions of devices. That's a VERY tempting target. This means that security model is perhaps the single most important aspect of the task. I think if you limit the notifiers, the security is more tractable. I agree that the kind of alert doesn't really matter for our work. I think the rendering issues are big, and will occupy a significant part of our time. The range of devices is large, but the size of the message is, hopefully, small. How we design the system so that it is feasible to render on a wide variety of devices in a wide variety of locations (language issues for example), is a hard problem. In some prior efforts, this was deemed to hard, and too much liability, and the solution was to require the notifier (or an agent operated by a government agency) to cast the notification in a single simple text string of limited length, thus not requiring the devices or downstream networks to do any rendering. While I would assume we would not choose such a solution, it indicates that the problem is pretty big, and needs some imagination on our part to make sure that what we send is simply renderable on the devices. Brian > -----Original Message----- > From: earlywarning-bounces@ietf.org [mailto:earlywarning- > bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Saturday, May 09, 2009 5:29 AM > To: 'Hannes Tschofenig'; earlywarning@ietf.org > Subject: Re: [earlywarning] Some further scoping issues > > Hi all, > > I did not receive a lot of feedback on the important aspect of scoping > the > work in this upcoming group. > > Please take a briefly look at it. > > Based on the mailing list discussion in a different thread I would also > like > to add: > > * Are we really interested in focusing on a particular security > deployment > model? I don't think so. > For example, alerts that are sent from a particular entity, such as a > government, only. Technically this does not make a lot of sense and is > too > far into the deployment choices of certain entities. > > * We also do not make specific restrictions regarding the type of > alerts > (e.g., alerts about a tornado vs. early school closing) as the semantic > largely comes from the content of the alert -- something we will not > define > anyway. There may be some technical requirements that some folks might > want > to discuss, such as delivery mechanisms to deal with potential > congestion > and so on. That's fine for me. > > * Excluding discussions about the type of device and the available user > interface also seems to make sense to me. This appears to be more > issues > with a specific architecture that, as stated below, would not be in our > scope. > > Ciao > Hannes > > PS: Another pragmatic way to scope the work is to focus on the things > that > have actually been proposed already rather than speculating about > things. > From what I can tell there isn't a huge amount of work being proposed > in > terms of documents. When new proposals come along then one can make a > judgement again to determine whether this is something the group is > interested in. > > >-----Original Message----- > >From: earlywarning-bounces@ietf.org > >[mailto:earlywarning-bounces@ietf.org] On Behalf Of Hannes Tschofenig > >Sent: 02 May, 2009 12:50 > >To: earlywarning@ietf.org > >Subject: [earlywarning] Some further scoping issues > > > >For the future work in this group I furthermore suggest that > > > >* we do not focus our efforts on defining an architecture used > >for distributing of alert messages (like we did it in ECRIT > >with the PhoneBCP/Framework document). Instead, we develop > >building blocks (like conveying CAP in SIP). I believe we will > >run into lots of problems with the different usages, different > >solutions that have been specified elsewhere already, etc. > > > >* we do not pick a single alert document format (as a > >mandatory-to-implement), like CAP or GeoRSS, but instead give > >those who deploy these mechanisms freedom. > > > >* we do not define our own alert document format (because > >there are other formats available already). > > > >We can always decide later to document ways how people use our stuff. > > > >Ciao > >Hannes > > > >_______________________________________________ > >earlywarning mailing list > >earlywarning@ietf.org > >https://www.ietf.org/mailman/listinfo/earlywarning > > > > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning From acb@incident.com Mon May 11 07:39:11 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B913A6F73 for ; Mon, 11 May 2009 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x70FTQPndMsv for ; Mon, 11 May 2009 07:39:11 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id AF6A03A6C12 for ; Mon, 11 May 2009 07:39:10 -0700 (PDT) Received: (qmail 54884 invoked from network); 11 May 2009 14:39:59 -0000 Received: from unknown (HELO postfix.incident.com) (acb@99.182.125.96 with login) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 11 May 2009 14:39:59 -0000 X-YMail-OSG: 8RkUDrIVM1k.3BmFZEkWYh3uxCtGuQgubeMhp_LiZfFOz0ucY87.jY3tSl1mRIShXSKwbqJqeIxcKRhc6H8K_mHDWIygXneOR4ceSfIxy03R_ld803iFXAbPOKI3NCeLntvzlgAOIfD9uCKwI0l.AbTmW2WjaeBPhBYRLA73EpOnVS7WxL4kEoLDbOyUJQYNhCccqB6OQjrE1GbZgA3AtXGXRNvWlav8N3vc_IMdQkpp0sZtuxhfJoCnOPtPGCUpSJGKotTjNMVMeyg- X-Yahoo-Newman-Property: ymail-3 Received: from [127.0.0.1] (localhost [127.0.0.1]) by postfix.incident.com (Postfix) with ESMTP id 310C11ED4CE6 for ; Mon, 11 May 2009 07:39:57 -0700 (PDT) Message-Id: <60BD3A70-B819-4E9D-8A92-D8DCDFC8CDAC@incident.com> From: Art Botterell To: earlywarning@ietf.org In-Reply-To: <055d01c9d237$c4265310$4c72f930$@net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 11 May 2009 07:39:56 -0700 References: <017d01c9cb0b$590469b0$0301a8c0@nsnintra.net> <009401c9d088$9cd898a0$0301a8c0@nsnintra.net> <055d01c9d237$c4265310$4c72f930$@net> X-Mailer: Apple Mail (2.930.3) Subject: Re: [earlywarning] Some further scoping issues X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2009 14:39:11 -0000 On May 11, 2009, at 5/11/09 5:55 AM, Brian Rosen wrote: > I think if you limit the notifiers, the security is more tractable. Seems like the challenge here may be more attribution than authorization. If folks can know with confidence who sent a message, they can decide for themselves who they trust. If they can't, the door is open to spam. Reliable identity is a prerequisite to access control anyway, but it might actually make "prior restraint" mechanisms unnecessary... thus allowing the technology to sidestep the complex political question of "authority." - Art From drage@alcatel-lucent.com Thu May 14 10:05:33 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EC33A6F29 for ; Thu, 14 May 2009 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[AWL=-1.692, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9QU8D7Jwc68 for ; Thu, 14 May 2009 10:05:31 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id C32653A69D2 for ; Thu, 14 May 2009 10:05:29 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n4EH6iNM031773 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 14 May 2009 19:06:44 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 14 May 2009 19:06:44 +0200 From: "DRAGE, Keith (Keith)" To: Henning Schulzrinne , Brian Rosen Date: Thu, 14 May 2009 19:06:41 +0200 Thread-Topic: [earlywarning] Depricate "Authority" - was : global CAPcommunity Thread-Index: AcnMxsBJopCAszIYQdCpiQwFJGhRcgH7yeZQ Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6759ED6A6@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46F3@gaalpa1msgusr7e.ugd.att.com> <4C3C5B6D-81D5-4B63-A1F1-6429A9980AED@incident.com> <2B21B310-A861-4D01-87DC-3229EF95965A@g11.org.uk> <0d3101c9ccb5$d98e7a70$8cab6f50$@net> <31F5CFB3-6434-4414-926C-1659A0AE4C93@cs.columbia.edu> <0d5e01c9ccc0$e4966b20$adc34160$@net> <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> In-Reply-To: <97F83B40-E741-4A83-A2CE-CF64181757DB@cs.columbia.edu> 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.57 on 155.132.188.84 Cc: "earlywarning@ietf.org" Subject: Re: [earlywarning] Depricate "Authority" - was : global CAPcommunity X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:05:33 -0000 Maybe we could address this a different way round. In draft-norreys-ecrit-authority2individuals-requirements-02.txt we have va= rious figures showing the entities involved. Between which entities do we s= ee various security activities (authorisation, integrity protection, encryp= tion) occurring.=20 I rather get the impression that Brian is arguing for the closed federation= figure and therefore no authorisation between "Warning Notification Provid= er" and "Warning Notification Aggregator". regards Keith > -----Original Message----- > From: earlywarning-bounces@ietf.org=20 > [mailto:earlywarning-bounces@ietf.org] On Behalf Of Henning=20 > Schulzrinne > Sent: Monday, May 04, 2009 3:43 PM > To: Brian Rosen > Cc: earlywarning@ietf.org > Subject: Re: [earlywarning] Depricate "Authority" - was :=20 > global CAPcommunity >=20 > Why is authorization easier for government? A school,=20 > university or company generally knows all of its students and=20 > employees, and can thus easily, relatively speaking, provide=20 > their public key to them ahead of time, so that an alert can=20 > be trivially verified as to its authenticity. For that, it=20 > doesn't matter whether the organization is run by a=20 > government (say, the Port Authority of NY&NJ) or a private=20 > entity (Columbia University). (I guess sending alerts to GM=20 > and Citibank would still be ok...). I'm ignoring the problem=20 > of university/ company visitors, as most existing alert=20 > systems don't deal with them, and reasonably rely on the=20 > "regulars" to tell them what's going on. >=20 > The case of alerting is much harder for entities who need to=20 > reach everyone who happens to be in their territory, such as=20 > a county. They have to distribute some cryptographic material=20 > to everybody, including visitors, without knowing who they are. >=20 > Thus, the operative difference seem much more of a "closed"=20 > vs. "open" =20 > membership, rather than whether the entity operating the=20 > alert has a seal and calls it itself county or state government. >=20 > Henning >=20 > On May 4, 2009, at 10:01 AM, Brian Rosen wrote: >=20 > > Finally, a meaty subject; terminology really doesn't get us=20 > very far. =20 > > This is important; really narrowing scope. > > > > Let's take a look at how far do we want to go: > > > > National Government with major warning - impending attack Regional=20 > > Government with life threatening event - Tornado or flash=20 > flood Local=20 > > Government with life threatening event - hazmat spill Local=20 > Government=20 > > with important, but not threatening event - major traffic=20 > tieup Local=20 > > Government with useful event - public school closing State=20 > Government=20 > > College with life threatening event - school shooting=20 > Private College=20 > > with life threatening event - school shooting Private elementary=20 > > school with useful event - school closing Enterprise with life=20 > > threatening event - hazmat spill Enterprise with useful event -=20 > > building closing due to weather > > > > It's clear to me that all of these are very useful alerts. The=20 > > question becomes, which of these should be in scope for the first=20 > > charter? > > > > It seems to me that the issue of authorization is the=20 > biggie here, and=20 > > if we started out limiting to government, even local government, it=20 > > gets a lot easier. Once you allow a non-government entity to notify=20 > > using the > > mechanism, we make the authorization decision much more=20 > difficult. =20 > > I don't > > see an in-between way to slice the above list other than=20 > government/=20 > > non government unless you say that the government can=20 > authorize other=20 > > entities and you are relying on that authorization. > > > > I think the wishes of the networks that are transporting the alerts=20 > > come into play; they would want a bright line on authorization. > > > > I suspect that once you have an authorized entity that can=20 > create an=20 > > alert, what it gets to use that authorization for is a less=20 > > interesting (to the > > IETF) issue. If you can issue alerts, you can issue any kind of=20 > > alert. > > > > Brian > > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Monday, May 04, 2009 9:20 AM > > To: Brian Rosen > > Cc: 'ken carlberg'; 'Art Botterell'; earlywarning@ietf.org > > Subject: Re: [earlywarning] Depricate "Authority" - was : global=20 > > CAPcommunity > > > > This distinction is unlikely to work in the US, at least,=20 > as there are=20 > > many quasi-governmental entities. Classical example: some of the=20 > > largest scale notification systems today are deployed by college=20 > > campuses, particularly after the Virginia Tech shooting.=20 > There is no=20 > > technical reason why such function should be available to state=20 > > colleges and universities, but not to private institutions=20 > (which, in=20 > > the US, are in no way governed by the Federal or state government). > > Same is true for large school districts, which can be either run by=20 > > the city/county or, say, the Catholic Church. > > > > Henning > > > > On May 4, 2009, at 8:42 AM, Brian Rosen wrote: > > > >> As with any IETF effort, limiting scope is useful to get=20 > progress in=20 > >> a reasonable time. With this effort, we have tried to limit the=20 > >> scope of "authority". It would be okay with me if we did=20 > limit it to=20 > >> government initially, although eventually I suspect we will expand=20 > >> it. > >> > >> I am very comfortable leaving the terminology as is: authority to=20 > >> citizen. > >> I think we can reasonably explain that authority is initially=20 > >> government (national, state/province/region/, and local). We can=20 > >> reasonably explain that citizen includes residents and visitors. > >> > >> I'd like to keep the discussion more on the scope than on the=20 > >> terminology. > >> > >> Brian > >> > >> -----Original Message----- > >> From: earlywarning-bounces@ietf.org=20 > >> [mailto:earlywarning-bounces@ietf.org > >> ] > >> On Behalf Of ken carlberg > >> Sent: Sunday, May 03, 2009 9:14 AM > >> To: Art Botterell > >> Cc: earlywarning@ietf.org > >> Subject: Re: [earlywarning] Depricate "Authority" - was : global=20 > >> CAPcommunity > >> > >> a good point. What the previous poster failed to elaborate on is=20 > >> that other SDO's like the ITU have made the association of=20 > authority=20 > >> =3D=3D government, and given us terms and classification of=20 > communication=20 > >> models comprising: > >> > >> citizen-to-citizen, citizen-to-authority,=20 > authority-to-authority, and=20 > >> authority-to-citizen > >> > >> which is why we are seeing this terminology creep up on this list. > >> one could take the approach that the IETF will go its own=20 > way, but I=20 > >> think it will be more constructive to acknowledge what's already=20 > >> gained traction and explore other terms. and in this=20 > specific case,=20 > >> something other than "authority" if we want to expand the target=20 > >> model. > >> > >> -ken > >> > >> > >> > >> On May 2, 2009, at 3:47 PM, Art Botterell wrote: > >> > >>> If so, why not say "government"? > >>> > >>> On May 2, 2009, at 5/2/09 12:38 PM, DOLLY, MARTIN C,=20 > ATTLABS wrote: > >>> > >>>> Authority is government > >>>> > >>>> ----- Original Message ----- > >>>> From: earlywarning-bounces@ietf.org=20 > > >>>> To: earlywarning@ietf.org > >>>> Sent: Sat May 02 11:51:10 2009 > >>>> Subject: Re: [earlywarning] Depricate "Authority" - was : global=20 > >>>> CAPcommunity > >>>> > >>>> On May 2, 2009, at 5/2/09 3:26 AM, Janet P Gunn wrote: > >>>> > >>>>> How many people here know PRECISELY what "exigent"=20 > means without=20 > >>>>> looking it up. > >>>>> > >>>>> You need a term that has wider comprehension. > >>>> > >>>> Unfortunately, not many folks know precisely what "early warning" > >>>> means either, although many assume they do until you=20 > press them for=20 > >>>> specifics. > >>>> > >>>> It seems like the current terms of reference are heavily loaded=20 > >>>> with emotional and cultural baggage. That's the problem=20 > with the=20 > >>>> word "authority"... it has several different senses and=20 > ultimately=20 > >>>> involves a subjective, or at least individual, interpretation of=20 > >>>> who and what constitutes authority (Government? Church? Academe?=20 > >>>> Culture?) > >>>> > >>>> "Warning" is likewise a fairly subtle notion when you=20 > really start=20 > >>>> to unpack it. In my particular public warning system we=20 > define it=20 > >>>> narrowly as "information about imminent threats to human life or=20 > >>>> health"... but other practitioners frame it differently.=20 > The word=20 > >>>> also spans the distinct domains of attention-management and=20 > >>>> information-sharing (is it a warning if folks are=20 > already aware of=20 > >>>> the subject matter?) > >>>> > >>>> So I'm wondering... might it be more productive to specify the=20 > >>>> particular observable characteristics we're concerned about=20 > >>>> (latency, reliability, verifiability, etc.) we're hoping=20 > to achieve=20 > >>>> rather than sloshing around in non-technical semantics? > >>>> > >>>> I get the sense that at least some of us are primarily concerned=20 > >>>> with the use of SIP, and although I have no personal=20 > investment in=20 > >>>> that particular approach, at least it sounds like the=20 > frame for a=20 > >>>> tractable technical problem. > >>>> > >>>> - Art > >>>> _______________________________________________ > >>>> earlywarning mailing list > >>>> earlywarning@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/earlywarning > >>> > >>> _______________________________________________ > >>> earlywarning mailing list > >>> earlywarning@ietf.org > >>> https://www.ietf.org/mailman/listinfo/earlywarning > >> > >> _______________________________________________ > >> earlywarning mailing list > >> earlywarning@ietf.org > >> https://www.ietf.org/mailman/listinfo/earlywarning > >> > >> _______________________________________________ > >> earlywarning mailing list > >> earlywarning@ietf.org > >> https://www.ietf.org/mailman/listinfo/earlywarning > >> > > > > >=20 > _______________________________________________ > earlywarning mailing list > earlywarning@ietf.org > https://www.ietf.org/mailman/listinfo/earlywarning > = From bs7652@att.com Fri May 15 11:49:51 2009 Return-Path: X-Original-To: earlywarning@core3.amsl.com Delivered-To: earlywarning@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0593A6AA0 for ; Fri, 15 May 2009 11:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.59 X-Spam-Level: X-Spam-Status: No, score=-104.59 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oED2dStUr85 for ; Fri, 15 May 2009 11:49:51 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id B3C433A68A0 for ; Fri, 15 May 2009 11:49:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1242413482!35714913!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 20326 invoked from network); 15 May 2009 18:51:23 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-3.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 May 2009 18:51:23 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n4FIpMvw032455 for ; Fri, 15 May 2009 14:51:22 -0400 Received: from 01GAF5142010624.AD.BLS.COM (01GAF5142010624.ad.bls.com [139.76.131.91]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n4FIpEs9032303 for ; Fri, 15 May 2009 14:51:14 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 15 May 2009 14:51:13 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 15 May 2009 14:51:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 May 2009 14:51:10 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0E4CD0C8@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: emergency alert implementations Thread-Index: AcnVjhviNn9EvKG9RYe5jjxxfTmk+A== From: "Stark, Barbara" To: X-OriginalArrivalTime: 15 May 2009 18:51:13.0760 (UTC) FILETIME=[1EEB9E00:01C9D58E] Subject: [earlywarning] emergency alert implementations X-BeenThere: earlywarning@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for Authority-to-Individuals \(Early Warning\) Emergency " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2009 18:49:51 -0000 Thought y'all might be interested in this news article. By the way, my local school system now uses Twitter to provide alerts. Barbara http://blogs.wsj.com/digits/2009/05/11/new-york-citys-emergency-text-ale rts-in-the-spotlight/=20