Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 May 2008 21:19:44 +0300

Hi Keith,

there are 4 types of emergency services:

-	citizen to authority
-	authority to authority
-	authority to citizen
-       citizen to citizen

Nowadays people tend to use "individuals" as a replacement for "citizen". 

These terms are defined in ETSI EMTEL documents (and typically used in 
the same fashion everywhere).

I have to check whether the ECRIT framework draft says that our work is 
about "citizen to authority" emergency services. The context should make 
it clear, however. It does not hurt to be explicit. I don't have fears 
that someone could get a wrong impression about the purpose of our work. 
I am obviously not so sure about the current TSVWG document.

We have organized a couple of workshops and talked to the different 
stakeholders in the space of "citizen to authority" emergency services 
and we had to realize that balancing the different interests is very 
challenging to accomplish some deployment.

Now, I claim that authority-to-authority and authority-to-citizen is not 
any easier to deploy.

We see a document that specifies a fairly small extension to RSVP 
(considering that some other work has been done in the context of 
IEPREP/SIP) on resource priority headers and I do have the impression 
that there is a big deployment problem. The IESG had no interest to let 
IEPREP to proceed but ironically the real world happened elsewhere 
anyway, namely SIP and TSVWG.

To some extend this is a more generic discussion for the IETF. Do we 
want to develop architectures or just some building blocks and let other 
folks figure out how to use it in a reasonable way?

If we were to cover authority-to-authority emergency services as part of 
the emergency services workshops and invite the respective players then 
I could imagine that we will not find too many folks that plan to use 
path-coupled signaling (particularly not when used with the end host). 
Instead, I believe that they will only want to make use of it as part of 
an IMS architecture and hence they would want to use the PCC framework.

Obviously this is quite challenging: Start with the building blocks and 
then later develop the architecture (maybe let other SDOs do the 
architecture instead of the IETF) vs. have an architecture in mind and 
then develop the building blocks. (Sometimes a few building blocks are 
useful in various architectures.)

I don't want to be the roadblock here (and I do get the impression that 
nearly everyone does not have a lot of opinion regarding the work) but I 
would like to understand what you were thinking when you did the work. 
Maybe you just wrote something that sounded nice but maybe you had a 
useful architecture in mind but you just did not write it down anywhere. 
Even with the "new" resource priority header work in SIP one can observe 
the conflict between the architectural preference some folks in the IETF 
have and the communication architecture preferred by other SDOs. 
Security is a classical example where these "tussels" become visible.

Ciao
Hannes

