Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Jul 2006 09:20:44 -0400

This thinking results in cases where assumptions made by one end don't
match assumptions made by the other.

Let's take LLDP as the example.  Barbara would say that if the phone
implements LLDP, then it should implement LLDP-MED.  Okay, so suppose I
have a residential phone which does not implement LLDP, so it doesn't
implement LLDP-MED.  So far, so good.  Now, let's look at an enterprise
network.  It may implement LLDP, and thus LLDP-MED.  Okay, the
enterprise phone on the enterprise network works.  What happens when the
residential phone connects to the enterprise network?  No location.
Let's keep going.  Suppose the residential phone implements DHCP, and
thus implemented the DHCP location options.  Unless the network ALSO
implements DHCP location, it doesn't work.  But if the enterprise
implements the DHCP mechanism, then the LLDP mechanism is superfluous. 

Now take the enterprise phone and plug it into a home network, on an
access network that does not meet the applicability statement of the L7
mechanism.  That network deploys DHCP location.  The enterprise phone
can't get location unless it also implements DHCP.  Now take that same
phone and plug it into a network that doesn't deploy DHCP but does meet
the applicability statement for the L7 protocol.  The enterprise phone
ALSO has to implement the L7 protocol.

The "implement the location mechanism corresponding to the configuration
mechanism" simply does not work.  You need a list, where one end
implements ALL and the other end implements "at least one of" to get
interoperability.  There is no other way.

It is not the case that the L7 mechanism can be the single fall-back
mechanism.  It will have an applicability limit, and not all networks
will meet it.  This is effectively true of DHCP.  It would be true of
LLDP if it was on the list.  It is the reason why, in this case, it is
the CLIENT that must implement ALL and the server implement one of.
Usually, we have the server taking the "all" role and the client taking
the "at least one of" role.

Brian

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 8:05 AM
To: Rosen, Brian
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft
wassubmitted)

Brian, 
Counter-point to below is that if the device and network do not support
mutually agreeable configuration method, then the device is a brick
anyway.  L7 becomes a fall-back for the cases where the direct
configuration method does not support passing location through (best
example seems to be home router on DSL or cable modem).   
An important case, not sure well heard yesterday during meeting, was
that in an IPv6 environment with address autoconfig there may be no DHCP
at all.  This may or may not be a small case as IPv6 rolls out, remains
to be seen.  And while IPv6 is not really important now in N.A. it is
very rapidly becoming important in Asia/Pac and also Australia (I'm
told).  Cannot ignore it.   
-- Peter 

"Rosen, Brian" <[email-masked]> 

11.07.06 20:56 

        To:        <[email-masked]>, <[email-masked]>,
<[email-masked]> 
        cc:        [email-masked] 
        Subject:        Re: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcp draft        wassubmitted)

But unless every phone supports LLDP-MED, then an enterprise must also
implement DHCP (or L7) in order to support those phones that don't
support LLDP.  If every access network has to support those 2, then LLDP
is superfelous.

A residential phone may be plugged into an enterprise network.  Ditto an
enterprise phone.  Location acquisition has to work always.  If there is
a list, and one end must support all, with the other end must support at
least one, it always works. 

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
[email-masked]

-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; [email-masked]
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft
wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the
network operator does not control the specification of every device
connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and
<dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location
Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all
VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED
spec), the 2nd if statement really doesn't say much. But it would also
suggest that devices that could have soft clients on them (PCs, PDAs)
also need to do that TLV when they do LLDP-MED. All router-type devices
that implement LLDP-MED are also required to support this TLV, per the
spec.

Since I'm really not at all concerned with the behavior of endpoints
that don't have a DHCP client, I think the first if statement is also
reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it
SHOULD support being configured to request location through a DHCP
INFORM message with options as described in RFC 3825 and <dhcp-civil>,
when it is configured to use one of these alternate bootstrap methods
(e.g., PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into
devices based on all their merits, and not just on location discovery.
If a vendor can't justify putting one or the other of these into a
device (outside of recommendations in this BCP), then I say the protocol
doesn't belong in the device. If the device is going to have one or the
other, or both, then it needs to support the location determination
mechanism that goes with it. Since, for LLDP-MED, that's already a
requirement of the LLDP-MED spec, I really don't see a problem with
stating it here.
Barbara

       -----Original Message-----
       From: Andrew Newton [mailto:[email-masked] <mailto:[email-masked]> ]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, Brian; [email-masked]
       Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp
draft wassubmitted)

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:

               To be clear, I do not have a strong feeling about what
