Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again)

["Brian Rosen" <br at brianrosen.net>]

There is very little downside to allowing the marking to be used in any
network.  It's the behaviors that are implied by the marking that you care
about.  In a public network, there may not be any behaviors associated with
the marking, while in an Emergency Services IP Network, there most certainly
will be.

The document in question doesn't really address behavior, and it shouldn't.
NENA would specify behaviors within the networks it standardizes, and is in
a much better position to do that.  What we need is a namespace.

You can qualify it if you want: "MAY" is good enough in the origination
network and the interconnect between the origination network and the
Emergency Services IP network.  I don't want to see it prohibited.  I think
it IS a good idea to give emergency calls signaling priority in both the UA
to proxy and proxy to ESInet legs.  However, whether those networks do that
is up to them.  It's certainly not wrong for the UAC to ask for priority.

Brian



-----Original Message-----
From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf Of
Hannes Tschofenig
Sent: Saturday, January 03, 2009 5:57 PM
To: 'ECRIT'
Subject: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt:
Scope (again)

(this time with my co-chair hat on)

Hi all, 

I reviewed the past presentations of RPH from IETF#72, IETF#70, and IETF#67.
You can listen into the audio recording yourself -- quite interesting. 
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch4-tue-noo
n.mp3
http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/ietf70-ch1-tue-af
noon-ecrit-dime-avt.mp3
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/ietf72-ch6-tue-no
on.mp3

An essentially issue, as it appears in the entire discussion, is the
question of applicability -- where should this SOS RPH mechanism be used.
There are at the following possible cases: 

  (a) UA to VSP
  (b) VSP to PSAP (potentially via another VSP)
  (c) Within the emergency services network (including PSAP to first
responders)
  (d) PSAP callback  

I briefly summarize the feedback the group got at those meetings: 

 -- IETF#67

A lot of the discussion focus on the name of the namespace, i.e. a syntactic
issue. 
Jonathan, Henning, and Ted argue that the usage of RPH particularly for
scenario (a) is not a good idea. 

Janet, James, and Brian like the idea of using RPH for use case (a), (b),
and (c). (I am not sure about everyone's position regarding (d)). 

Brian Stucker believes that RPH is OK for usage for scenario (d). He argues
that the authorization problem is simpler to solve with that scenario. 

 -- IETF#70

Keith, James and Brian like the document. Brian, for example, says that it
is very useful within an IP public safety communication network, i.e.,
scenario (c). He also thinks that it is useful outside of it in a public
network. 

Jon, Richard, and Henning have concerns regarding the usage of RPH for
things other than scenario (c). Particularly scenario (a) seems to be
problematic. I also voiced my opinion during that meeting against usage of
RPH for scenario (a).

THIS IS IMPORTANT: At the end of the meeting James asks Henning whether he
would be happy with the document if the focus is only on using SOS RPH
within the emergency services network, i.e., scenario (c). Henning says that
this is fine for him as it reassembles much better the intention of RPH.
James promises to update the document to reflect this restricted scope. I
checked subsequent draft versions: No scope change in any form.  

 -- IETF#72

We did not really discuss the document as such. We only asked for a HUM
assuming that folks were aware of the current document version. 


For some reason I must have had the discussions in mind that happened at
IETF#70 where the scope limitation of the draft got discussed. As such, my
mail to the list
http://www.ietf.org/mail-archive/web/ecrit/current/msg05665.html was, I
believe, not completely off topic. 

Although I did not recall who had raised objections in previous meetings
when I wrote my ECRIT WG status update I think that as a WG co-chair it is
fair to hear the opinion of those again that had previously raised concerns.
Maybe they changed their mind and are now in favor of using RPH for scenario
(a). Could be possible. 

Reading through the mail discussions, the drafts and listening to the
meeting recordings helped me again to refresh my memory regarding the
purpose of RPH for scenario (c).

Hope that this was a useful investigation. 

Ciao
Hannes

PS: I also noticed that the justification for the work, as mentioned on the
presentation slides, seems to be  "Brian sez NENA wants it", see: 
http://www.ietf.org/proceedings/07dec/slides/ecrit-2/sld2.htm
http://www.ietf.org/proceedings/06nov/slides/ecrit-7/sld3.htm 

It is good that our work finds excitement in other SDOs and groups. Given
that NENA focuses largely on the emergency services network itself rather
than on the end host to VSP exchanges, I guess it would have been nice to
have a better idea what the detailed requirements are. At the IETF#70
presentation James furthermore mentions that scenario (b) could be useful in
an 3GPP IMS context. I have to check whether there is interest to use RPH
there and for what exactly. 

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit