Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness?

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

I have read the document and I still have a hard time understanding the
value of the work. 

There is no need to mark emergency calls beyond the marking we have with
the Service URN document 
Calls between PSAPs  and from a PSAP to a first responder the Service
URN is not used. You could, if you think it is useful, use the existing
Resource Priority header there. 

So, why do we need this? 

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

---

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

You should mark a call appropriate to the functions it need to perform.

If you want an emergency call to pass through special queues or whatever
in SIP entities, then it should be marked with the appropriate header
for doing that, which is the Resource-Priority header. Some
administrations want to do this with emergency calls.

This would seem to be entirely consistent with the views put forward in
draft-ietf-sipping-service-identification, for example, whereas your one
indicator does everything, does not.

regards

Keith 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Tuesday, November 18, 2008 8:30 PM
> To: ECRIT
> Subject: [Ecrit] 
> draft-ietf-ecrit-local-emergency-rph-namespace --Usefulness?
> 
> I have read the document and I still have a hard time 
> understanding the value of the work. 
> 
> There is no need to mark emergency calls beyond the marking 
> we have with the Service URN document Calls between PSAPs  
> and from a PSAP to a first responder the Service URN is not 
> used. You could, if you think it is useful, use the existing

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 18 Nov 2008 16:00:05 -0500

Which "existing Resource Priority header" are you proposing to use? 

The dsn, and drsn namespaces are not intended for use outside the US DoD 
networks, and only provide (preemption based) priority over calls with the 
same namespace, but a different value. 

The q735 namespace, while not restricted to the US DoD is similarly based 
on a "closed group preemption", which is not appropriate to this 
situation.

The ets and wps namespaces are intended for the "Next Generation" versions 
of Government Emergency Telecommunications Service (GETS) and Wireless 
Priority Service (WPS).  Both of these are intended to support National 
Security and Emergency Preparedness, and explicitly exclude "911-type" 
calls.

As I noted earlier, I have some real concerns about some of the text in 
this ID.  But I support the concept of an RPH namespace for ecrit-related 
calls/sessions.

Janet

---

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

There is only one Resource-Priority header field, that defined in RFC
4412.
 
Different handling is determined by the namespace within the header.
 
The requirements for handling emergency calls in terms of priority are
different from any other existing namespace, so it needs a new
namespace.
 
That is a "priority" namespace rather than a "preemption" one.
 
Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Janet P Gunn
	Sent: Tuesday, November 18, 2008 9:00 PM
	To: Tschofenig, Hannes (NSN - FI/Espoo)
	Cc: ECRIT; [email-masked]
	Subject: Re: [Ecrit]
draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness?

	
	Which "existing Resource Priority header" are you proposing to
use?   
	
	The dsn, and drsn namespaces are not intended for use outside
the US DoD networks, and only provide (preemption based) priority over
calls with the same namespace, but a different value. 
	
	The q735 namespace, while not restricted to the US DoD is
similarly based on a "closed group preemption", which is not appropriate
to this situation. 
	
	The ets and wps namespaces are intended for the "Next
Generation" versions of Government Emergency Telecommunications Service
(GETS) and Wireless Priority Service (WPS).  Both of these are intended
to support National Security and Emergency Preparedness, and explicitly
exclude "911-type" calls. 
	
	As I noted earlier, I have some real concerns about some of the
text in this ID.  But I support the concept of an RPH namespace for
ecrit-related calls/sessions. 
	
	Janet 

	> I have read the document and I still have a hard time
understanding the

---

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

If it has a totally different meaning does it make sense to put it in
the RPH namespace? 

	From: ext DRAGE, Keith (Keith) [mailto:[email-masked]]

	Sent: 18 November, 2008 23:30
	To: Janet P Gunn; Tschofenig, Hannes (NSN - FI/Espoo)
	Cc: ECRIT; [email-masked]
	Subject: RE: [Ecrit]
draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness?

	There is only one Resource-Priority header field, that defined
in RFC 4412.
	 
	Different handling is determined by the namespace within the
header.
	 
	The requirements for handling emergency calls in terms of
priority are different from any other existing namespace, so it needs a
new namespace.

	Keith

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Janet P Gunn
		Sent: Tuesday, November 18, 2008 9:00 PM
		To: Tschofenig, Hannes (NSN - FI/Espoo)
		Cc: ECRIT; [email-masked]
		Subject: Re: [Ecrit]
draft-ietf-ecrit-local-emergency-rph-namespace-- Usefulness?

		
		Which "existing Resource Priority header" are you
proposing to use?   
		
		The dsn, and drsn namespaces are not intended for use
outside the US DoD networks, and only provide (preemption based)
priority over calls with the same namespace, but a different value. 
		
		The q735 namespace, while not restricted to the US DoD
is similarly based on a "closed group preemption", which is not
appropriate to this situation. 

		As I noted earlier, I have some real concerns about some
of the text in this ID.  But I support the concept of an RPH namespace
for ecrit-related calls/sessions. 
		
		Janet 

understanding the

---

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

I wonder why the specific usage has been tied into the RPH usage. 
After all, they are just tokens and in the US DoD networks they would
have defined their special meaning for them. 

	From: ext Janet P Gunn [mailto:[email-masked]] 
	Sent: 18 November, 2008 23:00
	To: Tschofenig, Hannes (NSN - FI/Espoo)
	Cc: ECRIT; [email-masked]
	Subject: Re: [Ecrit]
draft-ietf-ecrit-local-emergency-rph-namespace -- Usefulness?

	

	

	Janet 

