ATOCO WG
==========

Friday 12th November 2010 - 13:00 - 15:10

minutes by Keith Drage and Richard Barnes
---------------------------

Chair status and agenda bashing
--------------------------------

Complaint from James Polk that two internet drafts were not agreed as WG items yet have WG names.

Bradner: confirmed that they are not WG items, and status will be determined by this meeting.

Thomson gave overview of the charter and scope of the WG.

Exigent communications

Work is being done by other groups.

Challenges include authorization, congestion, identification.
	Not trying to distinguish tsunami, wave, high water

Spencer Dawkins: Not seen anything on the slides so far asking about Security and privacy.

Thomson: Definitely fundamental parts of what we're doing

Hannu: Security is definitely an issue, but might not equal confidentiality/privacy in this case

Bradner: Also useful for non-authority entities (e.g., universities), which could have more confidentiality
	How do you identify a set of target users?


3GPP Public Warning System
---------------------

Slides: atoca-0

Hannu Hietalahti presenting.

Spencer Dawkins: Can you talk about the EU alerting requirements?
Hannu: Starting to look a lot like the US CMAS requirements
	Delivery to all subscribers in a given area, roaming or not

Zachary Zelzan asked for clarification on "Reception and presentation of Warning Notifications to the user shall not pre-empt an active voice or data session". Alert should not interrupt an existing call, and therefore will not necessarily, but is allowed to, take display when such a call is in progress.

Igor Faynberg wanted information about the C interface. Mark Wood answered that it is based on OASIS.
Mark Wood: It's based on CAP == X.1303

Spencer Dawkins: Do you have links that people can go to for more information?

Hannu: Check out 3gpp website, they're openly available

Keepeng Li: Identified role of NOVES in 3GPP.

Hannes Tschoefienig: NOVES relates to ECRIT work, so it is citizen to authority. Just does not establish a voice channel. This work is authority to citizen.

Hannu Hietalahti: Confirmed.

Brian Rosen (via Jabber): Is there a standard for IP multicast in 3GPP networks?

Hannu: Not right now, but it's not excluded


ITU-T and ETSI
--------------

Mark Wood presenting.

No slides.

SG 17 is looking at signaling between and settled on CAP.

SG2 looking at harmonizing message identifier address space.
Using different multicast addresses to distinguish classes, languages

ETSI referred to current published document.

Bradner: Notice that they authenticate message source by IP address
	Pretty high-level requirements document

Ken Carlberg: Assume that the MI is the same as a multicast address in terms of representing a group
	Assume you're not going to configure a distribution tree based on that 

Wood: Cell broadcast doesn't have PIM, etc.; requires manual configuration
	Good for privacy

Hannu: 3gpp and ITU-T have coordinated some on this topic

Igor Faynberg: Speaking of SG13. Gregory Bain can speak to work ETS work in SG13.

Spencer Dawkins: Send note to making on how to retrieve ETSI document.

Gregory Bain: Emergency services NGN technical considerations. Y.2205 and is published. Send pointer to mailing list. There is a clause in Y.2205 relating to early warning. Most work is authority to authority. This document has a number of definitions.

Spencer Dawkins: As IAB: Is it publicly available for download? Answer. Yes it is. Spencer referred to view that IETF participants are covered under ISOC membership for work in progress. 

Igor Faynberg: Don't know exactly the latest but stated that heard that ITU had decided to open all documents. 

Chair: This is not entirely clear whether it applies to adopted documents only, or whether that is all documents.

Peter Saint-Andre: Reminder, we all participate as individuals rather than organizations

XMPP for CAP
-------------

Joe Hildebrand presenting.

Slides: atoca-4
	National Weather Service already using this

Keepeng Li: Can you include a CAP message into the XMPP. Response: Yes, easier to implement if separate publisher and subscriber. Q: Why use XMPP. Response: Just providing for information.

