Subject: [Geopriv] Geopriv L7 LCP: New Requirement: Summary

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Mar 2007 21:45:13 +0200

Hi all,

I went through the mailing list discussion and here is my summary with 
the respect to the impact for the <draft-ietf-geopriv-l7-lcp-ps-00.txt>.

If we would add this new requirement to the draft then the following 
additions are needed:

* Terminology: It might be useful to add LIS-to-LIS (and maybe OBO) 
terminology. The discussions focused mostly on LIS-to-LIS.

* Maybe add an architecture figure that describes the concept. Not 
needed but could be helpful for the reader (I think).

* Requirements: I believe that requirement L7-1 covers the functionality 
already but one might want to be more explicit by saying
   - the request for location information needs to be able to support 
other forms  of  client identifiers than the IP address (typically 
access technology dependent)
   - multiple identifiers may be added to the request

 I couldn't see any other new requirement.

Ciao
Hannes

PS: From a solution point of view I noticed there is the classical 
protocol choice dispute. The SIP functionality is already RFC or very 
close in the progress but some folks favor an HTTP based approach.

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 10 Mar 2007 21:59:53 +0200

Hi Jerome,

[email-masked] wrote:
> I agree with Barbara and would also add : 
>
> - ability to request geo and/or civic location
>   

Barbara previously said that geo-location does not make sense in the DSL 
environment.
I guess you are pointing to a different environment. The question is 
only: Is the LIS-to-LIS communication needed there as well?

> The "ability to specify how quickly a response is needed" would also be really helpful to us.
>   
I don't think that this is useful for this particular application.

> Having a BCP (one or more) that recommends a syntax to express various identifier types for common protocols like SIP/PRES and HTTP would be great!
>
>   
Ciao
Hanes