does on Brian's list or not.  I think LLDP-MED is a completely
reasonable thing for a wired phone vendor to implement on enterprise
class phones.

       Just throwing in my $0.0199997, I have not formed a strong
opinion about this either.  It does seem reasonable for enterprise class
devices with ethernet jacks to implement LLPD-MED, or for devices of
category Y to implement method X... as what must be implemented by the
device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if there is no one common
method, then devices may end up implementing things that are not
appropriate in an attempt to have devices that work in multiple network
environments... and even then they may end up missing the mark.
Therefore, one method that does work in all environments must be
implemented.   And that is likely to be the L7-LCP.

       -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. 162
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

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

---

From: <[email-masked]>
Date: Wed, 12 Jul 2006 09:50:39 -0400

Brian,

Can you be more precise on the foreseen "applicability limits" of the yet to be L7 protocol?

 

Guy Caron

Bell Canada

De : Rosen, Brian [mailto:[email-masked]] 
Envoyé : 12 juillet 2006 09:21
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted)

This thinking results in cases where assumptions made by one end don't match assumptions made by the other.

Let's take LLDP as the example.  Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED.  Okay, so suppose I have a residential phone which does not implement LLDP, so it doesn't implement LLDP-MED.  So far, so good.  Now, let's look at an enterprise network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let's keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO implements DHCP location, it doesn't work.  But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous. 

Now take the enterprise phone and plug it into a home network, on an access network that does not meet the applicability statement of the L7 mechanism.  That network deploys DHCP location.  The enterprise phone can't get location unless it also implements DHCP.  Now take that same phone and plug it into a network that doesn't deploy DHCP but does meet the applicability statement for the L7 protocol.  The enterprise phone ALSO has to implement the L7 protocol.

The "implement the location mechanism corresponding to the configuration mechanism" simply does not work.  You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability.  There is no other way.

It is not the case that the L7 mechanism can be the single fall-back mechanism.  It will have an applicability limit, and not all networks will meet it.  This is effectively true of DHCP.  It would be true of LLDP if it was on the list.  It is the reason why, in this case, it is the CLIENT that must implement ALL and the server implement one of.  Usually, we have the server taking the "all" role and the client taking the "at least one of" role.

Brian

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 8:05 AM
To: Rosen, Brian
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

Brian, 
Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway.  L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem).   
An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to be seen.  And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told).  Cannot ignore it.   
-- Peter 

11.07.06 20:56 

        To:        <[email-masked]>, <[email-masked]>, <[email-masked]> 
        cc:        [email-masked] 
        Subject:        Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)

But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP.  If every access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network.  Ditto an enterprise phone.  Location acquisition has to work always.  If there is a list, and one end must support all, with the other end must support at least one, it always works. 

-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; [email-masked]
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and <dhcp-civil>, when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here.
Barbara

       -----Original Message-----
       From: Andrew Newton [mailto:[email-masked] <mailto:[email-masked]> ]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, Brian; [email-masked]
       Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

               To be clear, I do not have a strong feeling about what does on Brian's list or not.  I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones.

       Just throwing in my $0.0199997, I have not formed a strong opinion about this either.  It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -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. 162
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Jul 2006 16:09:56 +0200

>You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability.  There is no >other way.
 
Fully agree. A device needs to implement ALL possible mechanisms, there is no other way, since you never know where a
device is attached to. Period
 
Richard

Von: Rosen, Brian [mailto:[email-masked]]
Gesendet: Mi 12.07.2006 15:20
An: [email-masked]
Cc: [email-masked]; [email-masked]
Betreff: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted)

Brian

Brian, 

11.07.06 20:56 

       -----Original Message-----
       From: Andrew Newton [mailto:[email-masked] <mailto:[email-masked]> ]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, Brian; [email-masked]
       Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

       -andy

*****

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 Jul 2006 07:25:48 -0700

>device is attached to. Period

My agreement with this depends a lot on what "possible" means.  If someone defines a pppoe mechanisms, implementing it in a phone that doesn't support ethernet or pppoe is  not useful.  If you define that as "not a possible mechanism for that phone", then we're probably okay.  But that sounds to me closer to what Barbara is saying than what Brian has said.

I also believe we need to see the text Brian mentioned in the room yesterday for self-configuration.  For some devices, self-configuration will be more accurate than the network-provided location received by many of these methods.  But putting that into the list of mechanisms has some pretty interesting results.

