Subject: [Ecrit] Comment on draft-ietf-ecrit-unauthenticated-access

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 14 Jan 2011 15:55:14 -0500

In  Section 5, step 2, this document says that the ISP informs the calling device about its local ESRP via DHCP.  This seems incorrect, not least because there is no DHCP option defined to carry this sort of information.  

It seems to me that in order to minimize the divergence from the normal procedure, step 2 should have the network providing the client access to location (HELD/DHCP-location) and LoST servers, then connecting to the ESRP.

--Richard

---

From: Brian Rosen <[email-masked]>
Date: Fri, 14 Jan 2011 16:05:56 -0500

Yes, that is wrong.

I think your proposed solution is correct.

Brian

On Jan 14, 2011, at 3:55 PM, Richard L. Barnes wrote:

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 14 Jan 2011 17:23:27 -0600

>I think your proposed solution is correct.

I agree

James

> > In  Section 5, step 2, this document says that the ISP informs 
> the calling device about its local ESRP via DHCP.  This seems 
> incorrect, not least because there is no DHCP option defined to 
> carry this sort of information.
> >
> > It seems to me that in order to minimize the divergence from the 
> normal procedure, step 2 should have the network providing the 
> client access to location (HELD/DHCP-location) and LoST servers, 
> then connecting to the ESRP.
> >
> > --Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 15 Jan 2011 11:13:58 +0200

Hey Richard, 

you raise a very good point and this is definitely something we should a discussion about. 

There are two options for providing this functionality:

1) As you suggested to use the procedure in Phone BCP

This essentially requires the following statements:
"
The emergency client MUST support location acquisition and the LCPs described in Section 6.5 of [I-D.ietf-ecrit-phonebcp].  The description in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the interaction between the device and the LIS applies to this document. The emergency client MUST use LoST [RFC5222] to obtain an ESRP URI.
"

Particularly the usage of RFC 5223 (DHCP option for discovering LoST servers) in this discovery step. 

2) The second variant, the DHCP-based SIP Proxy discovery mechanism is used. This SIP proxy will take on the role of a ESRP.  
This is what the current document says. 

Ciao
Hannes

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 16 Jan 2011 21:53:28 -0500

It doesn't seem helpful to have a whole separate calling procedure at the application layer, just because the mechanism for layer-2/3 access is different.  So I think whatever the solution is to be, it should be consistent between this document and phonebcp.  

There are at least a few arguments for this common method to be the current LCP/LoST method instead of this novel DHCP-based method.

1. Long-standing consensus around phonebcp, and no clear reason to change.  

2. In addition to the client-side requirements, the DHCP method adds several requirements for network operators.  Given that there is already some resistance by network operators to deploying phonebcp, this does not seem like a decision that is likely to promote deployment.

3. Pinning the solution to SIP unnecessarily constrains the set of protocols that the caller can use to communicate with the PSAP.  This should be up to the network operator's policy, not decided by the technology.  At best, you could put PSAP contact URIs in DHCP, but you would need to define a new option.

4. DHCP server service areas don't necessarily align well with PSAP service areas or LCP service areas, which can make the job of the ESRP tricky.  For example, it might be necessary for the ESRP to discover which location server it needs to draw from.

--Richard

---

From: Brian Rosen <[email-masked]>
Date: Sat, 15 Jan 2011 16:22:35 -0500

The SIP proxy cannot take the role of an ESRP.  

It could do the LoST processing on behalf of the client, but the client would have to obtain location and pass it on.  It seems unreasonable to me to expect the client to know enough about emergency calling to add location, and not enough to handle the LoST query.  It is unreasonable to expect that the proxy could always know location.  If you want to make that a requirement, I think you limit the applicability.

Since I don't like unauthenticated access at all, it's fine with me to limit applicability :)

However the document has to say that.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 17 Jan 2011 13:08:00 +0800

I have to agree with Richard here.

There's an argument to be made for a dumb enterprise phone to delegate these sorts of functions to a proxy, but this is really the opposite scenario.  I can't see why you would need a separate procedure.

--Martin

On 2011-01-17 at 13:53:28, Richard L. Barnes wrote:
> It doesn't seem helpful to have a whole separate calling procedure at
> the application layer, just because the mechanism for layer-2/3 access
> is different.  So I think whatever the solution is to be, it should be
> consistent between this document and phonebcp.
> 
> There are at least a few arguments for this common method to be the
> current LCP/LoST method instead of this novel DHCP-based method.
> 
> 2. In addition to the client-side requirements, the DHCP method adds
> several requirements for network operators.  Given that there is
> already some resistance by network operators to deploying phonebcp,
> this does not seem like a decision that is likely to promote
> deployment.
> 
> 3. Pinning the solution to SIP unnecessarily constrains the set of
> protocols that the caller can use to communicate with the PSAP.  This
> should be up to the network operator's policy, not decided by the
> technology.  At best, you could put PSAP contact URIs in DHCP, but you
> would need to define a new option.
> 
> 4. DHCP server service areas don't necessarily align well with PSAP
> service areas or LCP service areas, which can make the job of the ESRP
> tricky.  For example, it might be necessary for the ESRP to discover
> which location server it needs to draw from.
> 
> --Richard
> 
> 
> 
> 
> > The emergency client MUST support location acquisition and the LCPs
> described in Section 6.5 of [I-D.ietf-ecrit-phonebcp].  The description
> in Section 6.5 and 6.6 of [I-D.ietf-ecrit-phonebcp] regarding the
> interaction between the device and the LIS applies to this document.
> The emergency client MUST use LoST [RFC5222] to obtain an ESRP URI.
> > "
> >
> > 2) The second variant, the DHCP-based SIP Proxy discovery mechanism
> is used. This SIP proxy will take on the role of a ESRP.
> >> In  Section 5, step 2, this document says that the ISP informs the
> calling device about its local ESRP via DHCP.  This seems incorrect,
> not least because there is no DHCP option defined to carry this sort of
> information.
> >>
> normal procedure, step 2 should have the network providing the client
> access to location (HELD/DHCP-location) and LoST servers, then
> connecting to the ESRP.
> >>
> >> --Richard