Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 18 Nov 2008 22:29:48 +0200

I have reviewed this document and I believe the scope has changed to
what we agreed in previous ECRIT meetings. 

I believe that the document must not provide mechanisms for 
* PSAP callbacks 
* end hosts attaching a marking

I believe that the document should only talk about how to use this
marking inside an emergency services network. 
Other mechanisms are overlapping with other techniques and raise
security issues. 

Ciao
Hannes

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Nov 2008 17:01:58 -0500

I don't see a problem here.  

I think it's perfectly reasonable for an endpoint or proxy outside an
emergency services IP network to mark a call needing resource priority.  The
policing and behavior of proxy servers or UASs in the presence of such a
marking is beyond the scope, but limiting the marking to emergency services
networks is unwarranted.

Further, differentiating between an incoming emergency call and a call back
seems wise.  It may be the case that there is minimal if any resource
priority for such calls in some networks, where in others, it may be that
there is some explicit priority of incoming vs outgoing.  

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Tuesday, November 18, 2008 3:30 PM
To: ECRIT
Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope
incorrect

Ciao
Hannes

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 18 Nov 2008 23:07:18 +0100

Brian is correct.

But I was under the impression that people wanted to do the callback
stuff later. So I do envisage the current proposal only for the citizen
to authority emergency call.

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Tuesday, November 18, 2008 10:02 PM
> To: 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ECRIT'
> Subject: Re: [Ecrit] 
> draft-ietf-ecrit-local-emergency-rph-namespace --Scope incorrect
> 
> I think it's perfectly reasonable for an endpoint or proxy 
> outside an emergency services IP network to mark a call 
> needing resource priority.  The policing and behavior of 
> proxy servers or UASs in the presence of such a marking is 
> beyond the scope, but limiting the marking to emergency 
> services networks is unwarranted.
> 
> Further, differentiating between an incoming emergency call 
> and a call back seems wise.  It may be the case that there is 
> minimal if any resource priority for such calls in some 
> networks, where in others, it may be that there is some 
> explicit priority of incoming vs outgoing.  
> 
> Brian
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Subject: [Ecrit] 
> draft-ietf-ecrit-local-emergency-rph-namespace -- Scope incorrect
> 
> I have reviewed this document and I believe the scope has 
> changed to what we agreed in previous ECRIT meetings. 
> 
> I believe that the document should only talk about how to use 
> this marking inside an emergency services network. 
> Other mechanisms are overlapping with other techniques and 
> raise security issues. 
> 
> Ciao
> Hannes
> 
>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 19 Nov 2008 00:10:28 +0200

>needing resource priority.  The policing and behavior of proxy 
>servers or UASs in the presence of such a marking is beyond 
>the scope, but limiting the marking to emergency services 
>networks is unwarranted.

The problem with this approach is that you have TWO (2) different ways
to mark an emergency call == NOT GOOD

>and a call back seems wise.

BUT: We have an alternative way to mark a call from a PSAP towards the
UA. 

>It may be the case that there is

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 19 Nov 2008 00:14:07 +0200

There is a proposal for making a call back in 
http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt

When we set the scope for
draft-ietf-ecrit-local-emergency-rph-namespace there was no mentioning
of a call-back mechanism. 

The group seemed to be OK about using this inside the emergency services
infrastructure but there was critique when used outside. 

Ciao
Hannes

>From: ext DRAGE, Keith (Keith) [mailto:[email-masked]] 
>Sent: 19 November, 2008 00:07
>To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
>Subject: RE: [Ecrit] 
>But I was under the impression that people wanted to do the 
>callback stuff later. So I do envisage the current proposal 
>only for the citizen to authority emergency call.
>
>Keith 
>
>On Behalf 
>> Of Brian Rosen
>outside an 
>> emergency services IP network to mark a call needing resource 
>> priority.  The policing and behavior of proxy servers or UASs in the 
>> presence of such a marking is beyond the scope, but limiting the 
>> marking to emergency services networks is unwarranted.
>> 
>and a call 
>> back seems wise.  It may be the case that there is minimal if any 
>> resource priority for such calls in some networks, where in 
>others, it 
>> may be that there is some explicit priority of incoming vs outgoing.
>> 
>> Brian
>>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 18 Nov 2008 23:16:10 +0100

Incorrect.

You have a way of marking that you want an emergency call to be given
particular priority. You have a way of marking that you want an
emergency call to be sent to a PSAP. etc.

What you are hinting at is that you believe emergency calls behave
entirely according to a single indicator, which defines a profile of
characteristics that is followed by entity in the path from sender to
destination. That in my view is a declaritive service definition in my
understanding of 

http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-identific
ation-03.txt

and therefore entirely the wrong way to go.

Keith

