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

[Hannes Tschofenig <[e-mail]>]

Hi Barbara,

based on your review James and I had updated the text. Here is the new 
version:

------

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".  An access network provider SHOULD
    provide this block either by value or by reference in the Provided-By
    section of a PIDF-LO

3.1.1.  Data Provider String

    Data Element:  Data Provider String

    Use:  Required

    XML Element:  <DataProviderString>

    Description:  This is a plain language string suitable for displaying
       the name of the service provider that created the additional data
       structure.  If the device created the structure the value is
       identical to the contact header in the SIP INVITE.

    Reason for Need:  Inform the call taker of the identity of the entity
       providing the additional call data structure.

    How Used by Call Taker:  Allows the call taker to interpret the data
       in this structure.  The source of the information often influences
       how the information is used, believed or verified.

3.1.2.  Data Provider ID

    Data Element:  Data Provider ID

    Use:  Conditional.  This data SHOULD be provided if the service
       provider or access provider is located in a jurisdiction that
       maintains such ids.  For example, in North America, this would be
       a "NENA Company ID".

    XML Element:  <ProviderID>

    Description:  A jurisdiction specific code for the access provider or
       service provider shown in the <DataProvidedBy> element that
       created the structure of the call.  NOTE: In the US, the NENA
       Company ID must appear here.  Additional information can be found
       at http://www.nena.org/nena-company-id.  The NENA Company ID MUST
       be in the form of a URI in the following format:
       urn:nena:companyid:<NENA Company ID>

    Reason for Need:  Inform the call taker of the identity of the entity
       providing the additional call data structure.

    How Used by Call Taker:  Where jurisdictions have lists of providers
       the Data Provider ID provides useful information about the data
       source.

3.1.3.  Data Provider ID Series

    Data Element:  Data Provider ID Series

    Use:  Conditional.  If Data Provider ID is provided, Data Provider ID
       Series is required.

    XML Element:  <ProviderIDSeries>

    Description:  Identifies the issuer of the ProviderId.  A registry
       will reflect the following valid entries:

       *  NENA

       *  EENA

    Reason for Need:  Identifies how to interpret the Data Provider ID.

    How Used by Call Taker:  Determines which provider ID registry to
       consult for more information

3.1.4.  Type of Data Provider

    Data Element:  Type of Data Provider ID

    Use:  Conditional.  If Data Provider ID is provided, Type of Data
       Provider ID is required.

    XML Element:  <TypeOfProviderID>

    Description:  Identifies the type of data provider id being supplied
       in the ProviderId data element.  A registry with an initial set of
       values is shown in Figure 1.

    +------------------------------+------------------------------------+
    | Token                        | Description                        |
    +------------------------------+------------------------------------+
    |Access Network Provider       | Access network service provider    |
    |Service Provider              | Calling or Origination telecom SP  |
    |Service Provider Subcontractor| A contractor to another kind of SP |
    |Telematics Provider           | A sensor based SP, especially      |
    |                              | vehicle based                      |
    |Language Translation Provider | A spoken language translation SP   |
    |Emergency Service Provider    | An emergency service provider      |
    |                              | conveying information to another   |
    |                              | emergency service provider.        |
    |Emergency Modality Translation| An emergency call specific         |
    |                              | modality translation service       |
    |                              | e.g., for sign language            |
    |Relay Provider                | A interpretation SP, for example,  |
    |                              | video relay for sign language      |
    |                              | interpreting                       |
    |Other                         | Any other type of service provider |
    +------------------------------+------------------------------------+

                Figure 1: Type of Data Provider ID Registry.

    Reason for Need:  Identifies what kind of data provider this is.

    How Used by Call Taker:  To decide who to contact when further
       information is needed

3.1.5.  Data Provider Contact URI

    Data Element:  Data Provider Contact URI

    Use:  Required

    XML Element:  <ContactURI>

    Description:  When provided by a service provider or an access
       provider, this information MUST be a URI to a 24/7 support
       organization tasked to provide PSAP support for this emergency
       call.  If the call is from a device, this would reflect the
       contact information of the owner of the device.  If a telephone
       number is the contact address then it MUST be tel URI.  If it is
       provided as a SIP URI then it MUST be in the form of
       sip:telephonenumber@serviceprovider:user=phone.

    Reason for Need:  Additional data providers may need to be contacted
       for error or other unusual circumstances.

    How Used by Call Taker:  To contact the supplier of the additional
       data for assistance in handling the call.

3.1.6.  Data Provider Languages(s) Supported

    Data Element:  Data Provider Language(s) supported

    Use:  Conditional

    XML Element:  <Language>

    Description:  The language used by the entity at the Data Provider
       Contact URI as an alpha 2-character code as defined in ISO
       639-1:2002 Codes for the representation of names of languages --
       Part 1: Alpha-2 code Multiple instances of this element may occur.
       Order is significant; preferred language should appear first.
       This data is required if a Data Provider Contact URI is provided.
       The content must reflect the languages supported at the contact
       URI.

    Reason for Need:  Information needed to determine if emergency
       service authority can communicate with the service provider or if
       an interpreter will be needed.

    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.
------

We made clarifications to Sections 3.1, Section 3.1.2, Section 3.1.5 and 
Section 3.1.6.

Do you think we got closer clarifying the text to meet the concerns you 
raised?

A few remarks below:


On 07/31/2013 07:06 PM, STARK, BARBARA H 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.

The access provider includes this information via the PIDF-LO and the 
service provider includes it via the SIP mechanism. The same data 
structures are used for both mechanisms.

For this reason there is no need to do a "DPI-alike" functionality.

I was hoping that the text in Section 4 ("Transport") clarifies this 
aspects but maybe we should move the transport section to an earlier 
part of the document.


> ------------------- 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.

We changed the text to avoid this concern.

  -------------------- 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"?


We also changed this text to avoid confusion.

  -------------------- 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?

Typically, the call takers do the work but you are right that in certain 
situations someone else might be involved as well. So, we should soften 
that language.

Cia
Hannes

>
> _______________________________________________ Ecrit mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/ecrit
>