Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 01 May 2013 12:22:23 +0300

Hi Gunnar,

thanks for the feedback.

Based on your input I added the following text to the terminology 
section of the draft.

"
    This document also uses terminology from [RFC5012]. We use the term
    service provider to refer to an Application Service Provider (ASP) or
    to Voice Service Provider (VSP), which is a specific type of ASP.
    With the term "Access Network Provider" we refer to the Internet
    Access Provider (IAP) and the Internet Service Provider (ISP) without
    further distinguishing these two entities, since the difference
    between the two is not relevant for this document. Note that the
    roles of ASP and access network provider may be provided by a single
    company.
"

Do you think that this change will help to improve readability of the 
document?

Ciao
Hannes

On 04/30/2013 09:18 AM, Gunnar Hellstrom wrote:
>
> ------------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> [email-masked]
> +46708204288
> On 2013-04-29 23:22, Hannes Tschofenig wrote:
>> Hi James,
>>
>> I am trying to incorporate some of your review comments and I have a couple of questions.
>>
>> On Mar 18, 2013, at 5:41 AM, Winterbottom, James wrote:
>>
>>> Hi Authors,
>>>
>>> I have reviewed this document and have the following comments, some of which I have already posted to the list and have not had a reply to.
>>>
>>> Comments:
>>> =================
>>> The term “Service Provider” is used extensively throughout this document but the term doesn’t seem to be obviously defined in the document, nor is there is a reference to an external definition. To add to this, Service Provider is a defined type in section 14.1.2, but used more generally throughout the rest of the document. This needs a clarification.
>> I searched for an appropriate definition in IETF RFCs and it turns out that others have defined this term either.
>>
>> Do you have a recommendation what we should use? Do you think it is really necessary to describe it?
> I had a similar problem in another SDO recently. I used "service
> provider" or "communication service provider" for an organization
> handling calls and subscribers.
> The conclusion there was to change it to "Application Service Provider"
> with the following definition:
>
> *"Application Service Provider (ASP): *organization or entity that
> provides application-layer services, which may include voice, video and
> text communication"
>
> The reason for confusion was apparently that some thought of the network
> access service provider while others thought about the call control
> service provider when using the term "service provider".
>
> It stands out clear in section14.1.2. that it is a problem.
> The table with service provider types contains "service provider" as one
> of the types.
>
> At least this recursive use of the term needs to be broken.
>
> I briefly checked RFC 6881 and RFC 4504 to check how they handled
> "service provider" and found that you are in good company. The term is
> just used without definition and seems to mean an organization working
> on the SIP or other call control level and manages subscribers.
>
> I suggest that this definition is used:
>
> *"Application Service Provider (ASP): *organization or entity that
> provides application-layer services, which may include real-time
> communication"
>
> And then check through the occurrences and replace the ones that have
> the narrow meaning of "Application Service Provider".
>
>
> /Gunnar
>
>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Wed, 01 May 2013 19:26:28 +0200

> Do you think that this change will help to improve readability of the 
Yes.

You need also do something to the table in section 14.1.2.

There you say that the whole table is about service providers, and then 
one of the kinds of service providers is called just "service provider". 
That is unclear logic.

/Gunnar

>>>> I have reviewed this document and have the following comments, some 
>>>> of which I have already posted to the list and have not had a reply 
>>>> to.
>>>>
>>>> Comments:
>>>> =================
>>>> The term “Service Provider” is used extensively throughout this 
>>>> document but the term doesn’t seem to be obviously defined in the 
>>>> document, nor is there is a reference to an external definition. To 
>>>> add to this, Service Provider is a defined type in section 14.1.2, 
>>>> but used more generally throughout the rest of the document. This 
>>>> needs a clarification.
>>> I searched for an appropriate definition in IETF RFCs and it turns 
>>> out that others have defined this term either.
>>>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Wed, 01 May 2013 20:52:41 +0200

Hannes,

Looking at the contents of the list of different service providers, I 
wonder if there should be more types defined.
It depends of course on what usage this information is expected to have.

It seems that the various language translation and expert advice 
services that can be involved in emergency calls could be of interest to 
include here.