Last, the l7 question has two issues.  First, if you have IP connectivity, will you be able to
reach an l7 server?  The answer to that had better be yes, since reaching one and reaching a sip service have pretty similar properties.   The other question is: will the l7 server be able to identify 1) you and 2) where you.  I take it that Brian's primary concern is that it  will not be possible to identify a client to the l7 server in ways  that will work reliably in all environments.  Until we get a little deeper I can't say, but I do have to question whether the effort to get to that point (so that there is single fallback mechanism) is really worse than every client implementing everything, where everything is a potentially growing list.

				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 12 Jul 2006 10:35:04 -0400

One of Brian's favorite topics and a limitation of L7 protocols:  
VPNs. In those cases, you are unlikely to get to the right L7 server  
or get it the right IP address. In those cases, lower-layer  
solutions, such as LLDP-MED and DHCP are likely to be more reliable.

Thus, I think as important as picking a list, is to also suggest the  
sequence of things to try and whether to keep trying if you got an  
answer (which may be wrong). In other words, if you got a location  
via DHCP, should you also ask via L7?

On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote:

>>> You need a list, where one end implements ALL and the other end  
>>> implements "at least one of" to get interoperability.  There is  
>>> no >other way.
>>
>> Fully agree. A device needs to implement ALL possible mechanisms,  
>> there is no other way, since you never know where a
> My agreement with this depends a lot on what "possible" means.  If  
> someone defines a pppoe mechanisms, implementing it in a phone that  
> doesn't support ethernet or pppoe is  not useful.  If you define  
> that as "not a possible mechanism for that phone", then we're  
> probably okay.  But that sounds to me closer to what Barbara is  
> saying than what Brian has said.
>
> I also believe we need to see the text Brian mentioned in the room  
> yesterday for self-configuration.  For some devices, self- 
> configuration will be more accurate than the network-provided  
> location received by many of these methods.  But putting that into  
> the list of mechanisms has some pretty interesting results.
>
> reach an l7 server?  The answer to that had better be yes, since  
> reaching one and reaching a sip service have pretty similar  
> properties.   The other question is: will the l7 server be able to  
> identify 1) you and 2) where you.  I take it that Brian's primary  
> concern is that it  will not be possible to identify a client to  
> the l7 server in ways  that will work reliably in all  
> environments.  Until we get a little deeper I can't say, but I do  
> have to question whether the effort to get to that point (so that  
> there is single fallback mechanism) is really worse than every  
> client implementing everything, where everything is a potentially  
> growing list.
>
> 				Ted
>

---

From: <[email-masked]>
Date: Wed, 12 Jul 2006 10:52:31 -0400

Henning,

VPN is indeed a concern that I hope, will be addressed by the L7 design team. There are 2 statements in the draft-tschofenig-geopriv-l7-lcp-ps-00 that leads me to believe that some solution may be pointing out for that specific concern.

Guy Caron
Bell Canada
-----Message d'origine-----
De : Henning Schulzrinne [mailto:[email-masked]] 
Envoyé : 12 juillet 2006 10:35
À : Ted Hardie
Cc : Rosen, Brian; Stastny Richard; [email-masked]
Objet : Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)

---

From: "Francois D. Menard" <[email-masked]>
Date: Wed, 12 Jul 2006 12:25:34 -0400

I think the case where you are in the hotel room with your ATA through NAT
is quite eloquent.

The DSL NAT router employed by the hotel operator has to be intelligent
enough to acquire location via PPPoE from the underlying operator (if it was
cable modem, it would get it via DHCP) and then present through its NAT
STACK, a DHCP offer re-offering the same location tocken it acquired.  The
Host grabbing location from its DHCP request has to communicate this
information through the VPN software being launched on the host.  The VPN
server at the far end, when allocating address should attempt to acquire
location of its client before it presents a DHCP offer through the VPN (or
via PPP, or TLS, or whatever).  

Basically, I think it is up to the VPN server to request the location of the
client prior to assigning its VPN IP address and telling what location is
associated with this IP address (which happens to be the same location than
the underlying location).

Is there any better way?

F.

--
François D. Ménard
Chargé de projet
Xit télécom inc.
1350 rue Royale #800
Trois-Rivières, QC, G9A 4J4
Canada
[email-masked]
Tel: (819) 374-2556 ext. 268
Fax: (819) 374-0395
Cell: (819) 692-1383

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 12 juillet 2006 10:35
To: Ted Hardie
Cc: Rosen, Brian; Stastny Richard; [email-masked]
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New
phonebcpdraftwassubmitted)

