[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again)
Agree with Brian.
I certainly would not want to preclude the usage in a public network, and I believe the RFC has all the words needed to cover the interoperation with the Emergency services IP network.
regards
Keith
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf Of Brian Rosen
> Sent: Monday, January 05, 2009 3:56 PM
> To: 'Hannes Tschofenig'; 'ECRIT'
> Subject: Re: [Ecrit]
> draft-ietf-ecrit-local-emergency-rph-namespace-00.txt: Scope (again)
>
> 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/iet
> f67ch4-tue-noo
> n.mp3
> http://limestone.uoregon.edu/ftp/pub/videolab/video/ietf70/iet
> f70-ch1-tue-af
> noon-ecrit-dime-avt.mp3
> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf72/iet
> f72-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.ht
> ml 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
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit