[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)
I also agree. There is quite a lot of text in 4412 about "passing"
RPH (without providing any special behavior) across a network that
"doesn't understand" that namespace to/from a network that does
understand/provide special behavior to that namespace. Perhaps that
could be stressed a bit more in the text of this ID. This ID does
not need to go into detail about which networks are expected to "understand"
and which to "ignore" the namespace.
Janet
ecrit-bounces at ietf.org wrote on 01/05/2009 02:17:23
PM:
> 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
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit