Subject: RE: [Ecrit] draft-polk-dhc-uri-00

From: "McCalmont, Patti" <[email-masked]>
Date: Fri, 23 Sep 2005 09:01:52 -0500

Wow.......guess we all know how you stand but......... even James Polk
stated that one size won't fit all. HELD provides a solution for many
other types of interfaces, such as Wireless as the mobile is moving. It
does take care of the embedded base and it meets other Carrier needs.
Probably not a surprise, but I don't agree at all with your statements.

Patti

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Rosen
Sent: Friday, September 23, 2005 7:26 AM
To: 'Andrew Newton'
Cc: 'ECRIT'
Subject: RE: [Ecrit] draft-polk-dhc-uri-00

I deeply deplore the location determination situation we find ourselves
in.
It is my opinion that the IETF (I suspect that means geopriv) should
state
that the only acceptable protocol for getting location into the endpoint
is
DHCP, and if you manually provision an IP address you could either use
DHCP
for location anyway or manually provision location.  DHCP will work in
every
circumstance.

LLDP-MED, in my opinion, is 100% duplicative, and should not be
deployed.
It changes the element that reports location to be one which is closer
to
the endpoint.  While that is a positive thing, the negatives of two
options
outweigh the positive.  LLDP-MED is only really suitable for deployment
in
enterprise situations where managed Ethernet switches face the
endpoints,
but manufactures of endpoints don't know if they will be used in a home
or
an enterprise.  

DHCP is suitable in every environment for endpoints.  Home routers may
need
some protocol to get location that isn't DHCP so they can give location
to
endpoints via DHCP, but we don't have to implement that in every
endpoint.

In my opinion, HELD is a very large mistake being pushed for a poor
reason:
the installed base of home routers for which in the field upgrade of
firmware is deemed to be so difficult that the promoters of L7 protocols
believe every phone from now till the next big thing should need a third
protocol.  That is, again in my opinion, erroneous, and we should
decline to
standardize an L7 location determination protocol.

I have no illusions that my opinions as expressed above are prevalent
enough
that we will in fact do what I suggest.  I'm advising endpoint
manufacturers
that all phones will need to implement all three protocols.  That is
stupid,
but it's reality.  I've probably committed an error raising these issues
on
this thread in this venue as we should argue the above in geopriv, but
I've
said this before, and we're still spending lots of time on them so rough
consensus is not going my way :(

However to repeat this mistake in the mapping side is wrong.  All of the
proposed protocols for mapping are simple enough that endpoints can
implement them directly.  We'll choose one, and that's it, we don't need
anything else. Having other options forces all endpoints into more code,
for
no good reason.

Having one protocol makes life simpler for everyone.  With this
particular
one (DHCP for mapping determination), endpoints have to implement the
mapping protocol directly, and having done so, should choose to use it,
because the DHCP mechanism is another intermediary that would have to
implement the mapping protocol, and it can fail.  It adds no value; the
endpoint can duplicate the function itself, and in fact, since it
doesn't
know if the DHCP option will be available, HAS to duplicate the
functionality.  

If this was proposed as the ONLY mechanism, then I'd have fewer
problems.
In fact if DHCP was the only location determination mechanism, and this
was
the only mapping determination protocol, then I would be fairly happy.
Folks, you CAN query DHCP at call time.  You can query DHCP any time.
DHCP
is fast.  I'm not worried about DHCP as a protocol; I just don't want
any
options where we don't need any, because of the effect on hundreds or
thousands of endpoint designs.  I'm a little more worried about
robustness,
we don't design DHCP servers to be ultra reliable.  However, I suspect
if
your DHCP server is down, you can't do much of anything anyway, and the
cached value is likely to be good anyways even if I don't want to rely
on
it.

Brian

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, September 22, 2005 9:50 PM
To: [email-masked]
Cc: 'James M. Polk'; 'ECRIT'
Subject: Re: [Ecrit] draft-polk-dhc-uri-00

On Sep 22, 2005, at 6:15 PM, Brian Rosen wrote:

> My personal opinion is that this is not a good idea, that we don't  
> want
> another mechanism between the mapping protocol and the end device,  
> and that
> DHCP is not an appropriate protocol to deliver the URI of the  
> PSAP.  Among
> other reasons, unless we mandated that DHCP is the only way an  
> endpoint
> finds out the URI of a PSAP, then every endpoint that looked for  
> this DHCP
> option would have to implement at least one other way to get it.   
> To me,
> that makes this idea pretty worthless.

Why is it that the lack of DHCPs ubiquity is acceptable for the  
sighting of location information, which is key to the success of the  
LCMS, but this same protocol must be ubiquitous in order for it to be  
used for an optional optimization?

As for there being multiple methods to obtain this information, that  
is already the case today with location information.  Why is this not  
a problem, especially given that location information is essential to  
the entire premise of this working groups output?

-andy

_______________________________________________
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: John Schnizlein <[email-masked]>
Date: Fri, 23 Sep 2005 10:20:33 -0400

Wouldn't it be reasonable to keep the discussion of the issues and 
claims with HELD in the GeoPriv WG where it has been?  We should not 
recapitulate that in this WG also.

John