In-line.....
On 9/17/09 1:00 PM, "Tschofenig, Hannes (NSN - FI/Espoo)"
<hannes.tschofenig@nsn.com> wrote:
>
>> Hannes,
>>
>> I didn't say it wasn't possible. Your examples don't
>> sacrifice the overall goal/characteristics of the
>> 'next-generation' technology and neither will we sacrifice the
>> end-user's security of privacy to location information the
>> group was created to work on.
>
> We don't sacrifice the privacy of the Target if the security mechanisms
> described in the document are applied.
Not sure I agree. An excerpt from the document (section 5):
" When Device identity is used, the "LCP policy" is only applicable if
the LR and Target are the same entity. If they are the same, the
security and privacy considerations of the base HELD protocol
[I-D.ietf-geopriv-http-location-delivery
<http://tools.ietf.org/html/draft-ietf-geopriv-held-identity-extensions-00#r
ef-I-D.ietf-geopriv-http-location-delivery> ] MAY be applied by a LIS.
The usage of the additional identifiers defined in this document by
the LR MAY cause the LIS to perform additional security verifications
to take place."
I have yet to find where you describe the 'additional security verifications
to take place' and the mechanisms required to accomplish such.
How does the LIS verify that the identifier belongs to the target and not
someone else?
>
>> In hindsight, some transition mechanisms have caused many problems.
>> Remember the gray-beards screaming about NATs?
>
> Actually, this is a very good example where the industry just did
> something because the IETF did not react to the practical needs.
Hmm... The 'excuse' for NATs was IPv4 address exhaustion. But IPv6 was
first published 1995 and updated in 1998. I would not consider this the
IETF not reacting! And my comment about the gray-beards was the IETF
forewarning the problems NATs would cause, which in hindsight, have proven
to be true and have cost far more $$ than simply upgrading to IPv6 way back
when.
> Protocol design requires more than just technical requirements but also
> insight into the properly shared responsibilities and incentives.
And protection of the Internet Architecture model.
-Marc-
>
> Ciao
> Hannes
>
>>
>> -Marc-
>>
>>
>> On 9/17/09 12:43 PM, "Tschofenig, Hannes (NSN - FI/Espoo)"
>> <hannes.tschofenig@nsn.com> wrote:
>>
>>> Well. Think about all the work that is going on in the IETF when it
>>> comes to transition architectures and considering
>> not-updated devices.
>>> I believe that there is now in the IETF more interest to meet the
>>> expectations of the deployment rather than designing clean-slate
>>> architectures.
>>>
>>> Example to support my statement: Proxy Mobile IP, IPv4/IPv6
>> transition
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: I very strongly believe that we have to care about the
>>> intermediate deployment stages as well since we otherwise will never
>>> get to the final stage either.
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>> Behalf Of ext Marc Linsner
>>> Sent: 17 September, 2009 19:36
>>> To: Ray.Bellis@nominet.org.uk
>>> Cc: GEOPRIV
>>> Subject: Re: [Geopriv] WG2LC:
>>> draft-ietf-geopriv-held-identity-extensions-00.txt
>>>
>>>
>>> Ray,
>>>
>>> You won't find too much sympathy in the IETF for not wanting to
>>> upgrade. We're talking about computing devices, not too
>> many deployed
>>> that don't require upgrades. I believe the black-jack game on my
>>> iPhone has been upgraded at least 4 times in the 8 month life of the
>>> phone (and the OS at least 3 times).
>>>
>>> OBO is, IMO, from an end-user pov, a privacy disaster waiting to
>>> happen. But, with proper authentication and authorization
>> it might be
>>> doable within the constraints of GeoPriv.
>>>
>>> -Marc-
>>>
>>> On 9/17/09 12:05 PM, "Ray.Bellis@nominet.org.uk"
>>> <Ray.Bellis@nominet.org.uk> wrote:
>>>
>>>
>>>
>>>
>>>> I'm also not sure that NENA is asking for
>>> third-party/OBO, I believe it's
>>>> SPs asking for it. NENA simply wants location
>>> included with call setup.
>>>
>>> Getting location included with call setup requires software and/or
>>> firmware updates to every (mobile) SIP device on the planet.
>>>
>>> NICC therefore wants OBO, because in the short-to-medium
>> term it's the
>>> only way to get location without requiring those device updates.
>>>
>>> OBO can work now, with the only pre-requisite being deployment of
>>> LIS's on each IP access network. Those LIS's will be required for
>>> first party queries anyway, for those devices that don't have GPS
>>> capablity.
>>>
>>> Ray
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
