Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv

From: "Karl Heinz Wolf" <[email-masked]>
Date: Tue, 13 May 2008 10:36:38 +0200

Hi Barbara!

I'm not sure if your DSL Forum document is the right place for my ELIN
concern: should there be a note "do not to use the LLDP-MED location
data type ELIN"? At least an ELIN would be problematic in your
document looking at server location requirement 10 saying location
from LLDP-MED format is translated to a PIDF-LO. There is no PIDF-LO
element that could hold an ELIN.

Concerning the time to wait for LLDP-MED: recommending the fast
start-up-behaviour could reduce the time to wait. However, I think it
is feasible to activate all ways to get location in parallel, and then
use a defined order in case of multiple locations.

karl heinz

On Thu, Apr 24, 2008 at 4:53 PM, Stark, Barbara <[email-masked]> wrote:
> James,
>  My document does have details for handling multiple locations. I don't
>  think there's any lack of guidance there (and it is the contents of the
>  DSL Forum document we're talking about, and not phonebcp). It says "The
>  device MAY allow configuration of the rules for ordering multiple
>  locations, and selecting the one to use for the  LoST query and routing.
>  The recommended default order is LLDP-MED, DHCP, HELD, GPS, and manual."
>  I think this statement needs to be improved to make a default
>  recommendation in case other configuration mechanisms exist.
>
>  But the guidance that phonebcp does supply is that a device should try
>  all location config protocols (LCPs), and that the device needs to be
>  able to handle multiple locations. So, I believe that the DSL Forum
>  document is consistent in this area, except that it doesn't recommend
>  proceeding with HELD, if there is success at the lower layers. I'll
>  probably change that to do HELD if the device got a LIS server URL via
>  DHCP. But I'm not sure of the benefits of doing public IP address
>  discovery, followed by LIS discovery through reverse DNS, followed by
>  HELD, if the device got location already. If others feel strongly that
>  HELD must always be attempted, then I'll consider changing that.
>
>  So, do you disagree with the phonebcp recommendation to try all LCPs? If
>  you do, how long would you recommend waiting for LLDP-MED to timeout, in
>  case there is no LLDP server in the premises? What do you recommend to
>  address the concerns of people who want to try to make this location
>  config process as quick as possible? My approach was to do a step as
>  soon as possible, without waiting for other things to complete, instead
>  of using lots of timers and timeouts to make sure everything was purely
>  sequential.
>
>  I'm also a bit confused about your pushback to my statement that LLDP
>  wouldn't be present in the majority of consumer scenarios. You say you
>  disagree with that statement. Does that mean you think it will be
>  present in the majority (over 50%) of consumer (residential) scenarios?
>  That's interesting. Are you aware of consumer-grade equipment that does
>  this today? I'm not, which is why I made that statement. I realize that
>  there are a number of consumers who do use high end equipment, either
>  because of their enterprise job, or their home-based business. But
>  statistics that I've seen suggest that this population is very small
>  compared to the population that uses low-end retail home routers. I
>  currently don't see any LLDP servers in my home in the near future.
>  Barbara
>
>
>  -----Original Message-----
>  From: James M. Polk [mailto:[email-masked]]
>  Sent: Wednesday, April 23, 2008 4:30 PM
>  To: Stark, Barbara; Karl Heinz Wolf
>  Cc: ECRIT
>  Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv
>
>
>
> Barbara
>
>  comments in-line
>
>  At 01:12 PM 4/23/2008, Stark, Barbara wrote:
>  >Hi Karl Heinz,
>  >Thanks for reading it.
>  >
>  >I specifically removed the check for whether or not there was a
>  response
>  >from LLDP-MED. By removing that, the device no longer has to wait for
>  >LLDP-MED to timeout before initiating the DHCP. I'm assuming there will
>  >be no LLDP in the majority of consumer scenarios.
>
>  however, LLDP-MED will likely be quite often in enterprise
>  situations, and understanding the level of spillover between the two
>  network environments (residential and enterprise -- not to mention
>  that there really isn't a clear-cut choice for the SMB market to
>  choose between these two, meaning they will come from either,
>  therefore both point products) -- I'm not sure I agree with this
>  opinion.
>
>  >Not waiting makes
>  >things work faster.
>
>  but could (possibly) result in receiving location from two sources.
>  Given the lack of guidance of what to do with more than one location
>  source (does the UA send both?') and what the receiver does with
>  receiving both (which *one* does it deem true (or truer) to use?).
>
>  >In discussions with various people, we came to the
>  >conclusion that there was really no negative consequence to not waiting
>  >for LLDP-MED to either return a response or timeout. This is also
>  >consistent with phonebcp, which expresses a preference for trying all
>  >location configuration protocols.
>
>  --------------- I deleted everything below this -------------------
>
>  *****
>
>  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. GA622
>
>
>
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit