Re: [earlywarning] Finishing the Charter Text Discussions

["James M. Polk" <[e-mail]>]

At 10:30 AM 4/7/2010, SENNETT, DEWAYNE A (ATTCINW) wrote:
>Hi Hannes,
>
>Based upon the previous email decisions, changes to the charter text are
>still needed.
>
>The second paragraph of the charter provides a high level purpose and
>scope for the ATOCA work.  The following should be added to the end of
>the second paragraph to provide further clarification on the purpose and
>scope of the ATOCA work:
>
>"The ATOCA solutions will not adversely affect the ability of any access
>technology to provide emergency services to the citizens (e.g. 9-1-1
>calls) or to provide communication services to first responders or other
>authorized emergency services personnel.

The above sentence is troubling to me too.  Take the old adage "one 
man's victory is another man's defeat". In that - I mean -- who's to 
say that an ATOCA (layer 3-7) solution adversely affects a layer 2 
solution (existing or planned)?  This is nearly always in the eyes of 
the beholder.  The IETF, for the most part, deals only with layers 
3-7, and leaves lower layer solutions to other SDOs. The classic 
example is wrt IEEE.

Put another way - if you are a proponent of the WARN act, you like 
the 140 character limitation for any message.  Most of us in the IETF 
feel that's too limiting, and believe we can create something that is 
much more useful.  Now, anyone that MUST be in compliance with the 
WARN act needs to support at least the 140 character limitation. Does 
that mean there can be no other communication with a richer set of information?

Some might say that idea alone "adversely affect an access 
technology" because who implements both are taking on increased complexity.

Is that a reason to stop progress?

In the 50s the railroad industry tried to prevent the airline 
industry from becoming certified, at least in the US.  The rail 
industry say the airline industry as a threat.  Now, was that effort 
good for anyone?

If someone doesn't implement what the IETF specifies in ATOCA, then 
they don't implement it. We let the market decide -- of course where 
jurisdictions allow.

I am opposed to the suggested change to the charter.

James

>Additionally, ATOCA is not
>replacement solution for any authority to citizen alerting supported by
>any access technology."
>
>Regards,
>
>DeWayne A. Sennett
>
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]] On Behalf Of Hannes Tschofenig
>Sent: Tuesday, April 06, 2010 4:18 AM
>To: [e-mail]
>Subject: [earlywarning] Finishing the Charter Text Discussions
>
>Hi all,
>
>we had some discussions in response to the charter text I distributed. I
>made some minor changes based on the received comments but most of the
>discussions seemed (at least to me) not related to the charter text
>itself.
>
>Is the charter text OK for everyone?
>
>Ciao
>Hannes
>
>----------------
>
>Authority to Citizen Alert (ATOCA)
>==================================
>
>Authorities need mechanisms to notify citizens and visitors of emergency
>events.   Traditionally, they have done so with broadcast networks
>(radio
>and television).  The Internet provides another way for authority to
>citizen
>alerts to be sent, but it also presents new challenges. While there are
>some existing layer 2 mechanisms for delivering alerts the work in this
>group
>focuses on delivering alerts to IP endpoints only.
>
>The general message pattern that this group is intended to address is
>the
>sending of alerts from a set of pre-authorized agents (e.g.,
>governmental
>agencies) to a large population. The goal of this group is not to
>specify
>how originators of alerts obtain authorization, but rather how a
>messaging
>system can verify authorization and deliver message to the intended
>recipients.
>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 (e.g., audio and/or video), but the initial
>work in the group is focused on small messages, which may be
>mechanically
>rendered by the device in other forms (text to speech for example). In
>situations of a major emergency there could be scenarios where there are
>
>multiple alerts generated that may require that a priority mechanism has
>to
>be used. The work on a resource priority mechanism is out of scope of
>the
>initial charter, but may be revisited at a later date.
>
>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
>that
>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. The group will explore how to support both opt-in
>and
>opt-out at the level of communication protocols.
>
>Another class of recipients that are in scope of the work are explicit
>opt-in subscriptions which ask for alerts for a specified location.
>An example of such a subscription would be 'send me alerts for
>location x' (previously determined as the location of interest).
>This work builds on existing IETF geopriv location work.
>
>There are efforts in other fora on early warning, which will be
>considered
>in this effort.  For example, we expect to make use of the OASIS Common
>Alerting Protocol (CAP) for the encoding of alerts.  OGC, ATIS, TIA,
>ITU-T,
>ETSI and 3GPP also have alert efforts underway, and consultation with
>these
>efforts will be undertaken to avoid unnecessary duplication of effort.
>Of course, existing protocols for delivering messages (e.g., SIP)
>will be the basis for the message delivery system of this working group.
>
>The security implications of mechanisms that can send alerts to billions
>of
>devices are profound, but the utility of the mechanism encourages us to
>face
>the problems and solve them.
>
>Milestones
>
>TBD      Initial document for "Terminology and Framework" document.
>          A starting point for this work is
>          draft-norreys-ecrit-authority2individuals-requirements.
>TBD      Initial document for conveying alerts in SIP
>TBD      Initial document for subscribing to alerts using SIP
>          A starting point for this work is draft-rosen-sipping-cap
>TBD      Initial document for locating the alerting server for a
>          geographic region. A starting point for this work is
>          draft-rosen-ecrit-lost-early-warning.
>
>_______________________________________________
>earlywarning mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/earlywarning
>_______________________________________________
>earlywarning mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/earlywarning