Subject: [Geopriv] Terminology (again)

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 22 Jul 2007 21:13:20 +0200

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 23 Jul 2007 10:26:40 -0500

Hi Hannes,

I don't like the term LCP because so many other things use it, and
presupposes that location information is configuration in the same
manner that a local default gateway is, which it clear is not! You don't
for example ask where the default gateway is every time you want to
establish a TCP connection to anything. But I can live with term if I
have to.

I really don't like the term LCS for two main reasons. Firstly the
notion of this function has existed in documents external to the IETF
for several years now and the term "LIS" that they use is widely used.
RFI/RFPs coming in all use this term, and simply using the term LCS to
be different seems a bad idea to me. 

My second reason for not using this term is that LCS if used extensively
in 3GPP specification for location services. Given the inevitable
interaction between specification produced by this WG and 3GPP having
the same acronym in related areas but meaning different things again
seems like a bad idea to me.

I have no strong object to any of the other terms.

Cheers
James

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, 23 July 2007 5:13 AM
> To: GEOPRIV
> Subject: [Geopriv] Terminology (again)
> 
> So, could those people please indicate what terms should be changed.

------------------------------------------------------------------------------------------------
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: <[email-masked]>
Date: Tue, 24 Jul 2007 16:21:56 -0400

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:[email-masked]] 
Envoyé : 22 juillet 2007 15:13
À : GEOPRIV
Objet : [Geopriv] Terminology (again)

Ciao
Hannes

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 24 Jul 2007 15:43:39 -0700

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. 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 1:22 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Geopriv] Terminology (again)
> 
> Hannes,
> 
> 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:
> 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

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.

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jul 2007 19:00:49 -0400

Just as a data point, the lack of a common definition of a LIS in NENA
documents has been recognized, a process for creating a common agreed upon
definition has been initiated, and the difference you cited will be resolved
shortly.

I will say that NENA will continue to use the term LIS, and not LS.  This is
primarily because NENA is not interested in the differences between LS+/-LG;

Brian

> From: Roger Marshall [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2007 6:44 PM
> To: [email-masked]; [email-masked]; [email-masked]
> 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:
> 
> 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]
> 
> 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]
> 
> 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:
> 
> 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.
> 
> >
> 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.
> 
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 21:35:39 -0500

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:[email-masked]] 
Sent: Wednesday, 25 July 2007 8:44 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Terminology (again)

Guy:

Summary:

Thanks.

-Roger Marshall.

-roger marshall.

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 23:02:47 -0400

Roger,

I submit that you will find yourself in the same situation with the term LCS.

I won't risk trying to put forth a definition for LIS/LCS, but we will likely find at the end that it is a discrete box with compounded functions of LG, LS, RH and in some cases, PS.

My point is simply that both LIS and LCS are equivalent (and thus, share the same desire for an unambiguous definition) but LIS has been used a lot prior to l7-lcp. In my opinion, it does not require to be renamed.

Regards,

Guy Caron
-----Message d'origine-----
De : Roger Marshall [mailto:[email-masked]] 
Envoyé : 24 juillet 2007 18:44
À : Caron, Guy (A162859); [email-masked]; [email-masked]
Objet : RE: [Geopriv] Terminology (again)

Guy:

Summary:

Thanks.

-Roger Marshall.

-roger marshall.

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 24 Jul 2007 21:23:57 -0700

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.

> From: Dawson, Martin [mailto:[email-masked]] 
> Sent: Tuesday, July 24, 2007 7:36 PM
> To: Roger Marshall; [email-masked]; 
> [email-masked]; [email-masked]
> 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
> 
> > 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:
> 
> 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]
> 
> 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]
> 
> 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:
> 
> 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. 
> 
> > 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.
> 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
> 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.
> 
> 
>

---

From: "Roger Marshall" <[email-masked]>
Date: Tue, 24 Jul 2007 21:31:04 -0700

