60 likes | 288 Views
IETF atoca. Brian Rosen N eustar. Background. Lots and lots of L2 specific Authority to Citizen alert technology Most of it is aimed at least common denominator devices Very often, very limited definition of “Authority”
E N D
IETF atoca Brian Rosen Neustar
Background • Lots and lots of L2 specific Authority to Citizen alert technology • Most of it is aimed at least common denominator devices • Very often, very limited definition of “Authority” • Most are single authority, and to cope, each authority has its own system • Virtually all have no opt-out, very few have any form of opt-in
IETF Interest • IETF emergency efforts started with Authority to Authority 9 years ago • Citizen to Authority work started 7 years ago • We’ve been talking about Authority to Citizen for at least 4 years, maybe longer
atoca • “Authority TO Citizen Alerts” = atoca • BOF held, charter discussions have been held for over a year post BOF • We now have an agreed upon charter, but need IESG approval to create a work group
Characteristics • Any IP connected endpoint • Not L2 specific, hopefully able to use L2 available L2 mechanisms • Complementary to other L2 specific mechanisms (CMAS, EWS, …) – people will have lots of devices • Initial target is a limited set of Authorities (government) • atoca won’t discuss how they are appointed, but will describe the authentication and authorization MECHANISMS
Characteristics • Explicit opt-in and opt-out mechanisms • Governments may proscribe controls on this for some kinds of messages • Initial design is small messages that can be rendered in a variety of ways by devices • May contains links to further information • Location based delivery, but not necessarily the location of the device • Use available tools, e.g. CAP • Security is a big deal to be faced