> Jérôme
>
> -----Message d'origine-----
> De : Stark, Barbara [mailto:[email-masked]] 
> Envoyé : 16 février 2007 10:05
> À : Andrew Newton
> Cc : [email-masked]; Otmar Lendl
> Objet : RE: [Geopriv] Geopriv L7 LCP: New Requirement
>
> I hate to break ranks, but if we could get the user part figured out
> (and I do think we would need some standardization, even if it's just a
> BCP), I kind of like this proposed solution. It has a certain simplicity
> to it.
>
> Since we've been pushing for these LISs to support LbyR, anyway, and
> this is really just LbyR, I don't see it as being a different protocol,
> yet again. This is a protocol we'd expect to be supported by a LIS in
> any case. The only change is that the URI may require careful parsing by
> the queried LIS, and the querier LIS needs to support LbyR queries in
> both directions.
>
> When I look at the functions in HELD (and RELO has a subset of these),
> and think through which of those functions would I really need for
> LIS-LIS or OBO, I come up with:
> - ability to request reference -- not needed, since, as pointed out,
> I've already got a perfectly good non-expiring reference; OBO querier or
> LIS doesn't need to ask for references to hand off to others, it should
> create its own references for that, as appropriate [aside: a
> non-expiring reference and a "LCP" are rather equal in the privacy
> debate from the OBO/LIS-LIS perspective.]
> - ability to assert location -- not needed for OBO or LIS-LIS; only an
> end device should be able to do this, if even that is allowed
> - ability to provide rules/profile for privacy -- not needed for OBO or
> LIS-LIS; only the device should be able to do this
> - ability to sign location -- if this is part of PIDF-LO, then this is
> independent of request mechanism
> - ability to request that location be signed -- I think we can assume
> that the location should be signed if it can be signed
> - ability to specify how quickly a response is needed -- this would be
> useful, but it may be possible to design around the issue
> - have I missed anything?
>
> Supporting URI formats other than SIP (e.g., HTTP) would still need to
> be worked. But that format would be common to all LbyR usages.
> This in no way removes the requirement for a device-to-LIS "LCP". I
> haven't read that into the suggestion at all.
>
> So, I think this idea warrants consideration.
> Barbara
>
> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Thursday, February 15, 2007 3:51 PM
> To: Stark, Barbara
> Cc: [email-masked]; Otmar Lendl
> Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement
>
>
> On Feb 15, 2007, at 12:50 PM, Stark, Barbara wrote:
>
>   
>> What is difficult, is figuring out a standard format for a URI user 
>> part that would allow for all the variations in combinations of IDs 
>> that exist, so that a standard format could be defined that would 
>> cover all interconnection models. Section 8 of the NENA Location TID
>> (http://www.nena.org/media/files/08-505_20061221.pdf) provides 5 
>> different examples of interconnection models, and the IDs that would 
>> need to be used in each of these cases. In this document, scenario 1 
>> uses the IP address, scenario 2 uses NAS-ID and ATM PVC, scenario 3 
>> uses
>> 2 VLAN tags, scenario 4 uses IP address, and scenario 5 uses L2TP 
>> tunnel ID (source and destination) and PPPoE session ID. These are 
>> just 5 possible examples, and should not be considered exhaustive.
>> Interconnection models are still evolving.
>>     
>
> Well, that's easily solved with a BCP for formulating URIs based on the
> ID.  You don't need a new protocol or to conflate the LCP protocol with
> this functionality.
>
> -andy
>
> *****
>
> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
>
>
>

---

From: <[email-masked]>
Date: Sat, 10 Mar 2007 15:44:14 -0500

Hi Hannes,

Indeed, the scenario I had in mind did not involve LIS-to-LIS in a DSL environment. It is the mobile access to the Internet scenario (3G cell phones / PDAs, PC cards, etc). The deployment I know involves only one entity as both the Internet Service Provider and the (mobile) Access Service Provider, therefore only one LIS is needed. Of course, the LIS-to-LIS issues would apply to deployments where those two providers would be different organizations (I don't know if such deployments actually exist).

In this mobile environment, the ability to specify how quickly a response is needed seems useful. Note that this makes more sense from an OBO perspective as well as if the mobile device itself tries to acquire its location just in time for an emergency call, for example.

Jérôme

-----Message d'origine-----
De : Hannes Tschofenig [mailto:[email-masked]] 
Envoyé : 10 mars 2007 15:00
À : Grenier, Jerome (6002687)
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Geopriv] Geopriv L7 LCP: New Requirement

Hi Jerome,

Ciao
Hanes

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 10 Mar 2007 21:08:40 -0600

Using civic for routing may work in the US where the MSAG is part of the legacy infrastructure. In other jurisdictions that I have spoken with, they would hate to have to develop this just for routing calls. As such a nominal geo associated with fixed wireline access points is also a requirement. Hence the need to be able to get both forms if possible.

There is plenty of demand for a response time parameter and it is in the NENA requirements. It has a very valid application in doing location technology arbitration in wireless location measurement - it is used already in 2G and 3G location determination. There is nothing in IP Location that removes this requirement - your opinion not withstanding being valid as your opinion.

Cheers,
Martin

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Sunday, 11 March 2007 7:00 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Geopriv L7 LCP: New Requirement

Hi Jerome,

Ciao
Hanes

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 10 Mar 2007 21:57:44 -0600

If we consider that the LIS-LIS scenario is typically an ISP LIS gatewaying the request to the infrastructure operator LIS, then the response time parameter still gets carried across that interface. I think the question of LIS-LIS versus target-LIS versus OBO, versus dereference are all orthogonal to the question of the utility of the response time parameter.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Sunday, 11 March 2007 7:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Geopriv L7 LCP: New Requirement

Hi Hannes,

Jérôme

-----Message d'origine-----

Hi Jerome,

Ciao
Hanes

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 11 Mar 2007 16:35:14 -0400

Is there really a use for more response time requests that "immediate" and
"eventually"?  I certainly don't see any use for more than those two in the
emergency case (recognizing that current systems don't have any such
options).  I can see "immediate" as needed for call routing, while
"eventually" is the "get me an accurate fix" that you use to send
responders.  I don't see why anyone would need more than that, and I think
the direction of the technology is to moving towards faster accurate fixes,
so the need to have intermediate states is clearly going to go down over
time.

I also think this is another case where the requirement doesn't have
anything to do with L7, although it does seem to have to do with mobile
devices.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Saturday, March 10, 2007 10:09 PM
> To: Hannes Tschofenig; [email-masked]
> Using civic for routing may work in the US where the MSAG is part of the
> legacy infrastructure. In other jurisdictions that I have spoken with,
> they would hate to have to develop this just for routing calls. As such a
> nominal geo associated with fixed wireline access points is also a
> requirement. Hence the need to be able to get both forms if possible.
> 
> There is plenty of demand for a response time parameter and it is in the
> NENA requirements. It has a very valid application in doing location
> technology arbitration in wireless location measurement - it is used
> already in 2G and 3G location determination. There is nothing in IP
> Location that removes this requirement - your opinion not withstanding
> being valid as your opinion.
> 
> Cheers,
> Martin
> 
> > Having a BCP (one or more) that recommends a syntax to express various
> identifier types for common protocols like SIP/PRES and HTTP would be
> great!
> >
> >
> Ciao
> Hanes
> 
> > Jérôme
> >
> > The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other
> use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If
> you received this in error, please contact the sender and delete the
> material from all computers. GA621
> >
> >
> >

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 11 Mar 2007 17:16:49 -0500

I have to disagree with you on almost all counts below Brian, except possibly with more accurate results are coming more quickly.

JSTD-036B has specifically move away from the immediate request scenario for routing to a low-delay one, as immediate will give you cell only routing, and low-delay will give you a timing advance solution which substantially improves accuracy, and hence reduces misroutes. 

Your last comment I think gets to the crux of the matter. You are thinking a wireline solution only for the L7 protocol, I am not. I think that what we want, and what we are trying to come up with requirements for, is an acquisition protocol covers all access networks. So precluding wireless is a very significant exclusion.

Cheers
James

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Monday, 12 March 2007 7:35 AM
> To: Dawson, Martin; 'Hannes Tschofenig'; [email-masked]
> > > The "ability to specify how quickly a response is needed" would also
> be
> > really helpful to us.
> > >
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > ------------------------------------------------------------------------
> --
> > ----------------------
> > [mf2]
> >
> >

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 11 Mar 2007 18:02:56 -0500

The problem with the concept of classes of service is that they require conventions to define expectations.

3GPP (and related) use two categories: "Low Delay" and "Delay Tolerant".  These would match what Brian has asked for.  In practice, these classes need to be defined, with reasonable time limits and so forth.  No point asking for "Low Delay" if your definition is 1 second and the serving node thinks 3 seconds is OK.  These can be controlled in a closed network - the values communicated between all respective nodes.  Having a number is simple and unambiguous.

Ta,
Martin

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Monday, 12 March 2007 9:17 AM
> To: Brian Rosen; Dawson, Martin; Hannes Tschofenig; [email-masked]
> I have to disagree with you on almost all counts below Brian, except
> possibly with more accurate results are coming more quickly.
> 
> JSTD-036B has specifically move away from the immediate request scenario
> for routing to a low-delay one, as immediate will give you cell only
> routing, and low-delay will give you a timing advance solution which
> substantially improves accuracy, and hence reduces misroutes.
> 
> Your last comment I think gets to the crux of the matter. You are thinking
> a wireline solution only for the L7 protocol, I am not. I think that what
> we want, and what we are trying to come up with requirements for, is an
> acquisition protocol covers all access networks. So precluding wireless is
> a very significant exclusion.
> 
> Cheers
> James
> 
> 
> 
> > > they would hate to have to develop this just for routing calls. As
> such
> > a
> > > > (and I do think we would need some standardization, even if it's
> just
> > a
> > > > any case. The only change is that the URI may require careful
> parsing
> > by
> > > > I've already got a perfectly good non-expiring reference; OBO
> querier
> > or
> > > > The information transmitted is intended only for the person or
> entity
> > to

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 12 Mar 2007 07:55:35 -0400

Okay then is there a reason for anything other than "low delay" vs "most
accurate"?  I see a single bit requirement, but do we really need more than
that?

You have misconstrued my last comment.  I am observing that a delay
parameter is not specific to L7 LCPs.  It applies to any LCP that could
reasonably be used with a mobile device.  In this regard, it is somewhat
like signatures, which are not specific to L7 LCPs but apply to them all.

Brian

> Sent: Sunday, March 11, 2007 6:17 PM

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 12 Mar 2007 07:57:59 -0400

Sounds reasonable.  I would think for routing you would want something like
500 ms.  The usual goal is 2 seconds dial to ring call setup.  Using a
quarter of that for location seems reasonable.  

Brian

> From: Thomson, Martin [mailto:[email-masked]]
> Sent: Sunday, March 11, 2007 7:03 PM
> To: Winterbottom, James; Brian Rosen; Dawson, Martin; Hannes Tschofenig;
> [email-masked]
> 3GPP (and related) use two categories: "Low Delay" and "Delay Tolerant".
> These would match what Brian has asked for.  In practice, these classes
> need to be defined, with reasonable time limits and so forth.  No point
> asking for "Low Delay" if your definition is 1 second and the serving node
> thinks 3 seconds is OK.  These can be controlled in a closed network - the
> values communicated between all respective nodes.  Having a number is
> simple and unambiguous.
> 
> Ta,
> Martin
> 
> > > "eventually"?  I certainly don't see any use for more than those two
> in
> > > the
> > > > > - ability to assert location -- not needed for OBO or LIS-LIS;
> only
> > an
> > > > > - ability to provide rules/profile for privacy -- not needed for
> OBO
> > > or
> > > > > - ability to sign location -- if this is part of PIDF-LO, then
> this
> > is
> > > > > - ability to specify how quickly a response is needed -- this
> would
> > be
> > > > > Supporting URI formats other than SIP (e.g., HTTP) would still
> need
> > to
> > > > >> need to be used in each of these cases. In this document,
> scenario
> > 1
> > > > > Well, that's easily solved with a BCP for formulating URIs based
> on
> > > the
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > --------------------------------------------------------------------
> --
> > --
> > > --
> > > > ----------------------
> > > > [mf2]
> > > >
> > > >

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 12 Mar 2007 16:28:15 -0500

That would be a reasonable starting point.  Of course, if you put it in the protocol, then the UA vendor can make those decisions based on testing and other constraints that they have.  Some may opt for lower or higher based on their experience.

And, as you said, this could apply to all configuration protocols, location or otherwise.  On the other hand, since many of those can be run before call-setup time, there is less of an imperative.

Cheers,
Martin

> Sent: Monday, 12 March 2007 10:58 PM
> To: Thomson, Martin; Winterbottom, James; Dawson, Martin; 'Hannes
> Tschofenig'; [email-masked]
> > > acquisition protocol covers all access networks. So precluding
> wireless
> > is
> > > > Is there really a use for more response time requests that
> "immediate"
> > > and
> > > > > Using civic for routing may work in the US where the MSAG is part
> of
> > > the
> > > > > There is plenty of demand for a response time parameter and it is
> in
> > > the
> > > > > Barbara previously said that geo-location does not make sense in
> the
> > > DSL
> > > > > environment.
> > > > > > yet again. This is a protocol we'd expect to be supported by a
> LIS
> > > in
> > > > > > the queried LIS, and the querier LIS needs to support LbyR
> queries
> > > in
> > > > > > both directions.
> > > > > >
> > > > > > This in no way removes the requirement for a device-to-LIS
> "LCP".
> > I
> > > > > >> cover all interconnection models. Section 8 of the NENA
> Location
> > > TID
> > > > > >> uses the IP address, scenario 2 uses NAS-ID and ATM PVC,
> scenario
> > 3
> > > > > >> uses
> > > > > > ID.  You don't need a new protocol or to conflate the LCP
> protocol
> > > > with
> > > > > > this functionality.
> > > > > >
> > > > > > -andy
> > > > > >
> > > > > > *****
> > > > > >
> > > > > persons or entities other than the intended recipient is
> prohibited.
> > > If

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:25 +0100

Hi Martin,

I will double-check with some location folks to have more than one opinion.
I want to make sure that I also see the "there is a plenty of demand" 
indication.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:30 +0100

Hi Martin,

I agree that the question of "response time parameter" is orthogonal to 
the question of LIS-to-LIS and also to the OBO aspect.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:25 +0100

Hi Martin,

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Mar 2007 20:44:30 +0100

Hi Martin,

Ciao
Hannes