(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