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

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 4 Jan 2009 00:57:16 +0200

(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
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 04 Jan 2009 16:21:45 -0600

Hannes

Thanks for summarizing.

draft-ietf-ecrit-local-emergency-rph-namespace-00 currently says scenario:

(a) is "can be used" in Figure 1 and "MAY be included" in text.
(b) is "can be used" in Figure 1 and "MAY be included" in text.
(c) is to be used (when supporting this doc) in both Figure 1 and the text.
(d) is "MAY be included" in text of section 3.

For (a), Section 2 goes on to say that use of this namespace from 
UACs is likely untrustworthy, unless the UAC is directly attached to 
an IP managed network (such as IMS).

I don't really need to remind you that MAYs (in PS RFCs) are for 
implementers, not configurers. These mean that a future RFC MAY make 
any MAY into a MUST, SHOULD, MUST NOT or SHOULD NOT.

The reason I still have "can be used" in Figure 1 and "MAY be 
included" in text is that to omit these is to implicitly forbid its 
use in a), b) and d) -- which, after IETF#67, I was asked explicitly 
not to do this for (b) - which you note below (in IMS).

I'm willing to change the text around scenario (a) to something like 
"...it is NOT RECOMMENDED (or SHOULD NOT be used), but a 
specification in the future MAY recommend or mandate the usage of 
this namespace...".

Reality applies here too, given that I do not believe any ESInet will 
interconnect to any public network without an SBC (or B2BUA), thus 
any RP namespace received by this SBC will likely be ignored and not 
passed on to the ESInet's interior elements.

I'm equally open to changing scenario (d) to say the same thing as I 
offered to write about (a).

Either MAY being changed to SHOULD or MUST would (most) likely be 
based on implementation experience.

What do you think about both these suggestions?

James

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 5 Jan 2009 10:56:25 -0500

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: [email-masked] [mailto:[email-masked]] 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)

Hi all, 

  (a) UA to VSP

 -- IETF#67

 -- IETF#70

 -- IETF#72

Ciao
Hannes

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 5 Jan 2009 20:17:23 +0100

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 

> From: [email-masked] [mailto:[email-masked]] 
> 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.
> 
> 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
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig
> Subject: [Ecrit] 
> draft-ietf-ecrit-local-emergency-rph-namespace-00.txt:
> Scope (again)
> 
> An essentially issue, as it appears in the entire discussion, 
> is the question of applicability -- where should this SOS RPH 
> mechanism be used.
> 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).
> 
> 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: 
> 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. 
>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 5 Jan 2009 15:04:07 -0500

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

[email-masked] 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 
>