Current list
------------------------------------------------------------

        14.1.2
        <http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-07#section-14.1.2>.
        Additional Call Data Service Provider Type Registry

    +------------------------------+------------------------------------+
    | Name                         | Description                        |
    +------------------------------+------------------------------------+
    |Access Infrastructure 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                      |
    |Relay Provider                | A interpretation SP, for example,  |
    |                              | video relay for sign language      |
    |                              | interpretors                       |
    |Other                         | Any other type of service provider |
    +------------------------------+------------------------------------+

-------------------------------------
Proposal with more types

    +------------------------------+------------------------------------+
    | Name                         | Description                        |
    +------------------------------+------------------------------------+
    |Access Infrastructure Provider| Access network service provider    |
    |Application 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   |
    |Expert advice provider        | An SP giving expert advice         |
    |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 |
    +------------------------------+------------------------------------+

-----------------------------------
I inserted the "Emergency Modality translation", because there is a 
tendency in USA to not use the term "relay service" for cases when the 
service is arranged specifically for
handling modality conversion in emergency call and when the PSAP can 
participate in all media communication but need this extra service to 
mediate the communication.

The expert advice provider is usually added in a bridge operation after 
the original incoming call. But I can imagine that the additional-data 
is of interest also for such situations

For deciding on this, I think it would be good to have an idea of the 
use of this information.

Will it be used for a review if a call was properly handled?  If so, 
maybe even more detail is needs, such as what kind of relay service was 
invoked, so that it is possible to check if it was of a suitable kind.

Or are such details provided in some other parameter?

I think this should be checked with EENA and NENA to verify if more 
needs in this area have been developed lately.

/Gunnar

---

From: Matt Serra <[email-masked]>
Date: Wed, 1 May 2013 14:36:33 -0500

One thought:  It may be worthwhile to distinguish "Internet Access Provider" over Internet Service Provider, no?

For the purposes of this RFC, the "access" provider we are referring to is expected to be the provider of the location associated with the call's PIDF-LO.

This is the entity that knows the location of the device placing the call.  Typically this will be the "last mile" provider, as opposed to a different internet service provider in the middle of the call path (who probably doesn't even know the data is associated with an emergency call).

If we can use language that helps make this distinction, I think that would be a good thing.

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

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]] 
Sent: Wednesday, May 01, 2013 1:26 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

Yes.

There you say that the whole table is about service providers, and then one of the kinds of service providers is called just "service provider". 
That is unclear logic.

/Gunnar

>>>> The term "Service Provider" is used extensively throughout this 
>>>> document but the term doesn't seem to be obviously defined in the

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 2 May 2013 06:01:34 +0800

Hi Matt,

I am not sure that I follow your assertion.
In the cases that I know of, a subscriber gets an Internet subscription from an ISP. How that ISP implements that service and makes it available to the subscriber is largely unknown to the subscriber. The subscriber only has a relationship with the ISP, so it is quite possible that the physical "last-mile" provider has no idea of the service being run over the physical medium or who the person is that is running this data, all they know is where the able terminates and that the ISP (the organization that they have the contract with) has the other information. 

So I think that the question really boils down to who is providing the service and to whom. So far, all the entities really relate to the service actually subscribed to by the caller. If we take this approach, then I don't see a need to go down to the level you describe, or even how we would get there in a timely fashion. I think that this could be provided as follow-up information manually if really required.

Cheers
James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Serra
Sent: Thursday, 2 May 2013 5:37 AM
To: Gunnar Hellstrom; Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

Matthew A. Serra, ENP

-----Original Message-----
From: Gunnar Hellstrom [mailto:[email-masked]] 
Sent: Wednesday, May 01, 2013 1:26 PM
To: Hannes Tschofenig
Cc: [email-masked]
Subject: Re: [Ecrit] draft-ietf-ecrit-additional-data-07

Yes.

/Gunnar

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 05 May 2013 21:08:37 +0300

Hi Gunnar,

thanks for the feedback.

Comments below.

> services that can be involved in emergency calls could be of interest to

I personally think that the clarifications you added and the new types 
are good. We might need to change the Access Infrastructure Provider" to 
"Access Network Provider", as we did in the terminology section.

I am also not sure why there is the "Service Provider Subcontractor" term.

Why wouldn't you call it "Emergency Modality Translator" instead?

