RE: [Geopriv] coming to terms on location by reference

Nobody has suggested, that I'm aware of, that location by value be
deprecated. What are you actually saying?

Cheers,
Martin

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Thursday, 14 September 2006 11:53 PM
> To: Winterbottom, James; Dawson, Martin; geopriv@ietf.org
> Subject: RE: [Geopriv] coming to terms on location by reference
>
> James,
>
> Following your line of thinking, we can probably deprecate all the
> following
> protocols and their variants:
>
> ftp
> smtp
> pop
> imap
> http
> nfs
> and the list goes on....
>
> Afterall, the client really doesn't care about application data, only
the
> resultant computation/rendering performed on such, which you are
> advocating
> is best done off-board of the host. I believe we could revive 3270 to
> handle all your needs, saving thousands of dollars on client
> cpu/memory/software purchases.
>
> The bottom line is, this community agreed to the requirement(s) that
an
> end
> host needs to know it's location by value, but hasn't yet agreed to
such
> wrt
> location by reference. I suggest you provide convincing arguments
towards
> that end versus questioning the need for previous work.
>
> -Marc-
>
>
>
>
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: Wednesday, September 13, 2006 7:16 PM
> > To: Marc Linsner; Dawson, Martin; geopriv@ietf.org
> > Subject: RE: [Geopriv] coming to terms on location by reference
> >
> > Marc,
> >
> > Carrying the requirement argument forward, it is seldom if
> > ever a requirement for the end-point to have its location.
> > The actual requirement is that the end point wishes to use a
> > service in the network, and that the service requires to the
> > end point's location in order to fulfil the request.
> >
> > This requirement can be resolved either by the end point
> > having its location and forwarding it, or by the service
> > making use of a location reference. Both work.
> >
> > Perhaps you can state a requirement where the end point
> > wishes to have its own location independent of a network service?
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > Sent: Thursday, 14 September 2006 4:01 AM
> > > To: Dawson, Martin; geopriv@ietf.org
> > > Subject: RE: [Geopriv] coming to terms on location by reference
> > >
> > > Martin,
> > >
> > > >
> > > > This piece of misinformation about i2 continues to be
promulgated.
> > The
> > > > i2 *working group* was tasked with defining a solution for fixed
> > > > subscriber access and was encouraged to find a solution
> > supporting
> > > > wireless access as well. The i2 *architecture* was based off the
> > > > cellular mobile interfaces and *most
> > > > definitely* supports mobile devices. That's one of the
> > main reasons
> > > > that the V3 interface exists.
> > >
> > > I view the i2 V3 interface in the same category as L by R in sip
> > > conveyance and L by R in the L7 LCP design team work. None
> > of these
> > > answer the
> > basic
> > > question of what are we trying to do that can't be done
> > with existing
> > > mechanism(s), in other words, the requirements.
> > >
> > > >
> > > > As far as I know it is primarily the detractors of location by
> > > > reference who continue to raise the "business model benefit" and
> > > > it's done so as some kind of anti-benefit statement presumably
to
> > > > discredit the entire concept by association. Objections to this
> > > > particular use location-by-reference are apparently based on an
> > > > ideological criterion that has no place in the engineering of a
> > > > protocol that provides useful functions to those that want to
> > > > implement them.
> > >
> > > My mention of the business model was actually demonstrating
> > a positive
> > for
> > > the L by R justification. We can take it off the table if you
wish.
> > >
> > > >
> > > > I cited a quite extensive list of the benefits
> > location-by-reference
> > > > previously that goes beyond the two you have gleaned.
> > Would you like
> > > > them re-listed?
> > >
> > > Not necessary to repeat. I read this prior to drawing my
> > conclusions
> > > below.
> > > I can comment on each point in the mentioned email if you wish.
> > >
> > > -Marc-
> > >
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > > > -----Original Message-----
> > > > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > > > Sent: Thursday, 14 September 2006 2:18 AM
> > > > > To: 'Andrew Newton'; geopriv@ietf.org
> > > > > Subject: RE: [Geopriv] coming to terms on location by
reference
> > > > >
> > > > > Andy,
> > > > >
> > > > > One thing I continue to look for when L by R solutions are
> > discussed
> > > > is
> > > > > the
> > > > > underlying requirements. In other words, what problem is L by
R
> > > > solving
> > > > > that can't be solved by existing mechanisms.
> > > > >
> > > > > 1) The only requirement that I've been able to glean from
> > > > the multiple
> > > > > years of this discussion is the business requirement of not
> > letting
> > > > > the
> > > > target
> > > > > know the location. Notwithstanding personal opinion on
> > this, this
> > > > > requirement obviously cannot be accomplished by current
> > mechanisms.
> > > > >
> > > > > 2) Any attempt to cite bandwidth efficiency as a
> > > > requirement doesn't
> > > > > normally motivate Internet engineers, lack of bandwidth
> > > > isn't normally
> > > > > associated with Internet devices.
> > > > >
> > > > > 3) The citation of the NENA i2 architecture failing for
wireless
> > > > devices
> > > > > without a L by R mechanism needs more clarification.
> > > > > a) The i2 specification is targeted at
> > residential WIRELINE
> > > > > replacement by VoIP devices normally not thought of as mobile.
> > > > > b) The i2 architecture defines a 'gateway'
> > between the VoIP
> > > > world
> > > > > and the legacy.
> > > > > c) I see no reason why any mechanism to support wireless
> > > > location
> > > > > updates won't work for i2 (no need for a specific mechanism).
> > > > >
> > > > > -Marc-
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Andrew Newton [mailto:andy@hxr.us]
> > > > > > Sent: Tuesday, September 12, 2006 11:18 AM
> > > > > > To: geopriv@ietf.org
> > > > > > Subject: [Geopriv] coming to terms on location by reference
> > > > > >
> > > > > >
> > > > > > As John Schnizlein has noted in a message
> > > > > >
(http://www.ecotroph.net/~anewton/hypermail/geopriv/0607/2717.
> > > > > > html), we have not truly come to consensus on location by
> > > > reference
> > > > > > within this working group. The GEOPRIV working group
> > has been
> > > > > > presented with many individual submissions for both
> > architectural
> > > > > > considerations and concrete solutions.
> > > > > > Additionally, this working group has discussed
> > > > location-by-reference
> > > > > > with regard to its component uses in location configuration
> > > > > > protocols, location dereference protocols, and location
> > > > conveyance
> > > > > > protocols. As a working group, we are much further
> > along in our
> > > > > > understanding of location-by-reference than we were just
> > > > 1 year ago.
> > > > > > And as it stands, there are many who feel it is valuable,
> > > > many who
> > > > > > feel it is not, and many who have not given their
> > > > opinions. But it
> > > > > > is now time for us to determine how we should move forward
on
> > > > > > location-by-reference, either accepting it as a whole,
> > > > accepting it
> > > > > > in limited form, or rejecting it entirely.
> > > > > >
> > > > > > To that end, I offer the following inexhaustive list of
> > > > observations
> > > > > > on this
> > > > > > topic:
> > > > > >
> > > > > > 1) Location-by-reference offers better efficiency where
> > > > location of
> > > > > > a target is not determined by the target and when the
> > > > target wishes
> > > > > > to convey its location. It is more efficient because
> > the target
> > > > > > does not have to first retrieve the location in order to
> > > > convey it.
> > > > > >
> > > > > > 2) Location measurement and determination (sighting) of a
> > > > target by
> > > > > > another element is of limited scope as self-determination
> > methods
> > > > > > such as GPS may offer greater accuracy.
> > > > > >
> > > > > > 3) Authentication of the dereferencer may have unintended
> > > > > > consequences. For example, a referent host may require
> > > > > > authentication that could cause the failure of emergency
call
> > > > > > routing. Therefore, location-by-reference may not
appropriate
> > or
> > > > > > could even be harmful for certain use cases.
> > > > > >
> > > > > > To further this discussion so that we may come to
> > > > resolution on this
> > > > > > topic, I welcome comments regarding the above as well
> > as further
> > > > > > observations.
> > > > > >
> > > > > > -andy
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Geopriv mailing list
> > > > > > Geopriv@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > > >
> > > > > _______________________________________________
> > > > > Geopriv mailing list
> > > > > Geopriv@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/geopriv
> > > >
> > > > --------------------------------------------------------------
> > > > ----------------------------------
> > > > 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]
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/geopriv
> >
> > --------------------------------------------------------------
> > ----------------------------------
> > 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]

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 14 Sep 2006 09:22:26 -0500