Authority to Citizen Alert (ATOCA) BOF Wednesday, 25 Mar 2009, 0900-1015 Notes by Gonzalo Camarillo and Marc Linsner CHAIR(s): Brian Rosen and Steve Norries Cullen gives a bottle of ice wine to Jon. Hannes presenting: Architectures draft-norreys-ecrit-authority2individuals-requirements-02.txt Hannu: the first bullet (alerts to affected devices in a particular area) is in line with 3GPP's understanding. Henning: taking into account what facebook and twitter do, some of our concerns regarding scalability may not be so relevant. Ken Covert: are these things you would like to have or characterization of systems out there? If it is the latter, it is incomplete. Henning: they are possible solutions using tools that already exist. Henning: do they have regions or points? Hannes: only points. Henning: it would be useful to state what information they need. A description from the origin perspective about who should be notified (e.g., a chemical leak where the area to be alerted is fairly large). Richard Barnes: there seem to be two problems. Who should be getting the alert and How to deliver them. The slides so far has focused on the delivery. Brian: also who is allowed to send the alerts. Brian: who sends them, who gets them, what is in them, and how they are sent. Orit Levin: clarification: do systems nowadays use multicast? Is the discussion about multicast and scalability in scope? Brian: the proposed charter has a line that says: we hope to use systems the IETF has developed. This includes multicast, but it needs to work in existing networks. Orit Levin: but what happens if we use SIP? Brian: what is going to be used has not been decided yet. Hannes: SIP is just an example of things they have looked at. Henning: the problem of the document is that it tries to do three things: describes existing systems, suggests a possible generic architecture, and general notions on technologies that we could use. If this was chartered, we would need three separate documents. We may decide not to work on certain things (e.g., multicast). Brian: we do not have any solution in mind. We do not know what the solution will be. We only have a set of problems and we want to resolve them. We are not set on a particular solution (unlike many other BOFs). Brian: the scope of this WG would need to be very narrow to avoid trying to boil the ocean. Hannes still presenting: draft-rosen-sipping-cap-03.txt Steve: we still need to work on the some issues if we decide to use CAP in SIP. Hannes: the semantics of different elements are very loosely defined. Ted: we had a discussion in ECRIT about how difficult it is to get URN service categorizations. That architecture can be widely used. Alerts are or are not warnings depending on how much you care. We may need to talk to ECRIT about applicability of the technologies. Cold weather is a different alert for a farmer or for another person in the same area. Musgrove: in the requirements you talked about multicast and broadcast. Will both models (subscription model and everybody gets it model) be supported? Brian: yes, both should be supported. For example, you can request to receive alerts that affect someone else. Both are in scope. Musgrove: there are concerns with interworking with existing solutions. People may get irritated because they get several alerts. Keith: the way the slides were distributed is un aceptable. Brian presenting: Proposed Charter Review Shockey: authority to authority Brian: out of scope. xxx: we do not have a definition of authority Brian: authorized agents, primarily government agents. xxx: an authorized agent could be whoever. Are you going to scope it down to big agencies? xxx: take out the primarily if we are only talking about large agencies. Henning: for example, private schools are not government agencies. There is no technical reason to stick to governmental agencies only. Henning: authority to authority. If the mechanism fits for that, I do not see any particular reason to keep it out. For example, the police department subscribes to certain alerts. Brian: OK, but to make progress in the IETF we should scope it to authority to citizen. Henning: If we do not rule out hierarchical mechanisms, it would be OK. Hannes: the emphasis on authorities may be too strong. The metro guys do not see themselves as authorities. Steve: whether or not they consider themselves authorities, they are. Hannu: what is an authority is an academic discussion. Technically, it does not matter so much. We just need to define the interfaces. Hannu: is the idea to come up with the requirements in the IETF or to take existing requirements (e.g., Japanese agencies). Brian: we will develop our own requirements with several inputs. Hannu: because I have seen requirements I did not see anywhere else. Keith: pay for services. You may want to register for a capability in one area. Keith: we are not covering the whole class of authority to citizen communications. We are only covering alerts. Richard: the definition of agency is not only academic. It has to do with the level of authentication and authorization needed. Hannes: the architecture slide with two approaches. most of the requirements apply to the content of the alert. Paul: if you do not define authority very well you will have problems related to security. It is not an academic things. The security requirements will be more narrowly defined. Musgrove: devices without data connection but you can reach them using interworking functions. Brian: that would be outside of the scope of the charter. xxx: careful about the definition of alerts. Some alerts should not fall into what we work on. Brian: clarify that we are talking about emergencies. James Polk: we need to learn from geopriv. We need concise definitions. We need to define authority. xxx: emergency is too specific. Public safety would be a better term. Paul: we are restricting. We need to say: at the end, it is human readable. Richard: Is CAP human readable? Brian: No but can be rendered easily. I need the right words. it needs to be easily rendered as human-readable text. Orit: do we add a requirement to support audio later on? Brian: it is an interesting thing to do but I do not want to deal with media. Not with RTP or anything close to that. Orit: today, existing systems support this. If we come up with a protocol that is too narrow, how useful is going to be? Steve: there are text-to-voice services. Translation services as well. Brian: could Orit send some references to the mechanisms you are talking about and we will think about it. Spencer: opt in and opt out. Does it cover all types of alerts? Brian: it will be in the charter. Ted: I strongly agree with having subscriptions to alerts in an area we are not currently in. Phrase it differently in the charter. Brian: it is only an example. Ted: the example is wrong. It is not up to the system to track your daughter. Is is up to the father to update his subscription. Don't include "track this individual and send me alerts that would be for them". Brian: I would like to take this to the list because I see things differently. Paul: you want to follow a person. Brian: it is not a follow. Paul: what Ted said is correct. You should not have the system follow a person. Get duplicates of all subscriptions to a person. Shockey: we need an architecture reference document. We have a one-to-many protocol. Now we want authority to foo and foo to someone else. We need to have tiers in the architecture. The idea of a subscription model may not be appropriate for a tier but not for others. Musgrove: ITU and 3GPP have efforts in this area. Chairs: we need to revise the charter to include all the comments received. Cullen: it is normal to have an evolving charter. If we have consensus in this room to move forward, we can start working on the charter, with IAB and IESG input, etc. We do not need a polished charter before moving forward. We want to avoid huge hard debates. Chairs: Does this seem like something that needs to be done and that can be done in a reasonable time? Daryl: I could not find the charter when I prepared for the meeting. I would like to have time to review it before we make any decision. Brian: I apologize. Spencer: do we understand how locations look in alerts? Brian: there is a lot of work on that. Spencer: we need to ensure that all works. I sent my comments to the list. Chairs: is this a solvable problem that should be done here? Consensus in the room that it is. Cullen: it sounded like a fairly strong consensus. Robert: I just got an alert that there is a thunderstorm in Dallas and my daughter is there. This thing is useful.