Randall Gellens: Did you mention there is some preference in US federal areas for using XMPP. Response: There is a DOD mandate for IM in presence. Spreading wider through other agencies that interact with DOD. Gives security properties and ability to federate.

Mark Wood: Because of restrictions with Cell Broadcast, strip headers and only transmit the text. XML only used between the agencies.



Requirements, Terminology and Framework for Exigent Communications 
------------------------------------------------------------------

Hannes Tschofenig presenting

Slides: atoca-1

Ken Carberg: For CBS some alerts can opt out of, and some cannot. Does this exist here.

Peter Saint-Andre: There are implicit subscriptions in XMPP.

Mark Wood; ETSI document gives regulatory framework that different levels have opt out or not as the case may be. Default is for terminal to have all channels turned on

Keeping Li: Who sends the subscription - is it the user or authority. Response: Can be both. 

Igor Faynberg: How do you test against unspecific requirements e,g, How large is a large group?

Bradner: Postpone until after presentation

Keith Drage: Referring to P1: Only covers half the story because does not cover the congestion relationship with other traffic on the system, which may well be emergency calls in its own right.

Bradner: Also is it always to use the lower layer infrastructure.

Brian Rosen: It should also be possible for recipients to see who sent the alert

Igor Faynberg: Referring to originator impersonation: Does this mean credentials rather than identity. Response: In many cases today make a distinction based on originator and his organization.

Bradner: Authorization is not solely based on identity but may be based on other information.

Hannes: Separation between individual and organization

Igor: Is there a requirement to authenticate the originator.

Keeping Li: Requirement that language should be indicated, but solution draft doesn't do it

Mark Wood: Should IANA be consulted.

Bradner: This is a requirements document - that issue does not come up here.

Bradner asked to adopt as a working group document: Everyone in room that expressed an opinion expressed that this should be adopted.

Thomson asked who had read the requirements document: One third of the room.


Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) 
------------------------------------------------------------------------------

Hannes Tschofenig presenting

Slides: atoca-2

Martin Thompson: Are these being copied or referring work in other place. Response: They are being copied and defined in full in this document. Semantics are in the CAP specification.

Brian Rosen: Started with the CAP list, One advantage of URNs is that you can incorporate other orgs as sub-namespaces

Keeping Li: If want to extend, how do we do this. Response: Create an IANA registry. 

Brian Rosen: This is the taxonomy question. Can use other organization and then adopt as a subset of this list.

Thomson: Define amplification. Response: This is when alert is sent and gets branched to a number of different subscribers. 

Bradner: Note that one of the ETSI requirements is that some messages are not allowed to be cut pasted or saved.

Thompson: Couple of other things came from earlier discussion. Confidentiality of contents of alert. Confidentiality of the recipients of particular messages.

Igor Faynberg: Back to simplification. Why would it be problem to authenticate the originator of early warning. One would expect that there is a certificate. Response: What are the main use cases? Based on lower layer security mechanisms. Weather alerts no security.

Brian Rosen: The problem is Internet scope, need world-wide authority authentication

Thompson: Two problems. Before amplification need to know that things should be distributed. When delivered, user needs some assurance that it is valid message. 

Richard Barnes: Disagree with Brian's claim that one would need a worldwide authority for security. Other things could work. Commented also currently focused on perimeter defense. Very at end point that things came from trusted sources. 

Keeping Li: Event filtering issue?? Will you use separate draft to fulfill the requirements.

Keith Drage: Relationship to requirements document. How will we use requirements document to test the solution document because there is content here that is not reflected by the current underlying requirements.

Bradner: We did agree in the room that the requirements document should be adopted.

Cullen (via Jabber): Document was not on the agenda when he printed out. Didn't read the doc; wonder how many did?

Brian Rosen:  Not unreasonable to spin requirements more.

Bernard: ditto Cullen. Security requirements need more work.

Bradner: We'll give the requirements another spin before we work on adopting a solution doc

Meeting finished 15:10.