RE: [Geopriv] Geopriv L7 LCP: New Requirement

From: jerome.grenier@bell.ca
Date: Fri Feb 16 2007 - 16:16:51 EST

I agree with Barbara and would also add :

- ability to request geo and/or civic location

The "ability to specify how quickly a response is needed" would also be really helpful to us.

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!

Jérôme

-----Message d'origine-----
De : Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
Envoyé : 16 février 2007 10:05
À : Andrew Newton
Cc : geopriv@ietf.org; 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:andy@hxr.us]
Sent: Thursday, February 15, 2007 3:51 PM
To: Stark, Barbara
Cc: geopriv@ietf.org; 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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 16 Feb 2007 16:16:51 -0500

This archive was generated by hypermail 2.1.8 : Fri Feb 16 2007 - 16:29:40 EST