RE: [Geopriv] Terminology (again)

From: Roger Marshall ^lt;RMarshall@telecomsys.com>
Date: Wed Jul 25 2007 - 00:23:57 EDT

Hey there Martin:

I guess I don't understand the underlying technical need to requires putting an LS+LG together, when all that gets interacted with for Location Configuration and Dereferencing is the LS component. There seems to be a lot of resistance to the idea of separating the two functions.

The LS-to-LG interface is in fact defined in the case of both ANSI/CDMA & GSM Wireless/CS domains, an example (CDMA) is the J-STD-036 E5 interface. Some carriers think of a LIS as a replacement for an ALI, some others think of it as a PDE, or perhaps an "automated" wiremap repository. A Wireline carrier may not be to keen to select a LIS that does AGPS calculations inside.

How would you define a LIS, Martin? If we can all agree on the defn, then we can use it, and we'll be done.

-roger marshall.

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]
> Sent: Tuesday, July 24, 2007 7:36 PM
> To: Roger Marshall; g.caron@bell.ca;
> Hannes.Tschofenig@gmx.net; geopriv@ietf.org
> Subject: RE: [Geopriv] Terminology (again)
>
> Hi Roger,
>
> I think the wiremap can readily be incorporated in an LG - it
> is after all an essential component for generating location
> from a given piece of fixed layer 2 information. I don't
> think it's worth inferring an additional definition of LIS
> from. A wiremap will also incorporate a database - but I
> don't think that means that the definition of LIS has now
> become LS+LG+WMDB+Database+FileSytem+... etc.
>
> Putting that aside, I don't think there's any inconsistency
> in the definitions below and a LIS is, really, LS+LG. There's
> no need to avoid conflating the terms unless a discussion
> about the specifics of either side of an interface is required.
>
> Nobody has defined a separate formal LS<->LG interface so
> it's not surprising that the aggregate term gets used a lot.
>
> If somebody wants to make a formal LS<->LG interface
> proposal, then I encourage them to do so. Would you consider
> doing that Roger? HELD, with client identity extensions,
> works fine for this purpose.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: Roger Marshall [mailto:RMarshall@telecomsys.com]
> Sent: Wednesday, 25 July 2007 8:44 AM
> To: g.caron@bell.ca; Hannes.Tschofenig@gmx.net; geopriv@ietf.org
> Subject: RE: [Geopriv] Terminology (again)
>
> Guy:
> I've snipped out the following parts for comment:
>
> > While I recognize the right to the IETF to forge it own
> terms suitable
> > within the context of its work, it nevertheless strikes me
> when I see
> > a new one being created when one already exists with the exact same
> > definition which has been commonly used within IETF WGs and other
> > forums for years now without confusion.
>
> The problem is that the term "LIS" has never had any
> exactness to it. This is one potential reason for some of
> the confusion that may exist for those familiar with both the
> IETF and the NENA uses:
>
> 1.) a suggested LIS definition which equates to an IETF term
> "LS" alone (per 3893):
>
> Location Information Server (LIS): A LIS is a Location Server
> located in the Access Provider's domain that is either
> co-located with a Location Generator (LG) or has access to
> one or multiple LGs. The terms "Location Server", "Access
> Provider" and "Location Generator" are taken from RFC 3693.
> [from: ietf Geopriv archive
> http://www1.ietf.org/mail-archive/web/geopriv/current/msg03257
> .html, a suggested definition from Hannes Tschofenig on 4/10/2007]
>
> 2.) the NENA LIS definition which co-mingles the idea of an "LG+LS":
>
> Location Information Server (LIS): The LIS is a network
> entity that determines location of Targets with in the access
> network and provides that location information authenticated
> and authorized recipients. Location determination is
> performed network measurements provided by ALEs residing in
> the access network. [from: 08-505 NENA "Recommended Method(s)
> for Location Determination to Support IP-Based Emergency
> Services", Issue 1, December 21, 2006]
>
> 3.) another NENA LIS definition which relates the above,
> (LS+LG), along with a Wire-map database:
>
> Location Information Server (LIS) - The LIS stores a wiremap
> of the relationship between a unique identifier for a
> physical endpoint termination and a location, described as
> either geo-coordinates or a civic address). The
> administrator/owner of the LIS is responsible for creating
> and maintaining this wiremap, and for ensuring that civic
> location data is pre-validated by a Validation Function. The
> LIS may be used during location determination and
> acquisition. The LIS may also support assignment of a
> location query key to a particular IP device, and download of
> this key to the IP device to support subsequent queries for
> the location from other elements in the IP domain. [from:
> NENA i3 Technical Requirements Document NENA 08-751, Issue 1,
> September 28, 2006]
>
> Summary:
> The only way the term LIS could work, is, if each type of LIS
> was qualified, something like what is suggested here:
>
> S-LIS (Service LIS) == LS
> C-LIS (Calculating LIS), == LG+LS
> M-LIS (Database LIS) == LG+LS+WMDB (WireMap DataBase)
>
> It's understood that carriers/customers may choose discrete
> functions from a variety of vendors. Conflating functions
> into some multi-purpose LIS (e.g., LIS=LS+LG+DB), without
> proper clarity of qualification, doesn't help in terms of
> standards, but certainly may be viable through implementation choice.
>
> Thanks.
>
> -Roger Marshall.
>
> >
> > For those reasons, I would lean towards keeping the term Location
> > Information Server (LIS) in the context of Geopriv where
> such term is
> > applicable (i.e., not necessarily update RFC3693).
>
>
> -roger marshall.
>
> > -----Original Message-----
> > From: g.caron@bell.ca [mailto:g.caron@bell.ca]
> > Sent: Tuesday, July 24, 2007 1:22 PM
> > To: Hannes.Tschofenig@gmx.net; geopriv@ietf.org
> > Subject: RE: [Geopriv] Terminology (again)
> >
> > Hannes,
> >
> > First, thanks to bring this up (again).
> >
> > While I recognize the right to the IETF to forge it own
> terms suitable
> > within the context of its work, it nevertheless strikes me
> when I see
> > a new one being created when one already exists with the exact same
> > definition which has been commonly used within IETF WGs and other
> > forums for years now without confusion.
> >
> > For those reasons, I would lean towards keeping the term Location
> > Information Server (LIS) in the context of Geopriv where
> such term is
> > applicable (i.e., not necessarily update RFC3693).
> >
> > Besides that and as highlighted by Barbara Stark, the term "Access
> > Network Provider" needs to be better defined in the lcp
> requirements
> > document to capture the possibility of L1-L2 and L3 LISs to be
> > distinct components operated by different service providers
> (this is
> > somewhat captured in req. L7-4 which comes at the end of the
> > document). I believe that Barbara's suggestion to remove the word
> > "provider" when used in conjunction with "Access Network"
> would work
> > just fine.
> > Porting Barbara's proposed definition of "Access Network"
> > seems also useful. You will find it here:
> > http://www1.ietf.org/mail-archive/web/geopriv/current/msg03842.html
> >
> > And while at it, requirement L7-3 talks about VSP, ISP/ASP
> but those
> > terms are not defined anywhere. Spelling out VSP would
> suffice in my
> > opinion. For "ISP/ASP", I suggests replacing it with
> "Access Network"
> > (this would be consistent with Barbara's definition). NAT is also
> > mentioned but this one may be a given.
> >
> > Finally, I can't resist bringing back the issue with the
> term LCP. I'm
> > still convinced this is not appropriate in the context of L7 and
> > Location Acquisition Protocol (LAP) or Location Delivery Protocol
> > (LDP) would work better ;~)
> >
> > Regards,
> >
> > Guy Caron
> > -----Message d'origine-----
> > De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Envoyé : 22 juillet 2007 15:13
> > À : GEOPRIV
> > Objet : [Geopriv] Terminology (again)
> >
> > I would like to complete the work on
> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-
> > ps-03.txt
> >
> > I noticed that some people are still unhappy with the terminology.
> >
> > So, could those people please indicate what terms should be changed.
> >
> > Ciao
> > Hannes
> >
> >
> > _______________________________________________
> > 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
> >
>
>
> The information contained in this message may be privileged
> and/or confidential. If you are not the intended recipient,
> or responsible for delivering this message to the intended
> recipient, any review, forwarding, dissemination,
> distribution or copying of this communication or any
> attachment(s) is strictly prohibited. If you have received
> this message in error, please so notify the sender
> immediately, and delete it and all attachments from your
> computer and network.
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv
>
> --------------------------------------------------------------
> ----------------------------------
> 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]
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Tue, 24 Jul 2007 21:23:57 -0700

This archive was generated by hypermail 2.1.8 : Wed Jul 25 2007 - 00:24:14 EDT