DRAGE, Keith (Keith) wrote:
> Slightly tongue in cheek, but the point is real.
>
> Hannes, 
>
> Perhaps you should also be clarifying in all the drafts produced by
> ECRIT that the communication is citizen to authority, as exactly the
> same confusion of terminology appears there.
>
> I understand the taxonomy of emergency calls is generally subdivided as
> follows:
>
> -	citizen to authority
> -	authority to authority
> -	authority to citizen
>
> All of these can be referred to emergency calls.
>
> Regards
>
> Keith 
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> On Behalf Of James M. Polk
>> Sent: Tuesday, April 29, 2008 4:03 PM
>> To: [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [Ecrit] [Tsvwg] Emergency Services work in TSVWG
>>
>> At 03:49 AM 4/29/2008, [email-masked] wrote:
>>     
>>> Hi Ken,
>>>
>>> I would be very happy if you could state explicitly that you want to 
>>> use the mechanisms in that document for 
>>>       
>> authority-to-authority type of 
>>     
>>> emergency services rather than for other types of emergency services.
>>>       
>> The abstract starts with
>>
>>          "An Emergency Telecommunications Service (ETS)..."
>> which means a GETS type of service, which clearly isn't C2A 
>> based, as evidenced by the references within the opening 
>> sentence of the Intro
>>
>>          "[RFC3689] and
>> [<http://tools.ietf.org/html/./rfc3690>RFC3690] detail 
>> requirements for
>>          an Emergency Telecommunications Service (ETS)..."
>>
>>
>>     
>>> For citizien-to-authority I definitely see a lot of problems and
>>> regarding early warning (authority-to-citizen) we haven't 
>>>       
>> even worked on
>>     
>>> the architecture and therefore it is very hard to tell how 
>>>       
>> it would be
>>     
>>> used -- we will see in the future.
>>>
>>> Ciao
>>> Hannes
>>>
>>>       
>>>> -----Original Message-----
>>>> From: ext ken carlberg [mailto:[email-masked]]
>>>> Sent: 28 April, 2008 15:20
>>>> To: Tschofenig Hannes (NSN - FI/Espoo)
>>>> Cc: [email-masked]; [email-masked]
>>>> Subject: Re: [Tsvwg] Emergency Services work in TSVWG
>>>>
>>>> whoa, slow down a bit!
>>>>
>>>> On Apr 28, 2008, at 6:47 AM, <[email-masked]> wrote:
>>>>         
>>>>> Hi all,
>>>>>
>>>>> In a review of draft-ietf-tsvwg-emergency-rsvp-07.txt I got the
>>>>> impression that the document is not only used for authority-to-
>>>>> authority communication but also for citizen-to-authority
>>>>> communication.
>>>>>
>>>>> Here is my review comment:
>>>>> "
>>>>>      * I think the document needs to indicate clearly that
>>>>>           
>>>> this mechanism
>>>>         
>>>>> is supposed to be used for authority-to-authority 
>>>>>           
>> emergency services
>>     
>>>>> and not for citizen-to-authority/authority-to-citizen
>>>>> emergency
>>>>> services.
>>>>> "
>>>>>
>>>>> As a response I received:
>>>>>
>>>>> "
>>>>> I would disagree.  What you are asking for would be best 
>>>>>           
>> placed in a
>>     
>>>>> separate applicability draft.   For instance, while I 
>>>>>           
>> mostly agree
>>     
>>>>> with
>>>>> your above assertion, I can also envision an exception in
>>>>>           
>>>> the case of
>>>>         
>>>>> Japan's 911-like service, where preferential treatment is
>>>>>           
>>>> supported in
>>>>         
>>>>> their PSTN for these types of many-to-1 call flows.  Hence, more
>>>>> elaborate discussions on use cases and applicability is 
>>>>>           
>> really best
>>     
>>>>> served in a different document.
>>>>> "
>>>>>
>>>>> Now, I wonder whether the ECRIT WG is aware of the desire of some
>>>>> folks in TSVWG to have these types of QoS mechanisms to go into
>>>>> citizen-to-authority emergency services architecture? We are
>>>>>           
>>>> currently
>>>>         
>>>>> finishing our architecture document and this document 
>>>>>           
>> seems to touch
>>     
>>>>> that space without being explicit.
>>>>>           
>>>> Please *carefully* note that in my response on the tsvwg list
>>>> I said "...I can also envision..."
>>>>
>>>>                                                 ^ ^^ in no
>>>> way did I state any desire or advocacy, one way or the other,
>>>> to see the proposed extension used for citizen-to-authority
>>>> emergency services.  I'm agnostic in that regard, and I want
>>>> the cited tsvwg
>>>> draft to remain that way.   And as I also stated above, its up to
>>>> another document outside of the cited tsvwg draft to discuss
>>>> its applicability -- in the context of this note, that would
>>>> be the ECRIT architecture draft.
>>>>
>>>> if pressed on the matter, I would initially advocate a
>>>> position that the draft-ietf-tsvwg-emergency-rsvp-07.txt  MAY
>>>> be used for citizen- to-authority emergency services.  But I
>>>> haven't followed ECRIT very closely of late, so I'll certainly
>>>> defer to the consensus of others actively participating in the
>>>> ECRIT architecture document.
>>>>
>>>> cheers,
>>>>
>>>> -ken
>>>>
>>>>
>>>>         
>> _______________________________________________
>> Ecrit mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
>>
>>     
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>   

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit