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

From: [email-masked]
Date: Fri, 23 Sep 2005 10:01:19 -0400

Brian,

I just joined this tread so if any of my comments have already been provided by others and discussed, I apologise.

The main reason why DHCP should NOT be the ONLY method for location acquisition is because it would not work for a large portion of existing broadband access infrastructures that do not use DHCP today (and don't plan to), especially in the residential market.

If you mean to have DHCP in the home network only (between IP device and HG), this would still not address how the HG would acquire the location in the first place.

BTW, L7 solutions are not pushed only because of the reasons you mentioned but also because of what I explained above.

Who can claim to know what kind of L2 mechanisms (and mixes of) are deployed in the world today? How can the IETF certify any L2 mechanism (and mixes of) will work "out of the box" for any implementation?

On the other hand, applications will always work. I would also claim that applications are easier to develop and to evolve over time.

Finally, the issue is not with location determination but rather with location acquisition. The former uses local mechanisms proprietary to the type of broadband access network the EP gets the service from.

My 2 cents.

P.S.: If this is not the right forum for this discussion, please direct me to the right one. I would be happy to continue this further.

Guy Caron

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Brian Rosen
Envoyé : 23 septembre 2005 08:26
À : 'Andrew Newton'
Cc : 'ECRIT'
Objet : 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:18:27 -0400

The best forum to discuss HELD is the GeoPriv Working Group, where 
several issues with it have been raised.

John

On Sep 23, 2005, at 10:01 AM, [email-masked] wrote:
>
> ...
> BTW, L7 solutions are not pushed only because of the reasons you 
> mentioned but also because of what I explained above.
>
> Who can claim to know what kind of L2 mechanisms (and mixes of) are 
> deployed in the world today? How can the IETF certify any L2 mechanism 
> (and mixes of) will work "out of the box" for any implementation?
>
> On the other hand, applications will always work. I would also claim 
> that applications are easier to develop and to evolve over time.
> ...
> P.S.: If this is not the right forum for this discussion, please 
> direct me to the right one. I would be happy to continue this further.