understanding the

---

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

The Resource-Priority header was defined to have multiple namespaces.
You define your prioritisation requirements by defining the namespace,
i.e. it is a name of your template.

So yes, it makes absolute sense to use the Resource-Priority header for
exactly the functions for which it was defined.

regards

Keith 

> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: Tuesday, November 18, 2008 9:31 PM
> To: DRAGE, Keith (Keith); Janet P Gunn
> If it has a totally different meaning does it make sense to 
> put it in the RPH namespace? 
>  
> 
> 
> 	There is only one Resource-Priority header field, that 
> defined in RFC 4412.
> 	 
> 	The requirements for handling emergency calls in terms 
> of priority are different from any other existing namespace, 
> so it needs a new namespace.
> 	 
> 		The dsn, and drsn namespaces are not intended 
> for use outside the US DoD networks, and only provide 
> (preemption based) priority over calls with the same 
> namespace, but a different value. 
> 		
> 		The q735 namespace, while not restricted to the 
> US DoD is similarly based on a "closed group preemption", 
> which is not appropriate to this situation. 
> 		
> 		The ets and wps namespaces are intended for the 
> "Next Generation" versions of Government Emergency 
> Telecommunications Service
> (GETS) and Wireless Priority Service (WPS).  Both of these 
> are intended to support National Security and Emergency 
> Preparedness, and explicitly exclude "911-type" calls. 
> 		
> 		As I noted earlier, I have some real concerns 
> about some of the text in this ID.  But I support the concept 
> of an RPH namespace for ecrit-related calls/sessions. 
> 		
> 		Janet 
>

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 18 Nov 2008 16:51:14 -0500

Yes that is what I meant.  Use the same HEADER, but need  a new NAMESPACE.

Janet

"DRAGE, Keith \(Keith\)" <[email-masked]> wrote on 11/18/2008 

4412.
> The requirements for handling emergency calls in terms of priority 
> are different from any other existing namespace, so it needs a new 
namespace.
> From: [email-masked] [mailto:[email-masked]] On Behalf 
Of 
> Janet P Gunn
> Subject: Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-
> namespace-- Usefulness?

> The dsn, and drsn namespaces are not intended for use outside the US
> DoD networks, and only provide (preemption based) priority over 
> The q735 namespace, while not restricted to the US DoD is similarly 
> based on a "closed group preemption", which is not appropriate to 
> this situation. 
> 
> The ets and wps namespaces are intended for the "Next Generation" 
> versions of Government Emergency Telecommunications Service (GETS) 
> and Wireless Priority Service (WPS).  Both of these are intended to 
> support National Security and Emergency Preparedness, and explicitly
> As I noted earlier, I have some real concerns about some of the text
> in this ID.  But I support the concept of an RPH namespace for

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 18 Nov 2008 17:07:20 -0500

It is entirely possible that a "DoD" call could originate on one DoD 
network, and terminate on another DoD network, but traverse a non-DOD 
network in between.

The "DoD-related" namespace needs to be preserved, but ignored, by the 
traversed networks. I would be acted on only by the originating and 
terminating DoD networks.  This would not be possible if the intervening 
network were using the same namespace for a completely different purpose.

This behavior IS spelled out in 4412.

Janet

"Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]> wrote on

---

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

So, you believe that folks are going to use this to mark calls from
PSAPs to first responders?
>From a PSAP to a PSAP (in case of call forwarding) one could still use
the Service URN?

>Sent: 18 November, 2008 23:42
>To: Tschofenig, Hannes (NSN - FI/Espoo); Janet P Gunn
>You define your prioritisation requirements by defining the 
>namespace, i.e. it is a name of your template.
>
>So yes, it makes absolute sense to use the Resource-Priority 
>header for exactly the functions for which it was defined.
>
>regards
>
>Keith 
>
>defined in RFC 
>of priority 
>for use outside the US 
>> DoD networks, and only provide (preemption based) priority 
>over calls 
>> with the same namespace, but a different value.
>> 		
>US DoD is similarly 
>> based on a "closed group preemption", which is not 
>appropriate to this 
>> situation.
>> 		
>"Next Generation" 
>> versions of Government Emergency Telecommunications Service
>> (GETS) and Wireless Priority Service (WPS).  Both of these are 
>> intended to support National Security and Emergency 
>Preparedness, and 
>about some of the text 
>> 		> There is no need to mark emergency calls 
>beyond the marking we 
>> have with
>> 		> the Service URN document 
>> 		> Calls between PSAPs  and from a PSAP to a 
>first responder the 
>> Service
>> 		> URN is not used. You could, if you think it 
>is useful, use the 
>> existing

---

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

>I have read the document and I still have a hard time understanding the

Is this comment said with your WG chair hat on or as an individual contributor?

>the Service URN document.

So, do you want SIP entities to use another resource mechanism ONLY 
WHEN AN EMERGENCY CALL IS MADE, or do you want SIP to only use one 
mechanism, which is defined by RFC 4412, and updated with this ID's namespace?

>Resource Priority header there.

Hannes - the existing Resource Priority header spec (RFC 4412) does 
*not* define a namespace for emergency services. This ID defines 
*the* new namespace for use within emergency calling. It doesn't 
exist anywhere else.

>So, why do we need this?

see the paragraph above for the why.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 18 Nov 2008 17:03:41 -0600

Hannes

You really are comparing apples to oranges (or boats), *and* you are 
adding mechanisms that are needed to be coded for, instead of 
reducing the number of mechanisms that need to be accounted for.

James