> Sent: Tuesday, November 18, 2008 10:10 PM
> To: ext Brian Rosen; ECRIT
> Subject: Re: [Ecrit] 
> >emergency services IP network to mark a call needing 
> resource priority.  
> >The policing and behavior of proxy servers or UASs in the 
> presence of 
> >such a marking is beyond the scope, but limiting the marking to 
> >emergency services networks is unwarranted.
> 
> The problem with this approach is that you have TWO (2) 
> different ways to mark an emergency call == NOT GOOD
>  
> 
> 
> 
> >
> >back seems wise.
> BUT: We have an alternative way to mark a call from a PSAP 
> towards the UA. 
> 
> 
> 
> networks, where 
> >in others, it may be that there is some explicit priority of 
> incoming 
> >vs outgoing.
> >
> >Brian
> >
> >Of Tschofenig, Hannes (NSN - FI/Espoo)

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Nov 2008 17:14:47 -0500

If indeed a ecrit us chartered to do call backs, and this draft goes
forward, I would have no problem in having this draft define the namespace
(and thus a registry for values in that namespace), and then having the call
back work add a new value in the registry, thus removing the call back value
from this document.

Brian

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Tuesday, November 18, 2008 5:07 PM
To: Brian Rosen; Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope
incorrect

Brian is correct.

Keith

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Nov 2008 17:17:56 -0500

The service URN is a ROUTING marking
The RPH is a (SIP) RESOURCE marking

They do different things.  It may even make sense to have one marking
without the other in some circumstances, although the generic 1-1-2 type
emergency call would likely have both.

Brian

-----Original Message-----
From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]

Sent: Tuesday, November 18, 2008 5:10 PM
To: ext Brian Rosen; ECRIT
Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope
incorrect

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 19 Nov 2008 00:37:29 +0200

They are different only on a philosophical sense. 

A SIP UA should not have to implement two mechanisms for such a
philosophical difference. 

The RPH marking can also be used to influence routing decisions (like
anything can be used todo that)

>They do different things.  It may even make sense to have one 
>marking without the other in some circumstances, although the 
>generic 1-1-2 type emergency call would likely have both.
>
>Brian
>
>priority.  
>>The policing and behavior of proxy servers or UASs in the presence of 
>>in others, it may be that there is some explicit priority of incoming 
>>vs outgoing.
>>
>>Brian
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 19 Nov 2008 00:39:17 +0200

What do you think about the approach taken in
http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt with
regard to a call back procedure? 

>From: ext Brian Rosen [mailto:[email-masked]] 
>Sent: 19 November, 2008 00:15
>To: 'DRAGE, Keith (Keith)'; Tschofenig, Hannes (NSN - 
>FI/Espoo); 'ECRIT'
>Subject: RE: [Ecrit] 
>If indeed a ecrit us chartered to do call backs, and this 
>draft goes forward, I would have no problem in having this 
>draft define the namespace (and thus a registry for values in 
>that namespace), and then having the call back work add a new 
>value in the registry, thus removing the call back value from 
>this document.
>
>Brian
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Nov 2008 16:46:25 -0600

>marking inside an emergency services network.

Hannes - is all this said with your WG chair hat on, or as an 
individual contributor?

>Other mechanisms are overlapping with other techniques and raise

what other overlapping mechanisms exist within SIP?

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Nov 2008 17:53:37 -0500

Could I ask if there are others on the list who have the same objections
that Hannes has?  We have gone around this loop several times.  

Brian

-----Original Message-----

Sent: Tuesday, November 18, 2008 5:37 PM
To: ext Brian Rosen; ECRIT
Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Scope
incorrect

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Nov 2008 18:03:43 -0500

The whole subject needs a requirements doc and a mechanism.  I don't think
this is going to be the right mechanism, but we'll see.  

Charter
Then Requirements
Then mechanism

Right, Mr. Co-Chair?

Brian

-----Original Message-----

Sent: Tuesday, November 18, 2008 5:39 PM
To: ext Brian Rosen; DRAGE, Keith (Keith); ECRIT
Subject: RE: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace --Scope
incorrect

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 11:03:28 -0600

>to mark an emergency call == NOT GOOD

no no no.... you are suggesting using TWO mechanisms to accomplish 
resource priority ==> which is NOT GOOD.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 11:07:10 -0600

>infrastructure but there was critique when used outside.

To be accurate, there was critique when the UAC (i.e., the phone) 
*set* the Resource-Priority header - yes. There  are SPs that want to 
have the ability to have a relationship with PSAPs in such a way to 
have the SPs do the Resource-Priority header insertion.

the document is currently consistent with this view.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 19 Nov 2008 11:10:41 -0600

At 04:37 PM 11/18/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>A SIP UA should not have to

Hannes - the existing document *never* says a UA has to implement 
anything at all. The doc doesn't even suggest a UA SHOULD implement 
anything at all.

I think you are confusing things.

>implement two mechanisms for such a