One of Brian's favorite topics and a limitation of L7 protocols:  
VPNs. In those cases, you are unlikely to get to the right L7 server or get
it the right IP address. In those cases, lower-layer solutions, such as
LLDP-MED and DHCP are likely to be more reliable.

Thus, I think as important as picking a list, is to also suggest the
sequence of things to try and whether to keep trying if you got an answer
(which may be wrong). In other words, if you got a location via DHCP, should
you also ask via L7?

On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote:

>>> implements "at least one of" to get interoperability.  There is no 
>>> >other way.
>>
>> there is no other way, since you never know where a device is 
>> attached to. Period
>>
>> Richard
>>
>
> doesn't support ethernet or pppoe is  not useful.  If you define that 
> as "not a possible mechanism for that phone", then we're probably 
> okay.  But that sounds to me closer to what Barbara is saying than 
> what Brian has said.
>
> configuration will be more accurate than the network-provided location 
> received by many of these methods.  But putting that into the list of 
> mechanisms has some pretty interesting results.
>
> Last, the l7 question has two issues.  First, if you have IP 
> connectivity, will you be able to reach an l7 server?  The answer to 
> that had better be yes, since reaching one and reaching a sip service 
> have pretty similar
> concern is that it  will not be possible to identify a client to the 
> l7 server in ways  that will work reliably in all environments.  Until 
> we get a little deeper I can't say, but I do have to question whether 
> the effort to get to that point (so that there is single fallback 
> mechanism) is really worse than every client implementing everything, 
> where everything is a potentially growing list.
>
> 				Ted
>

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 12 Jul 2006 14:01:13 -0400

Francios,

Your point about using the FIRST attachment provided location information is
very valid.

But in your use case, I would like to think the Hotel operator as a L2
service provider that distributes location information to it's customers
that is more precise than what the Hotel's broadband provider could possibly
provide.  So, in my thinking, the Hotel operator would deploy a wire map
that include floor/room number/etc.  The Hotel operator is an enterprise.

-Marc-

> From: Francois D. Menard [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 12:26 PM
> To: 'Henning Schulzrinne'; 'Ted Hardie'
> Cc: 'Rosen, Brian'; 'Stastny Richard'; [email-masked]
> Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New 
> I think the case where you are in the hotel room with your 
> ATA through NAT is quite eloquent.
> 
> The DSL NAT router employed by the hotel operator has to be 
> intelligent enough to acquire location via PPPoE from the 
> underlying operator (if it was cable modem, it would get it 
> via DHCP) and then present through its NAT STACK, a DHCP 
> offer re-offering the same location tocken it acquired.  The 
> Host grabbing location from its DHCP request has to 
> communicate this information through the VPN software being 
> launched on the host.  The VPN server at the far end, when 
> allocating address should attempt to acquire location of its 
> client before it presents a DHCP offer through the VPN (or 
> Basically, I think it is up to the VPN server to request the 
> location of the client prior to assigning its VPN IP address 
> and telling what location is associated with this IP address 
> (which happens to be the same location than the underlying location).
> 
> Is there any better way?
> 
> F.
> 
> 
> --
> François D. Ménard
> Chargé de projet
> Xit télécom inc.
> 1350 rue Royale #800
> VPNs. In those cases, you are unlikely to get to the right L7 
> server or get it the right IP address. In those cases, 
> lower-layer solutions, such as LLDP-MED and DHCP are likely 
> to be more reliable.
> 
> Thus, I think as important as picking a list, is to also 
> suggest the sequence of things to try and whether to keep 
> trying if you got an answer (which may be wrong). In other 
> words, if you got a location via DHCP, should you also ask via L7?
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 12 Jul 2006 13:21:56 -0500

We are getting into GEOPRIV L7 territory here; perhaps you should direct
these sorts of comments to the GEOPRIV list.  We are, of course, aware
of these issues already and we are working on coming up with some sort
of solution - at the moment, nothing really looks that great - even what
you suggest has limitations that need to be acknowledged.

Cheers,
Martin

> Sent: Thursday, 13 July 2006 2:26 AM
intelligent
> enough to acquire location via PPPoE from the underlying operator (if
it
> was
> Basically, I think it is up to the VPN server to request the location
of
> the
------------------------------------------------------------------------------------------------
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]