Subject: [Ecrit] draft-ietf-ecrit-additional-data-10: comments on data provider elements

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 31 Jul 2013 17:06:11 +0000

I finished my review of draft-ietf-ecrit-additional-data-10. I'm sending my comments divided among 5 emails. These are miscellaneous comments on data provider elements.
Barbara
-------------------
3.1.  Data Provider Information

   This block is intended to be provided by any service provider in the
   path of the call or the access network provider.  It includes
   identification and contact information.  This block SHOULD be
   provided by every service provider in the call path, and by the
   access network provider .  Devices MAY use this block to provide
   identifying information.  The MIME subtype is "application/
   emergencyCall.ProviderInfo+xml".

Comment 1:
How are you expecting an access provider to know to include this block? What is the trigger? This could be a problematic recommendation as some access providers are explicitly forbidden from altering anything in the IP payloads of the packets they transport/route. If IP payload is encrypted, then it can't be done. But if the expectation is that this would happen when providing location (so it's in the Reference/Value Provided-By of supplied location), then that's ok but it might be useful to mention this.
-------------------
3.1.2.  Data Provider ID

   Data Element:  Data Provider ID

   Use :  Conditional.  Must be provided if the service provider is
      located in a jurisdiction that maintains such ids .  Devices are
      not required to provide it.

   Description:  A jurisdiction specific code for the provider  shown in
      the <DataProvidedBy> element that created the structure of the
      call.  This data SHOULD be provided if the local jurisdiction
      maintains such an ID list.  For example, in North America, this
      would be a "NENA Company ID".  Devices SHOULD NOT use this
      element.

Comment 2: Needs to say something about access provider use.
Comment 3: I don't think this sort of condition (dependency on whether some undefined organization in undefined jurisdictions do or don't do something) belongs in a RFC. Compliance is difficult to ascertain. My opinion is that this information would be better as guidance rather than normative.
Comment 4: The first use of "provider" in Description may need to be more specific. "Provider" as a stand-alone term is undefined, but it may be that only service providers will have jurisdiction specific codes, and not necessarily an access network provider.
--------------------
3.1.5.  Data Provider Contact URI
   Use:  Required
   Description:  For a service provider the contact SHOULD  be a contact
      URI.  This  MUST be a SIP URI.  If a telephone number is the
      contact address it should  be provided in the form of
      sip:telephonenumber@serviceprovider:user=phone.  If the call is
      from a device, this would reflect the contact information of the
      owner of the device.  When provided by a service provider, this
      would be a URI to a 24/7 support organization tasked to provide
      PSAP support for this emergency call.

Comment 5: This is confusing. A ContactURI *should* be a ContactURI? What else could it be?
Comment 6: What is the antecedent of "This" (This MUST be a SIP URI)? Is "This" the optional contact URI from the previous sentence (if contact is ContactURI then it MUST be a SIP URI)?
Comment 7: Is the 2nd should a normative SHOULD? Or is this more of "will" or non-normative "may"?
--------------------
3.1.6.  Data Provider Languages(s) Supported
   How Used by Call Taker:  If call taker  cannot speak language(s)
      supported by the service provider, a translation service will need
      to be added to the conversation.

Comment 8: Is this really the call taker or maybe also someone else at PSAP?