Emergency Context Resolution with Internet Technologies
charter-ietf-ecrit-04

[Ballot comment]
The following two new paragraphs are very generic:
Beyond human initiated emergency call request mechanisms, this group will
develop new methods to enable non-human-initiated requests for emergency
assistance, such as sensor initiated emergency requests.

The working group will also address topics required for the operation of
emergency calling systems, such as:  authentication of location, management
of the service URN namespace, augmented information that could assist
emergency call takers or responders.

Don't you want some more precise milestones?

[Ballot comment]

I hate the "WG cares" language. "We care deeply about
your privacy..." is nowadays a bad thing to see really and
this smacks of that. Just they will work on security and
privacy.

[Ballot comment]
I don't understand what is the task behind the following paragraph

  The group will show how the availability of location data
  and call routing information at different steps in the call session
  setup would enable communication between a user and a relevant
  emergency response center.

Pete suggested:
How about: "The group will define protocols for the use of location data and
call routing information at different steps in the call session setup to enable
communication between a user and a relevant emergency response center."

I still don't understand how the location data would "enable communication"?
Basically, you want to report the location data, or what do I miss?

[Ballot block]
While reviewing the -unauthenticated-access document, I referred back to the current ECRIT charter. I found parts of it quite loose and underspecified. Since re-chartering is happening now, I'm hoping that we might be able to tighten things up a bit:

  This working group will describe where and how these mechanisms may
  be used.

Can we change this to "This working group will specify where and how these mechanism are to be used for emergency call requests."? "Describing" isn't really the task; "specifying" is.
 
  The group will show how the availability of location data
  and call routing information at different steps in the call session
  setup would enable communication between a user and a relevant
  emergency response center.
 
How about: "The group will define protocols for the use of location data and call routing information at different steps in the call session setup to enable communication between a user and a relevant emergency response center."

  Beyond human initiated emergency call request mechanisms, this group
  will develop new methods to request emergency assistance, such as
  sensor initiated emergency requests,

"will develop protocols for non-voice communication requests for emergency assistance, such as sensor initiated emergency requests"

  and additional processes
  specified that address topics such as authentication of location,
  service URN definition and use, augmented information that could
  assist emergency call takers or responders.

The grammar is screwed up in there, but more importantly, I don't know what "service URN definition and use" means in this context. (Well, to be fair, I have a pretty good idea of what it means, but it is not explained clearly enough to be useful as a charter item.) So start with, "as well as protocols to address topics such as authentication of location, provision of augmented information to assist emergency call takers or responders, and [fill in what you really mean as a task regarding the URN stuff; maybe 'alternate call types' or something]."

[Ballot comment]
  This working group cares about privacy and security concerns, and
  will address them within its documents.

Change to "This working group will address privacy and security issues regarding emergency calling in its documents."

[Ballot block]
While reviewing the -unauthenticated-access document, I referred back to the current ECRIT charter. I found parts of it quite loose and underspecified. Since re-chartering is happening now, I'm hoping that we might be able to tighten things up a bit:

  This working group will describe where and how these mechanisms may
  be used.

Can we change this to "This working group will specify where and how these mechanism are to be used for emergency call requests."? "Describing" isn't really the task; "specifying" is.
 
  The group will show how the availability of location data
  and call routing information at different steps in the call session
  setup would enable communication between a user and a relevant
  emergency response center.
 
How about: "The group will define protocols for the use of location data and call routing information at different steps in the call session setup to enable communication between a user and a relevant emergency response center."

  Beyond human initiated emergency call request mechanisms, this group
  will develop new methods to request emergency assistance, such as
  sensor initiated emergency requests,

"will develop protocols for non-voice communication requests for emergency assistance, such as sensor initiated emergency requests"

  and additional processes
  specified that address topics such as authentication of location,
  service URN definition and use, augmented information that could
  assist emergency call takers or responders.

The grammar is screwed up in there, but more importantly, I don't know what "service URN definition and use" means in this context. (Well, to be fair, I have a pretty good idea of what it means, but it is not explained clearly enough to be useful as a charter item.) So start with, "as well as protocols to address topics such as authentication of location, provision of augmented information to assist emergency call takers or responders, and [fill in what you really mean as a task regarding the URN stuff; maybe 'alternate call types' or something]."

  This working group cares about privacy and security concerns, and
  will address them within its documents.

Change to "This working group will address privacy and security issues regarding emergency calling in its documents."

[Ballot comment]
Given that one obvious source of location information is the SSID information gleaned from WIFI interfaces, I a surprised that there is no association with groups with that expertise.

[Ballot comment]
  "Explicitly outside the scope of this group is the question of pre-
  emption or prioritization of emergency services traffic."

I assume this is describing the network situation.

The IETF emergency services work does seem to presume that emegency services communication on the devices can preempt other activity on devices or bypass configured handset/device policy. which while not a form of network pre-emption is I think a consideration and should probably be made more explicitly here, e.g.

Explicitly outside the scope of this group is the question of network pre-
emption or prioritization of emergency services traffic.

would stake that out as referring to the network.

Added milestone "Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC", due March 2014, from current group milestones

Added milestone " Submit a draft 'URN For Country Specific Emergency Services' to the IESG for consideration as a Standards Track RFC", due December 2013, from current group milestones

Added milestone "Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC", due December 2013, from current group milestones

Added milestone "Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC", due November 2013, from current group milestones

Added milestone "Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for consideration as a Standards Track RFC", due October 2013, from current group milestones

Added milestone "Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC", due October 2010, from current group milestones

Added milestone "Submit 'LoST Extension for returning Boundary Information for Services' to the IESG for consideration as an Experimental RFC", due December 2009, from current group milestones

Added milestone "Submit 'Best Current Practice for Communications Services in support of Emergency Calling' to the IESG for consideration as a BCP document", due July 2009, from current group milestones

Added milestone "Submit 'Framework for Emergency Calling using Internet Multimedia' to the IESG for consideration as an Informational RFC.", due July 2009, from current group milestones

Added milestone "A Standards Track RFC describing how to identify a session set-up request is to an emergency response center", due July 2006, from current group milestones