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

From: Cullen Jennings <[email-masked]>
Date: Thu, 3 Apr 2008 05:37:43 -0700

Jon and I receive the following email with three files attached. I  
have removed the attachments form the email and put them and a PDF  
version of them at the following URL.

http://idisk.mac.com/cullenfluffyjennings-Public?view=web

Cullen

Begin forwarded message:
> From: "Stark, Barbara" <[email-masked]>
> Date: March 28, 2008 12:53:23 PM PDT
> To: <[email-masked]>, <[email-masked]>
> Subject: Liaison from DSL Forum to ecrit and geopriv
>
> Jon, Cullen,
> Attached is a liaison from the DSL Forum to ecrit and geopriv WGs
> regarding IP device requirements for emergency services. If you could
> pass it along to those groups, I'd appreciate it.
>
> Thanks,
> Barbara
>

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

---

From: "Karl Heinz Wolf" <[email-masked]>
Date: Thu, 17 Apr 2008 14:31:59 +0200

Hi Barbara!

I read your new DSL-Forum document, and I think there is something
missing in flow A.
If one takes the NO path from "is DHCP used for IP address config?",
then there is no check for LLDP-MED success as in case for YES.

One questions regarding server location 12: why should manually
configured civic location not be advertised by LLDP-MED or DHCP.
phonebcp says all fields of PIDF-LO must be able to be specified
(ED-15). All the civic location parts have their according CAType
number (which would fit in DHCP and LLDP-MED), but you cannot say
method=manual in these protocols, is this the actual reason for your
requirement?

just a note for requirement Server location 2: it should be RFC4776 I think.

Thank you for publishing your document here.

-- karl heinz

---

From: "Stark, Barbara" <[email-masked]>
Date: Wed, 23 Apr 2008 14:12:29 -0400

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. Not waiting makes
things work faster. 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 hadn't checked to see that all PIDF-LO fields had a corresponding
CAtype. I see that you're right. Yes, DHCP is missing method. It also
lacks a signing ability (if one is ever created). I'm also concerned
with the ability to represent some of the ideas currently in
draft-ietf-geopriv-pdif-lo-profile-11, like multiple LO in a single
PIDF-LO. That particular example probably isn't relevant to this case,
but I still worry that some change may be made to PIDF-LO in the future
that DHCP/LLDP-MED wont be able to express.

Thanks for mentioning the bad reference.
Barbara

-----Original Message-----
From: Karl Heinz Wolf [mailto:[email-masked]] 
Sent: Thursday, April 17, 2008 8:32 AM
To: Stark, Barbara
Cc: ECRIT
Subject: Re: [Ecrit] Fwd: Liaison from DSL Forum to ecrit and geopriv

Hi Barbara!

just a note for requirement Server location 2: it should be RFC4776 I
think.

-- karl heinz

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 23 Apr 2008 15:29:46 -0500

Barbara

comments in-line

At 01:12 PM 4/23/2008, Stark, Barbara wrote:
>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
>CAtype. I see that you're right. Yes, DHCP is missing method.

I'm not sure what you mean by DHCP=manual needs to be there.  Both 
LLDP-MED and DHCP are in the "server-to-client" direction.  Unless 
I'm misunderstanding what you and Karl seem to be agreeing to, you 
want DHCP and LLDP-MED to be able to send LCI in the 
"client-to-whatever" direction. This isn't the way these protocols 
are designed to work.

>It also lacks a signing ability (if one is ever created).

I'm not sure I understand this concern...

>I'm also concerned with the ability to represent some of the ideas 
>currently in
>PIDF-LO.

Is this concern that DHCP can't send more than one LCI at the same time?

I'm just trying to figure out this exchange... sorry if I've missed 
the point of it

>That particular example probably isn't relevant to this case,

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 24 Apr 2008 10:53:57 -0400

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

therefore both point products) -- I'm not sure I agree with this
opinion.

--------------- 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