Guy:
It depends on how LCS is defined, and I'm not hung up on the term, but rather the definition of the term.  If we define it as LCS is an instance of an LS (IETF context only), then it implies nothing more w/regard to an LCS' interaction with a location calculation entity.

-roger marshall.

> Sent: Tuesday, July 24, 2007 8:03 PM
> To: Roger Marshall; [email-masked]; [email-masked]
> I won't risk trying to put forth a definition for LIS/LCS, 
> but we will likely find at the end that it is a discrete box 
> with compounded functions of LG, LS, RH and in some cases, PS.
> 
> My point is simply that both LIS and LCS are equivalent (and 
> thus, share the same desire for an unambiguous definition) 
> but LIS has been used a lot prior to l7-lcp. In my opinion, 
> it does not require to be renamed.
> 
> Regards,
> 
> Guy Caron
> De : Roger Marshall [mailto:[email-masked]] Envoyé 
> : 24 juillet 2007 18:44 À : Caron, Guy (A162859); 
> [email-masked]; [email-masked] Objet : RE: 
> [Geopriv] Terminology (again)
> 
> Guy:

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 24 Jul 2007 23:54:50 -0500

Hi Roger,

I wasn't thinking in terms of anything other than Internet definitions with respect to LS<->LG.

GSM (and UMTS) don't define an LS-LG interface because the gateway (LS) is at the top of the core network, the serving functions (SMLC and SAS) are subtended from the access. There two separate network elements and three interfaces between the gateway (LS) and serving (LG) functions in that architecture. Alternatively, as we discussed the other day, the GERAN SMLC incorporates the client interface (BSSAP-LE on Lb) and the location determination function is identified as an internal function only (the PCF - position calculation function); i.e. 3GPP does not define a pure PCF interface either; it's implementation specific. Anyway, that all seems out of scope to the Internet definitions; at best these are analogies, not definitive examples.

I think the definition of a LIS is that it is a function which embodies the network location service. It incorporates the client query interface and location determination functions. A LIS can be decomposed into an LS served by one or more LGs.

My invitation was to submit an IETF draft defining the LS<->LG interface.

Cheers,
Martin

-----Original Message-----
From: Roger Marshall [mailto:[email-masked]] 
Sent: Wednesday, 25 July 2007 2:24 PM
To: Dawson, Martin; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Terminology (again)

Hey there Martin: 

-roger marshall.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 30 Jul 2007 11:58:24 +0200

I think the IETF has a tradition of simply labeling entities by their 
role in one protocol, as in "(SIP) user agent server", rather than 
trying to define general architectural roles. These logical roles can 
then be combined, at will, into physical boxes. For example, a registrar 
and a proxy can be in one box, but an external observer can easily tell 
whether something is either, just by looking at messages, without having 
to discern the intent of the protocol designers or do exegesis on 
ancient documents. We should leave that type of work to constitutional 
lawyers.

Defining entities by composite roles is difficult to do since 
architectures tend to evolve and since IETF protocols are often used in 
very different architectures. This differs from, say, the 3GPP world 
where one starts by defining an architecture, but also tends to create 
pictures that tend to become eye charts.

We clearly have gotten into unproductive discussions, to put it 
politely, with trying to reverse-engineer general interpretations from 
entities where the authors had, by nature, a much more limited view of 
the overall system and its functionality.

Thus, I think we should define entities by externally observable 
behavior as in

"protocol foo client/server"

"entity that requests/delivers an information object of type X, 
regardless of the underlying protocol stack"

Thus, "HELD server" seems like a perfectly fine designation to me. That 
way, we don't have to get into theological arguments whether a DHCP 
server delivering CAtypes is morally equivalent to a HELD server 
delivering XML.

Other SDOs are naturally free to label their boxes in whatever way they 
like. They can say, for example, "We consider HELD servers and DHCP 
servers examples of LIS, which we define as having the following 
properties ...". Again, there is a reason that 3GPP defines the term 
I-CSCF, not the IETF. (Others can make the case whether that particular 
labeling has been helpful or not.)

Henning