Subject: [Ecrit] Comments against Additional Caller Data v4.0 ECRIT Draft from NENA Add'l Data WG.

From: Matt Serra <[email-masked]>
Date: Mon, 23 Jul 2012 16:13:43 -0500

On behalf of the NENA Additional Data Work Group, I respectfully submit the following comments against this document: http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-04 

--------------Begin Comments--------------

1. Introduction

* V4.0: "In general, there are four types of data exchanged:"
* NENA Comment: Recommend we reference "three" rather than "four" types of data.  This also requires that we strike the associated "Data associated with a PSAP:" paragraph.

* V4.0 Nit:  " Data Associated with a Call:  . . (as part of the SIP headers as well as in the body of the SIP message,"
* NENA Comment:  (nit) is missing a closing parentheses " . . (as part of the SIP headers as well as in the body of the SIP message),"

3. Call Info Specification

* V4.0 "More than one Call-Info header with an emergencyCallData purpose can be expected, but at least one MUST be provided.  The device MUST provide one if no service provider is in the path of the call.  The device MAY insert one if it uses a service provider, and any intermediary service provider SHOULD insert its own.  When there are multiple intermediaries, each intermediary SHOULD each insert one."
* NENA Comment: While the first sentence states emergencyCAllData must be provided, the rules that follow this sentence do not necessarily ensure this is the case.  We recommend this paragraph be reworked to ensure at least one set of Call Data is provided with each call.

4.3 Type of Data Provider ID

* v4.0 " Description:  Identifies the type of data provider id being supplied in the ProviderId data element.  A registry will reflect the following valid entries:
      *  Access Provider
      *  Origination Network Provider
      *  ServiceProviderSubcontractor
      *  Other
* NENA Comment:  We recommend the terminology used in ECRIT documentation be used, rather than the terminology proposed above. Perhaps consider adding other valid values as well, such as "Relay Service Provider", "Telematics Provider", etc.

* v4.0:  this document speaks to the "function" provided by the referenced Data Provider
* NENA Comment:  The original intent of this field was to convey which registry the "Data Provider ID" (4.2) refers to (e.g. NENA Company ID).  It seems as if a separate field to convey the function of the referenced "Data Provider ID" needs to be documented.

* V4.0 "Description . . .  A registry will reflect the following valid entries"
* NENA Comment:  While the registry is mentioned in the "Description" no such registry is called for within Section 12.1 Registry Creation

4.7 Subcontractor Principal

* V4.0 "Description: . . . the data provider is a subcontractor to an access provider or origination network, this element contains the DataProviderString of the access provider or origination network"
* NENA Comment: Similar to feedback on 4.3, should consider alternate terms for "access provider" and "origination network" consistent with other ECRIT documents.

5.1 Service Environment

* v4.0 - " Reason for Need:  To assist in determining equipment and manpower requirements."
* NENA Comment:  we recommend softening current reason for need, adding a reference to ALI backwards compatibility (for Legacy PSAP Gateway).  Sample text: "May be useful in determining equipment and manpower requirements during dispatch. Supports Legacy PSAP Gateway data transcoding."  Similar changes are recommended for "How used by Call Taker"

5.3.  Service Mobility Environment

* v4.0: "Service Mobility Environment"
* NENA Comment:  As the valid values describes service environments other than Mobile, a more generic name (such as "Service Use Environment" or "Service Deployment Environment") may be warranted

5.4.  addCallSvcInfo XML Schema

* v4.0: " <xs:element name="SvcMobility" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
* NENA Comment:  We believe the maxOccurs should be "1" rather than "unbounded".  The minOccurs should also be "1", as this is a required field.  We recommend the various XML definitions be inspected throughout this DRAFT for field usage consistency / accuracy.

6.1.  Device Classification

* v4.0: "It is possible to receive 2 Additional Data Associated with a Caller data structures, one created by the device and . . ."
* NENA Comment:  Should reference "Additional Data Associated with Call", rather than "Caller"

* v4.0: " Reason for Need: . . . does the device require human intervention to initiate a call or is this call the result of programmed instructions?."
* NENA Comment: Nit - extraneous period (.) after question mark (?)

--------------End Comments--------------

Matthew A. Serra, ENP
NENA Additional Data Workgroup Chair

Sr. Director, Product Management 
Rave Mobile Safety | Smart911
Mobile:  201.245.1557
[email-masked]