From rjsparks@nostrum.com Fri Apr 8 12:46:24 2011 Return-Path: X-Original-To: atoca@core3.amsl.com Delivered-To: atoca@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F343A6A19 for ; Fri, 8 Apr 2011 12:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, SPF_PASS=-0.001, 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 ZgAJECthHRbv for ; Fri, 8 Apr 2011 12:46:24 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B8D623A6957 for ; Fri, 8 Apr 2011 12:46:20 -0700 (PDT) Received: from [192.168.2.105] (pool-173-57-91-217.dllstx.fios.verizon.net [173.57.91.217]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p38Jm5vx081869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Apr 2011 14:48:05 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2011 14:48:05 -0500 Message-Id: <307CEC25-9E1F-4090-9965-758904FEA3F1@nostrum.com> To: atoca@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.57.91.217 is authenticated by a trusted mechanism) Subject: [atoca] ATOCA mailing list update X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:46:24 -0000 All - Based on the discussion at the meeting in Prague, the chairs requested = that the email list for this group be moved from earlywarning@ietf.org to atoca@ietf.org. That move has been completed. = You should all have been automatically subscribed to the new list, and the archives have been moved forward. = The old list will be closed in a few days.=20 Please upgrade any mail filters you are running accordingly (the List-ID = header, in particular, will have changed). Please let the chairs know if you are having any difficulties with the = new list or spot anything that didn't move correctly. Thanks, RjS From keith.drage@alcatel-lucent.com Fri Apr 8 12:51:21 2011 Return-Path: X-Original-To: atoca@core3.amsl.com Delivered-To: atoca@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F2DF3A6A10 for ; Fri, 8 Apr 2011 12:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.971 X-Spam-Level: X-Spam-Status: No, score=-105.971 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Rxq+s3b4L+pg for ; Fri, 8 Apr 2011 12:51:20 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 898583A6975 for ; Fri, 8 Apr 2011 12:51:20 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p38Jr30u019710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 8 Apr 2011 21:53:04 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 8 Apr 2011 21:53:03 +0200 From: "DRAGE, Keith (Keith)" To: Robert Sparks , "atoca@ietf.org" Date: Fri, 8 Apr 2011 21:53:02 +0200 Thread-Topic: [atoca] ATOCA mailing list update Thread-Index: Acv2JfIjOBc0UNPOTo6SnNIlMvEN5QAAHQmQ Message-ID: References: <307CEC25-9E1F-4090-9965-758904FEA3F1@nostrum.com> In-Reply-To: <307CEC25-9E1F-4090-9965-758904FEA3F1@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [atoca] ATOCA mailing list update X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 19:51:21 -0000 I assume this must have been offline discussion, as I thought I took the no= tes for the proceedings, and I did not record any such discussion. I don't specifically have a problem with this, but it does come as a surpri= se. Keith > -----Original Message----- > From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On Behalf Of > Robert Sparks > Sent: 08 April 2011 20:48 > To: atoca@ietf.org > Subject: [atoca] ATOCA mailing list update >=20 > All - >=20 > Based on the discussion at the meeting in Prague, the chairs requested > that the email list for this group be moved from > earlywarning@ietf.org to atoca@ietf.org. That move has been completed. Yo= u > should all have been automatically > subscribed to the new list, and the archives have been moved forward. The > old list will be closed in a few days. > Please upgrade any mail filters you are running accordingly (the List-ID > header, in particular, will have changed). >=20 > Please let the chairs know if you are having any difficulties with the ne= w > list or spot anything that didn't move correctly. >=20 > Thanks, >=20 > RjS >=20 >=20 > _______________________________________________ > atoca mailing list > atoca@ietf.org > https://www.ietf.org/mailman/listinfo/atoca From rjsparks@nostrum.com Fri Apr 8 13:04:22 2011 Return-Path: X-Original-To: atoca@core3.amsl.com Delivered-To: atoca@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 594AB3A6976 for ; Fri, 8 Apr 2011 13:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, SPF_PASS=-0.001, 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 Iv1gAVYUKPwH for ; Fri, 8 Apr 2011 13:04:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 338FC3A6975 for ; Fri, 8 Apr 2011 13:04:15 -0700 (PDT) Received: from [192.168.2.105] (pool-173-57-91-217.dllstx.fios.verizon.net [173.57.91.217]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p38K5T8h083468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 8 Apr 2011 15:05:59 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Fri, 8 Apr 2011 15:05:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <307CEC25-9E1F-4090-9965-758904FEA3F1@nostrum.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 173.57.91.217 is authenticated by a trusted mechanism) Cc: "atoca@ietf.org" Subject: Re: [atoca] ATOCA mailing list update X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 20:04:22 -0000 Apologies for the surprise. The discussion was at the end of the session = - it may well have been right after we started to break. On Apr 8, 2011, at 2:53 PM, DRAGE, Keith (Keith) wrote: > I assume this must have been offline discussion, as I thought I took = the notes for the proceedings, and I did not record any such discussion. >=20 > I don't specifically have a problem with this, but it does come as a = surprise. >=20 > Keith >=20 >> -----Original Message----- >> From: atoca-bounces@ietf.org [mailto:atoca-bounces@ietf.org] On = Behalf Of >> Robert Sparks >> Sent: 08 April 2011 20:48 >> To: atoca@ietf.org >> Subject: [atoca] ATOCA mailing list update >>=20 >> All - >>=20 >> Based on the discussion at the meeting in Prague, the chairs = requested >> that the email list for this group be moved from >> earlywarning@ietf.org to atoca@ietf.org. That move has been = completed. You >> should all have been automatically >> subscribed to the new list, and the archives have been moved forward. = The >> old list will be closed in a few days. >> Please upgrade any mail filters you are running accordingly (the = List-ID >> header, in particular, will have changed). >>=20 >> Please let the chairs know if you are having any difficulties with = the new >> list or spot anything that didn't move correctly. >>=20 >> Thanks, >>=20 >> RjS >>=20 >>=20 >> _______________________________________________ >> atoca mailing list >> atoca@ietf.org >> https://www.ietf.org/mailman/listinfo/atoca From Martin.Thomson@commscope.com Sun Apr 10 18:15:10 2011 Return-Path: X-Original-To: atoca@core3.amsl.com Delivered-To: atoca@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2B33A6A30 for ; Sun, 10 Apr 2011 18:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[AWL=-2.086, 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 WEIhKxDcXetI for ; Sun, 10 Apr 2011 18:15:08 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 978483A6A39 for ; Sun, 10 Apr 2011 18:15:08 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-ce-4da2561b0a89 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id E4.6C.05313.B1652AD4; Sun, 10 Apr 2011 20:15:07 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 10 Apr 2011 20:15:07 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 11 Apr 2011 09:15:04 +0800 From: "Thomson, Martin" To: "atoca@ietf.org" Date: Mon, 11 Apr 2011 09:15:02 +0800 Thread-Topic: Draft minutes from IETF-80 Thread-Index: Acv35eJPXpaZSivzTWO/dhbhfJ7B+Q== Message-ID: <8B0A9FCBB9832F43971E38010638454F04027BA0E9@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [atoca] Draft minutes from IETF-80 X-BeenThere: atoca@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Discussion list for the IETF Authority-to-Citizen Alert \(atoca\) working group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 01:15:10 -0000 I've uploaded the following draft minutes from the meeting. Let me know if= you think that there is anything missing/incorrect/etc... ATOCA minutes from IETF-80 =3DAdministrivia Covered working group status. ACTION: Chairs and AD to look into tools state of draft-ietf-atoca-cap. Se= cretariat have since updated this. =3DRequirements Discussion Part 1 - General Architecture Discussed scale of the architecture. - agreed that Internet scale is a goal, though smaller scale uses are impo= rtant ACTION: Requirements document should include discussion on the full range o= f use cases. Agreed to include discussion on both ends (e.g., school closu= res, tsunami warnings) Discussed subscription model and what sort of behavior is necessary from re= cipients. - some form of explicit action might be necessary regardless of scale requ= irements Discussed filtering. - filtering on message content - filtering based on source (and not just identity, but attribute-based) - filtering at relays - taxonomies of alert types =3DRequirements Discussion Part 2 - Security Discussed the general problems inherent in pub-sub architectures (based on = RFC 3265 and XEP 60) - access control, DoS, replays and MITM Discussed available mechanisms - noted that many are unsuitable either because they don't exist (SIP iden= tity), or don't work (P-Asserted-Identity) Described trust model - who is trusted - originator/relay - how trust anchors are created - device provisioning, some form of discov= ery mechanism - differences in models with and without prior subscription=20 =3D=3DRaw notes Thanks to Keith Drage and James Polk =3D=3D=3DKeith (Note: s/Jeff Thom[p]son/Geoff Thompson/;s/Martin Thom[p]son/Martin Thomson= ) ATOCA =3D=3D=3D=3D=3D=3D=3D Agenda --------- Slides atoca-0 Administrivia - Chairs 5 min Status Active drafts draft-ietf-atoca-requirements draft-ietf-atoca-cap is not a WG draft Chairs said there was apparently no way of sorting this out. Keith Drage asked that this issue was sorted out, i.e. have the authors res= ubmit as an author draft (which apparently they have) and declare the draft= with this name dead. Robert said there were issues with this (as of 3 months ago), but would inv= estigate whether the situation had changed with the submission of the autho= r draft. Requirements Discussion 40 min ----------------------------- Slides atoca-1 Brian Rosen Discussion to cover: scale; implicit and explicit subscriptions; alert filt= ering=20 [Slide] Two ways to get alerts Broadcast Subscription [Slide] Scale is, of course, the issue We have some tools for broadcast (e.g. multicast), but not widely useful be= cause not widely supported We would want to take advantage of it when we can We do manage to scale web= queries, no reason to doubt we can scale broadcast The requirement is Inte= rnet scale=20 James Polk: Concerned about making sure do not get an alert that it should = not do so. Also authorised person fraudulently sending message. Presenter diverted to security discussion on second half of the agenda. [Slide] Connecting to alert sources Even multicast requires initial action on the receiver While some L2 specif= ic mechanisms may be able to send alerts without any receiver action, can w= e assume a requirement that the receiver takes some action to connect to th= e alert source? Jeff Thompson: In our assumed configuration there is always some initial ac= tion (that will take some action to connect) Martin Thompson: Too easy to come up with requirements that are far too abs= tract. Wants to have things stated about what this should look like in prac= tice. [Presenter then discovered he had the wrong slides] Ken Colvert: Not just talking about IP multicast, there is always applicati= on layer multicast. Subscription can also be dynamic. [Slide] Figure Hannes: ...did not catch... Presenter: Tree of subscriptions possible. Richard Barnes: Can have fanout of alerts. Either network later fanout or a= pplication layer fanout. Jeff Thomson: What is the difference between this as a newsfeed. Presenter: One solution would be RSS. Presenter: Some things in out system that are not in the RSS. [Slide] Not wanting to get too far ahead of ourselves If the receiver takes action = to connect to the alert source, is this the same as subscription? We do clearly want to differentiate between "send alerts that affect me" an= d "send alerts that affect somewhere else". That might only be what location the alert is for ("mine" or "this") Janet (via Jabber): Elabourate because remote. [Slide] Filtering Not all alerts are of interest Location as a qualifier is a given What other filters might be needed? Source Classification Some kind of taxonomy Severity What else? Martin Thomson: Is the filtering based purely on the information in the ale= rt, or whether filtering based on instructions from downstream point. Need = to discuss this as a requirement, becuase if so, the downstream nodes need = to supply information upstream. Presenter: This is dependent on doing things at the relay, which is valid. Martin: What info is included in alert to allow filtering. What info is fed= upstream to allow filtering at a higher level entity. Presenter: Need requirement to filter on anything in the message. Scott: May not just be the identify of the source, but may need to be the c= haracteristic of the source. What kind of source is it, e.g. local blogger = or police. Jeff: Is this not just the information one has to put in ones subscriptions= . Presenter: SIP SUBSCRIBE already has the notion of filters. Randall Gellens: Use a compound term for each class of filters. Hannes: What from this discussion should go into the document? Presenter: Document currently does a fair job of naming actors and flows. S= ome of the discussion on filters and taking action on ... needs to be in th= e document. James: Have we thought about a use case document by itself? Presenter: No. We can add use cases to the requirements document. Does not = think a separate document is all that useful. Jeff: Need examples at both ends of the spectrum.=20 ???: Can you filter based on the language? Presenter: That could be a filter criteria. Martin Thompson: Thought experiments. Please have this captured. Keith: If talking language also need to talk alphabet. Requirements Discussion (Security) 40 min -------------------------------------------------- Slides atoca-2 Hannes Tschofenig Discussion to cover: authentication and authorization [Slide] Two Phases [Slide] Subscription RFC 3265 talks about: Access Control Denial-of-Service attacks (of server's and third parties) Replay Attacks Ma= n-in-the middle attacks Event packages may describe additional consideratio= ns. XEP 60 covers similar aspects. James Polk: Identified that there is a bis version of RFC 3265. Presenter: Depends on whether there are changes to the security section. Adam Roach: There have been no changes. [Slide] Message Delivery [Slide] KSTO1055887203 KSTO@NWS.NOAA.GOV 2003-06-17T14:57:00-07:00 Actual Alert Public Met SEVERE THUNDERSTORM Severe Likely NATIONAL WEATHER SERVICE SACRAMENTO SEVERE THUNDERSTORM WARNING SEVERE THUNDERSTORM OVER SOUTH CENTRAL ALPINE COU= NTY... TAKE COVER IN A SUBSTANTIAL SHELTER UNTIL THE STOR= M PASSES BARUFFALDI/JUSKIE EXTREME NORTH CENTRAL TUOLUMNE COUNTY IN CALIFORNIA, EXTREME NORTHEASTERN CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN ALPINE COUNTY IN CALIFORNIA 38.47,-120.14 38.34,-119.95 38.52,-119.74 38.62,-119.89 38.47,-120.14 [Slide] MESSAGE sip:aggregator@domain.com SIP/2.0 Via: SIP/2.0/TCP relay.domain.com;branch=3Dz9hG4bK776sgdkse Max-Forwards: 70 From: sip:dean@school.example.edu;tag=3D49583=20 To: sip:tony@foobar.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: common-alerting-protocol+xml Content-Length: ... ......=20 [Slide] Message Delivery:=20 Communication Security SIP/XMPP End-to-End Security Mechanisms Authentication of originator Integrity protection Confidentiality protection Example mechanisms: S/MIME SIP Identity, PAI [Slide] Message Delivery: Alert Security CAP security Authentication and integrity protection Uses XML Digital Signatures Martin Thomson: How serious are we about XML digital signatures? Presenter: Requirements document does not go into this level of detail Richard: Keep the solutions stuff out of the requirements document. Cullen: Avoid SOAP size holes that you will never get out of. Also Javascri= pt something?=20 going on. [Slide] Example SIP MESSAGE method based on TLS and P-Asserted-Identify. Richard: Is there a contradiction here. Use of asserted identity implies no= cryptographic infrastructure but the use of S/MIME implies that you have. Presenter: This example does not assume any digital signatures or suchlike. [Slide] Authorization Alert delivery: Where do the root certs come from? Once digital signature is verified what check is supposed to be performed t= o the author's identity? More likely that underlying SIP/XMPP communication architecture will be uti= lized!? Fewer problems where prior subscription step is performed. E.g. School case= Originator's identity is asserted via SIP mechanisms. How to deal with messages from unknown authors/originators that appear out = of the blue?=20 Cullen: Things you are under serious delusions about P-Access-Identity. Wil= l not be used to bill for 5c phone calls. Sceptical for treating SIPs ident= ity mechanism as useful. One does not work and one does not exist. Richard: Some constraints to the problem that one can leverage. Sidesteppin= g authorisation. How do I know he is someone that is supposed to send alert= s. Today it is people who my local carrier authorise to send alerts. Can bo= otstrap up to find who your local server is and then make some authorisatio= n to get into this space of authorised originators. Presenter: How would this local trust server get me get notifications about= my daughter in Finland. Richard: Two things, getting to an alert server and veryfying that that ale= rt server is authorised to send alerts. Cullen Jennings: Problem is different from the SIP identity problem in a nu= mber of ways. Here is a few parties going to send alerts to a lot of people= . If write down english language policy of who is allowed to do what, crypo= graphically it identifies what occurs. Can decide on asymmetric keying or s= ymmetric keying based on that. Presenter: Subscription model. Cullen: Subscription model is a data transfer model. Brian Rosen: Seems easy to get an appropriate credential for kindergarten c= lass, and similarly for the Tsumani warning. Scale problem is a lot bigger = than that. Have to discuss what the transitive trust issues are. Martin: 3 sorts of things. Identifying the people you trust to provide. Rel= ays taking alerts, what authorisation do these require before passing on al= erts. Discovering identify in some fashion. Chair: How do you trust the relay agent and how does the relay agent trust = the senders. The ultimate end may have less capabilities than the senders o= r relays. Brian: Relay agent cares less about the problem than the recipient. Richard Barnes: Disagree with Brian and agree with Scott. Jeff Thomson. Relay agents have a large vested interest in this. Richard Barnes will review the security requirements. Keith Drage identified that 3GPP SA3 had just started a work item of Public= Warning System security. Work item only just agreed so no material to look= at yet. They have a meeting in April that will carry this further. This sh= ould be investigated for relevance. Meeting ends 16:30. =3D=3D=3DJames Polk (Handwritten, transcription errors my own) ATOCA 3/31@1520-1720 by James Polk - Keith had a process issue about wg states of ID(s) - Robert will look into it. Brian's Reqs ID - Agreed to add use-cases to the reqs ID - to include a good breadth (e.g., Kindergarten's cancelled, Tsunami aler= t) Hannes' ID - Cullen has issues w/ PAI