> is of interest also for such situations

Why wouldn't you use the term "Relay Provider"?

> For deciding on this, I think it would be good to have an idea of the

Section 5.4 provides a little bit of information about how this data is 
used:

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

This is essentially meta-data about the entity that provides information.

> invoked, so that it is possible to check if it was of a suitable kind.

When you say "what kind of relay" what would you pass along?

> Or are such details provided in some other parameter?

You have to check in the rest of the document. Since I don't know what 
other information you have in mind I do not really know whether it is 
already available.

> needs in this area have been developed lately.

Definitely. This work was initially developed in NENA and there were two 
groups working on this stuff.

I am definitely planning to produce a tutorial for the emergency 
services authorities in Europe to provide some feedback. Letting them to 
review this draft is maybe not too useful since the information is too 
low-level.

Ciao
Hannes

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 06 May 2013 07:09:16 +0200

On 2013-05-05 20:08, Hannes Tschofenig wrote:
>>     | Name                         | 
>> Description                        |
>>     |                              | vehicle 
>> based                      |
>>     |                              | 
>> interpretors                       |
>>     | Name                         | 
>> Description                        |
>>     |                              | vehicle 
>> based                      |
>>     |                              | 
>> interpreting                        |
> are good. We might need to change the Access Infrastructure Provider" 
> to "Access Network Provider", as we did in the terminology section.
Right
> I am also not sure why there is the "Service Provider Subcontractor" term.
The draft seem to have some very specific thoughts embedded about that. 
I hope the original source can explain.
> Why wouldn't you call it "Emergency Modality Translator" instead?
Yes, maybe.

The EAAC group of FCC has produced a report on this kind of services,

Media Line Communication Services  ( MCLS )
http://www.fcc.gov/document/eaac-mcls-report

This is still advice from EAAC to FCC, and has not resulted in firm 
establishment of that term.

> Why wouldn't you use the term "Relay Provider"?
In the discussion in the EAAC USA, it was clear that "relay service" was 
strictly seen as tied to a service that:
    1. Isolates the user from the destination, by relaying the 
information between the two parties in the call.
    2. Is brought into the call as a complement to the call application 
service provision ( the telecom call provider).
    3. Is funded under specific regulation for funding such relaying 
related to phone calls. If translation, modality conversion of 
interpretation is brought into a call by another provider, or under 
other regulation not falling under the regulation for funding relay 
services, it should not be called a relay service.

In corresponding discussions in Europe, we have not been that strict and 
are calling this type of service "relay service" whoever brought them 
into the call and even if they act as a complement in a call when the 
user and the emergency service also have direct media contact in all 
media provided in the call.

So we have a mix of term usage here.

> Section 5.4 provides a little bit of information about how this data 
> is used:
>
If there is value of detailing it, it should be in the types described 
by ETSI ES 202 975 Harmonized Relay Services
http://www.etsi.org/deliver/etsi_es/202900_202999/202975/01.02.01_60/es_202975v010201p.pdf

That is after the main modality they convert
sign relay
text relay
speech relay
lip-reading relay   ( exists but rare )

and a special variant of text relay, called captioned telephony relay

there should also be the sign-and-text relay   using sign language one 
way and text the other.

> other information you have in mind I do not really know whether it is 
It was not.
And the described intended use indicate that it could be of value to 
specify this detail, so that it is evident for the call taker what kind 
of support already is available in the call, when they judge uf any more 
supporting services are needed.
> Definitely. This work was initially developed in NENA and there were 
> two groups working on this stuff.
>
> services authorities in Europe to provide some feedback. Letting them 
> to review this draft is maybe not too useful since the information is 
> too low-level.
>
> Ciao
> Hannes
I suggest that you add also the service provider type: Emergency Service 
Provider.

To be added by an Emergency Service if they decide to stay on the call, 
but invoke another emergency service also on the call.
This may be of language support reasons in the way that EENA has set up 
a procedure for support of calls made in the "wrong" country in another 
language than the local language at the site of the emergency.
It may also be of kind of expertize needed.

Or, are there separate fields for that somewhere else?

/Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 06 May 2013 07:09:22 +0200

Right
Yes, maybe.

It was not.

/Gunnar