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

[James Winterbottom <[e-mail]>]

Hi Barbara,

Please see comments inline.

Cheers
James

On 01/08/2013, at 3:06 AM, "STARK, BARBARA H" <[e-mail]> wrote:

> 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.
[AJW] I was certainly envisioning that the access provider would include a URI in the Provided-By section of any PIDF-LO it provides. This URI can then be dereferenced by authorised parities to obtain the associated access provider information. I will include a note to this effect.
> -------------------
> 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.
[AJW] Not sure why they need explicit call out. If they have an ID then they fill out this chunk of data.

> 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.
[AJW] I am okay with "Recommended" rather than SHOULD.

> 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.
[AJW] I will add something to make it clearer that it applies to any provider that has such a code.
> --------------------
> 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?
[AJW] This is not referring to the SIP header, it is referring to a way in which to contact the service provider potentially even using an old rotary phone.

> 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)?
[AJW] The sentence is actually wrong. The contact information must be in URI form. It may be a tel uri or a SIP URI. If it is a telephone number expressed as a SIP URI then it has to have the user=phone parameter.

> Comment 7: Is the 2nd should a normative SHOULD? Or is this more of "will" or non-normative "may"?
[AJW] I will update the normative language when I update the tel uri text.

> --------------------
> 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?
[AJW] for the service provider it will likely be someone else. I will update the text to say something like:
"If the person contacting the service provider cannot speak the language(s) supported by the service provider then a translation service can be added to the conversation.
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit