Bill to require warrants for tracking:
http://arstechnica.com/tech-policy/news/2011/06/bipartisan-bill-would-end-governments-warrantless-gps-tracking.ars
Bill to place constraints on services (require notification and consent):
http://www.wired.com/epicenter/2011/06/franken-location-loopholes/
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
--Martin
On 2011-04-04 at 14:20:15, Matt Duckham wrote:
> Martin,
>
> Thanks for this. I think the draft does look good, clear and very
> carefully thought through. Some comments:
>
> * Constraints to movement: You already anticipated my first
> criticism-- -that the spaces we navigate through almost always present
> known constraints to movement, and these may be exploited by a privacy
> attack. I think in general the principles you adopt might reasonably
> be translated to network spaces, even thought the geometry embedded in
> the specific methods would not. For example, one might interpret the
> distance parameter as, say, total *length* of network in which a
> person may be located with uniform probability (as opposed to radius
> of circle in which a person may be located with uniform probability).
> It would potentially not be too difficult to derive similar procedures
> to the planar geometric ones suggested in this case. But of course,
> one would need to in some way link this into information about the
> network that constrains movement, which does leave some questions
> unanswered. In short
> * Distance as a proxy for privacy: Distance can be, I think, a poor
> proxy for level of privacy. In particular, for two of the main threats
> from lack of privacy---intrusive inferences (about what activities I
> am engaged in) and physical harm (by someone who can locate
> me)---distance does not correlate especially well with level of
> privacy. In dense downtown NY city, for example, the same obfuscation
> radius presumably affords me much more protection from these threats
> (and so greater level of privacy), than it does in upstate New York.
> In some senses this is related to above: rather than heterogeneous
> constraints to movement across space, the point here is about the
> heterogeneous density of features/activities I might be engaged in across space.
> * Role of obfuscation methods: I wasn't quite sure what the role of
> the methods provided for obscuring location were: as examples, or as
> an exhaustive set of options? The latter strikes me as dangerous---
> although the privacy threats have been carefully analyzed in the
> draft, I think it highly likely that further ingenious methods for
> subverting these privacy protection methods could be designed, given a
> little time and motivation. So, I would expect that the standard aims
> to provide the framework for obscuring location, with perhaps some
> examples of obfuscation techniques, but leaves the details of how
> location is obscured to individual systems and service providers.
> Perhaps this is what you aim for, and I am just not familiar enough with the material.
> * Temporal issues: Also as I have argued in [2], which you mention, I
> think the static case is *relatively* easy to deal with compared to
> the dynamic case. The draft does consider carefully temporal issues,
> but I have the feeling that there are many more (maybe innumerable)
> ways in which one might attack privacy through integrating data from
> repeated observations of an individual (e.g., constraints to movement,
> conservation of momentum, maximum speed, goal directed movement, and
> even coordinated movement, see below). There is one other paper I
> wrote that started looking at this
> http://www.geosensor.net/papers/duckham06.GISCIENCE.pdf. As for the
> previous point, I doubt it is possible to come up with in advance any
> single method for obfuscation that can anticipate all these potential
> attacks. So presumably the standard needs to provide the underlying
> structure for obfuscated location-based services, but also allow lots
> of room for new innovation and adapting to unforeseen privacy threats.
> * Invasion of privacy across groups: Human movement is highly
> coordinated. If I know about the movements of groups of individuals
> (even if these are obfuscated) that also presumably provides a good
> basis for attacking privacy. I didn't really see anything in the draft
> about this issue---what happens if as an attacker I am able to relate
> locations not just over time but also over multiple individuals?
>
> Anyway, I don't think there even exist many good answers to some of
> these questions yet, and no doubt you have already been thinking about
> some or even all of these issues. In short, I see several important
> problems---ways in which techniques in the standard could fail or
> become bypassed through too many simplifying assumptions; but, under
> the circumstances (of a very complex problem, with no complete
> solutions yet in existence) I think the draft is nice, and makes a
> good fist of providing practical steps to protect location privacy,
> and highlighting many of the fundamental issues (e.g., threats through
> inferences across multiple times, uniform probability across
> obfuscation regions, etc.)
>
> I hope that helps, happy to discuss further any points that come up...
>
> bw Matt
>
>
> On Mon, Mar 21, 2011 at 4:19 PM, Thomson, Martin
> <Martin.Thomson@commscope.com> wrote:
>
>
> Hi Matt,
>
> I'm glad to see that you are aware of our efforts. I read some of
> your earlier work on the topic. It's certainly the best of the
> (limited) reading that I have done.
>
> Your opinion on the direction of the work that we are pursuing with
> regards to obfuscation would be greatly appreciated.
>
>
> http://tools.ietf.org/html/draft-ietf-geopriv-policy-23#section-6.5.2
>
> http://tools.ietf.org/html/draft-thomson-geopriv-location-obscuring-02
>
> The goal of each of these algorithms is to retain accuracy while
> reducing precision.
>
> I'm afraid that our earlier efforts were little better than that in
> Ardagna [1], which I fear is quite poor with respect to solution.
> These latter examples might be a little better.
>
> We willfully violate your principles [2] as a necessity - the
> algorithms are designed to be run without the sort of knowledge that
> might be used to attack them. Thus, we might be making a good
> solution for ships on the open ocean and desert trekkers without any
> real hope, but that doesn't mean we're not going to keep trying.
>
> Regards,
> Martin
>
> [1] http://portal.acm.org/citation.cfm?id=1770566
> [2] http://geosensor.net/papers/duckham10.SPRINGL.pdf
>
...
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
True. I hadn't really considered that use case.
> Of course, it's also a privacy feature.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
This is where X is.
This is where X says that X is.
This draft enables finer-grained, policy-based control over the lying process, for location.
On 2011-06-30 at 09:40:49, Carl Reed wrote:
> Liar, liar your pants are on fire . . .
I almost submitted this as draft-thomson-geopriv-pantsonfire-00, but thought better of it.
> I am reading the draft document now. A couple of questions/suggestions:
>
> 1. Perhaps a more "serious" element name than "liar"? I agree that
> the ability to provide a replacement location has value and is
> definitely easier than trying to obscure one's location. But . . .
I really did try to understate the seriousness of choosing to lie. Or more to the point: of asking someone to lie for you. Lies can result in some very serious consequences. I should probably point that out in the security considerations section.
Embarrassment is actually the least serious consequence I imagined.
> 2. What happens in an emergency call situation? The NENA folks might
> wonder.
> Perhaps some words on the emergency call use case.
Lying to a PSAP is a bad thing. Despite the seriousness of it - and an inordinate focus on that use case in this forum - I don't actually see the need to make a special point of it here. To be frank, that's a pretty narrow slice of the lying pie.
> 3. There might be some interesting legal issues here. Also perhaps has
> some counter-terrorism or drug interdiction implications. Of course,
> if law enforcement can always get "true" location from the location
> determination provider or mobile device or mobile provider perhaps
> this is not an issue.
Not to make light of this, but that latter part is entirely a matter for policy makers. If a jurisdiction wants to place a requirement on location servers to tell the truth to particular agencies of that jurisdiction, then that's their prerogative. Assuming that the location server knows the truth in the first place (see above).
> Anyway, I passed this document to the folks at the Center for Spatial
> Law and Policy to see if they have any comments. Location and privacy
> policy is a big issue for them.
Their response will be of great interest.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I am reading the draft document now. A couple of questions/suggestions:
1. Perhaps a more "serious" element name than "liar"? I agree that the
ability to provide a replacement location has value and is definitely easier
than trying to obscure one's location. But . . .
2. What happens in an emergency call situation? The NENA folks might wonder.
Perhaps some words on the emergency call use case.
3. There might be some interesting legal issues here. Also perhaps has some
counter-terrorism or drug interdiction implications. Of course, if law
enforcement can always get "true" location from the location determination
provider or mobile device or mobile provider perhaps this is not an issue.
Anyway, I passed this document to the folks at the Center for Spatial Law
and Policy to see if they have any comments. Location and privacy policy is
a big issue for them.
Regards
Carl
----- Original Message -----
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: <geopriv@ietf.org>
Sent: Wednesday, June 29, 2011 1:08 AM
Subject: Re: [Geopriv] New Version Notification
fordraft-thomson-geopriv-lying-00.txt
> On 2011-06-29 at 16:49:48, internet-drafts@ietf.org wrote:
>> A new version of I-D, draft-thomson-geopriv-lying-00.txt has been
>> successfully submitted by Martin Thomson and posted to the IETF
>> repository.
>
> <http://tools.ietf.org/html/draft-thomson-geopriv-lying>
>
> I think that the Abstract summarizes this best:
>
>> Abstract:
>> Obscuring location effectively is difficult. Falsehood offers a
>> simpler, more effective method of location privacy protection. A
>> mechanism is defined whereby a rule maker can request that a
>> location server lie about location.
>
> The mechanism is an extension to geopriv-policy.
>
> --Martin
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Begin forwarded message:
> From: Suresh Krishnan <suresh.krishnan@ericsson.com>
> Date: June 24, 2011 7:12:41 PM GMT+01:00
> To: IETF Discussion <ietf@ietf.org>
> Subject: Nomcom 2011-2012: Second Call for Volunteers
>
> This is the Second call for Volunteers for the 2011-12 Nomcom. We are
> just about halfway through the volunteer period so if you are considering
> volunteering, please do so very soon.
>
> We have had a very good response to the initial call for volunteers and
> I am pleased to report that we have 50 volunteers thus far whose
> qualifications have been confirmed by the secretariat. I have notified
> each of these volunteers by email.
>
> However, we would like to have many more volunteers. The more volunteers,
> the better chance we have of choosing a random yet representative cross
> section of the IETF population. You have until 11:59 pm EDT July 10, 2011
> to volunteer for Nomcom but it would be much better if you can volunteer
> as early as possible.
>
> If you volunteered before 21:00 EDT on June 21 to serve as a voting member
> and have not received a confirmation email from me, please re-submit and
> bring to my attention right away!
>
> Details about the process for volunteering for the Nomcom and the list
> of open positions for which the nominating committee is responsible are
> summarized in the initial announcement:
>
> https://datatracker.ietf.org/ann/nomcom/2938/
>
> The 50 volunteers who have thus far been qualified by the secretariat
> are:
>
> Alia Atlas , Juniper Networks
> Lixia Zhang , UCLA
> Wassim Haddad , Ericsson
> Glen Zorn , Network Zen
> Richard Barnes , BBN Technologies
> Stephen Kent , BBN Technologies
> Scott Mansfield , Ericsson
> Tina TSOU , FutureWei Technologies
> Fernando Gont , UTN/FRH
> Karen Seo , BBN Technologies
> Jie Dong , Huawei Technologies
> Mach Chen , Huawei Technologies Co.
> Sheng Jiang , Huawei Technologies Co. Ltd.
> Dimitri Papadimitriou , Alcatel-Lucent
> Thomas D. Nadeau , CA Technologies
> David Meyer , Cisco Systems/University of Oregon
> Wesley George , Time Warner Cable
> Cullen Jennings , Cisco
> Stephen Hanna , Juniper Networks
> Stephan Wenger , Bidyo
> Keyur Patel , Cisco Systems
> Michael Hamilton , BreakingPoint Systems
> Behcet Sarikaya , Huawei USA
> Mark Townsley , Cisco Systems
> Fred Baker , Cisco Systems
> Brian Trammell , ETH Zurich
> Sam Hartman , Painless Security
> Chris Griffiths , Comcast
> George Michaelson , APNIC
> Jiankang Yao , CNNIC
> Sohel Khan , Comcast
> Dacheng Zhang , Huawei
> Lianshu Zheng , Huawei Technologies
> Hui Deng , China Mobile
> Gang Chen , China Mobile
> Mirja Kuhlewind , University of Stuttgart
> John E Drake , Juniper Networks
> Matt Lepinski , BBN Technologies
> Subir Das , Telcordia Technologies Inc
> Yi Zhao , Huawei
> John Scudder , Juniper Networks
> Christer Holmberg , LM Ericsson
> Teemu Savolainen , Nokia
> Samita Chakrabarti , Ericsson
> Jaap Akkerhuis , NLnet labs
> Jason Weil , Time Warner Cable
> Randy Bush , Internet Initiative Japan
> Christian Schmidt , Nokia Siemens Networks
> Sean Shen , CNNIC
> Lou Berger , LabN Consulting
>
> The primary activity for this nomcom will begin during IETF-81 in
> Quebec City and should be completed by January 2012. The nomcom will
> be collecting requirements from the community, as well as talking to
> candidates and to community members about candidates. There will be
> regularly scheduled conference calls to ensure progress. Thus, being a
> nomcom member does require some time commitment.
>
> Please volunteer by sending an email to me before
> 11:59 pm EDT July 10, 2011 as follows:
>
> To: suresh.krishnan@ericsson.com
> Subject: Nomcom 2011-12 Volunteer
>
> Please include the following information in the body of the mail:
>
> Full Name: // As you enter in the IETF Registration Form,
> // First/Given name followed by Last/Family Name
>
> Current Primary Affiliation: // typically what goes in the Company
> // field in the IETF Registration Form
>
> Email Address(es): // all email addresses used to Register for the
> // past 5 IETF meetings
> // Please designate a Preferred email address for
> // contact if there is more than one email address
>
> Telephone number: // With country code (for confirmation if selected)
>
> Please expect an email response from me within 3 business days stating
> whether or not you are qualified. If you do not receive a response in
> this timeframe, please re-send your email with the tag "RESEND:" added
> to the subject line.
>
> If you are not yet sure you would like to volunteer, please consider
> that Nomcom members play a very important role in shaping the
> leadership of the IETF. Ensuring the leadership of the IETF is fair
> and balanced and comprised of those who can lead the IETF in the right
> direction is an important responsibility that rests on the IETF
> participants at large. Volunteering for the Nomcom is a good way of
> contributing in that direction.
>
> I will be publishing a more detailed target timetable, as well as
> details of the randomness seeds to be used for the RFC 3797 selection
> process within the next few days.
>
> Thank you in advance for your participation.
>
> Suresh Krishnan
> Nomcom Chair 2011-2012
> Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
<http://tools.ietf.org/html/draft-thomson-geopriv-lying>
I think that the Abstract summarizes this best:
> Abstract:
> Obscuring location effectively is difficult. Falsehood offers a
> simpler, more effective method of location privacy protection. A
> mechanism is defined whereby a rule maker can request that a
> location server lie about location.
The mechanism is an extension to geopriv-policy.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
--Martin
On 2011-06-27 at 14:48:48, internet-drafts@ietf.org wrote:
> A new version of I-D, draft-thomson-geopriv-location-obscuring-03.txt
> has been successfully submitted by Martin Thomson and posted to the
> IETF repository.
>
> Filename: draft-thomson-geopriv-location-obscuring
> Revision: 03
> Title: Obscuring Location
> Creation date: 2011-06-27
> WG ID: Individual Submission
> Number of pages: 32
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
--Martin
> -----Original Message-----
> From: Priebe, Russell
> Sent: Wednesday, 30 June 2010 11:54 PM
> To: Thomson, Martin
> Subject: RE: WiFi positioning measurements
>
> If I could have any measurement in order of value:
>
> 1) round trip delay
> 2) RSSI (preferably multiple AP signal strengths at client)
>
> There's really not a lot else, and round trip delay is not generally
> available yet.
>
> If by regulatory class, you mean 11g vs 11a vs 11b vs 11n, that info
> is in SUPL 2.0.
> Was that what you meant? And theoretically, yes, I could leverage that
> information to improve accuracy.
>
> Russell
>
> -----Original Message-----
> From: Thomson, Martin
> Sent: Tuesday, June 29, 2010 7:41 PM
> To: Priebe, Russell; Winterbottom, James; Andrew
> Subject: RE: WiFi positioning measurements
>
> Hi Russell,
>
> The question was more: if you could have any measurement, what could
> you use? What would you want?
>
> I understand that SUPL 2.0 has a number of measurements, but there are
> some omissions. For instance, the measurement doesn't include the PHY.
> If you knew the regulatory class, could you use it to get a better
> location, even if in theory?
>
> --Martin
>
> > -----Original Message-----
> > From: Priebe, Russell
> > Sent: Wednesday, 30 June 2010 6:13 AM
> > To: Winterbottom, James; Thomson, Martin; Andrew
> > Subject: RE: WiFi positioning measurements
> >
> > James,
> >
> > Probably the best list is SUPL 2.0.
> >
> > There is an 802.11v standard in development that might bring some
> > detail, but we don't have access to it.
> >
> > Russell
> >
> >
> >
> > -----Original Message-----
> > From: Winterbottom, James
> > Sent: Tuesday, June 29, 2010 1:53 AM
> > To: Thomson, Martin; Andrew
> > Cc: Priebe, Russell
> > Subject: RE: WiFi positioning measurements
> >
> > This should probably be Russell Priebe, at least to start with.
> >
> > Russell, would you mind taking a look please?
> > The Atheros guys did indicate that they were familiar with this work
> > and had indicated that they would "probably" provide some
> enhancements,
> > but as you both know, information seems kind of one way.
> >
> > Cheers
> > James
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Thomson, Martin
> > > Sent: Tuesday, 29 June 2010 3:52 PM
> > > To: Andrew
> > > Cc: Winterbottom, James
> > > Subject: WiFi positioning measurements
> > >
> > > Hi Andrew,
> > >
> > > James and I are working on a measurements format for our IP
> location
> > stuff
> > > and we've had a number of comments regarding what to include in
> > > the
> > WiFi
> > > measurements.
> > >
> > > <http://tools.ietf.org/html/draft-thomson-geopriv-held-
> > measurements>
> > >
> > > We currently have a slew of parameters for WiFi, but we've never
> > really
> > > had a good assessment of which of these are truly useful. Is
> someone
> > in
> > > your team in a better position to say which of these is useful?
> > >
> > > Most recently, someone has suggested more 802.11k parameters. The
> > copy we
> > > have doesn't even have the parameters they mentioned. Are you
> aware
> > of
> > > anything in an upcoming version that could be of use to us?
> > >
> > > Regards,
> > > Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Changes (by martin.thomson@…):
* status: new => closed
* resolution: => fixed
Comment:
Addressed in -03.
--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner:
Type: defect | Status: closed
Priority: critical | Milestone:
Component: deref-protocol | Version: 1.0
Severity: In WG Last Call | Resolution: fixed
Keywords: |
---------------------------------------+------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/49#comment:1>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
This addresses the issues discussed here:
<http://www.ietf.org/mail-archive/web/geopriv/current/msg09111.html>
I've updated references and affiliations as appropriate. This document is ready for the next stage of scrutiny.
--Martin
On 2011-06-23 at 12:06:40, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Geographic
> Location/Privacy Working Group of the IETF.
>
> Title : A Location Dereferencing Protocol Using HELD
> Author(s) : James Winterbottom
> Hannes Tschofenig
> Henning Schulzrinne
> Martin Thomson
> Martin Dawson
> Filename : draft-ietf-geopriv-deref-protocol-03.txt
> [...]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Title : A Location Dereferencing Protocol Using HELD
Author(s) : James Winterbottom
Hannes Tschofenig
Henning Schulzrinne
Martin Thomson
Martin Dawson
Filename : draft-ietf-geopriv-deref-protocol-03.txt
Pages : 24
Date : 2011-06-22
This document describes how to use the Hypertext Transfer Protocol
(HTTP) over Transport Layer Security (TLS) as a dereferencing
protocol to resolve a reference to a Presence Information Data Format
Location Object (PIDF-LO). The document assumes that a Location
Recipient possesses a URI that can be used in conjunction with the
HELD protocol to request the location of the Target.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-deref-protocol-03.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-geopriv-deref-protocol-03.txt
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Very well written and even for me easy to understand! Only nit is whether
you want "Privacy" in the title of the document. I passed the draft to the
OGC community for consideration as we now have a couple of URI based
standards in process (Open GeoSMS being one).
Carl
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "GEOPRIV WG" <geopriv@ietf.org>
Sent: Monday, June 20, 2011 12:27 PM
Subject: Re: [Geopriv] I-D Action: draft-ietf-geopriv-policy-uri-01.txt
> <hat type="individual" />
>
> This version addresses comments from last call related to:
> -- Multi-protocol support
> -- The relationship between policy URIs, location URIs policy documents
> -- Policy URI deletion / expiry
> -- Several editorial issues.
>
> Since all the significant changes were agreed on the list, I believe this
> version is ready for a publication request.
>
> --Richard
>
>
>
> On Jun 20, 2011, at 2:23 PM, internet-drafts@ietf.org wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Geographic Location/Privacy
>> Working Group of the IETF.
>>
>> Title : Location Configuration Extensions for Policy Management
>> Author(s) : Richard Barnes
>> Martin Thomson
>> James Winterbottom
>> Hannes Tschofenig
>> Filename : draft-ietf-geopriv-policy-uri-01.txt
>> Pages : 17
>> Date : 2011-06-20
>>
>> Current location configuration protocols are capable of provisioning
>> an Internet host with a location URI that refers to the host's
>> location. These protocols lack a mechanism for the target host to
>> inspect or set the privacy rules that are applied to the URIs they
>> distribute. This document extends the current location configuration
>> protocols to provide hosts with a reference to the rules that are
>> applied to a URI, so that the host can view or set these rules.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-01.txt
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
This version addresses comments from last call related to:
-- Multi-protocol support
-- The relationship between policy URIs, location URIs policy documents
-- Policy URI deletion / expiry
-- Several editorial issues.
Since all the significant changes were agreed on the list, I believe this version is ready for a publication request.
--Richard
On Jun 20, 2011, at 2:23 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.
>
> Title : Location Configuration Extensions for Policy Management
> Author(s) : Richard Barnes
> Martin Thomson
> James Winterbottom
> Hannes Tschofenig
> Filename : draft-ietf-geopriv-policy-uri-01.txt
> Pages : 17
> Date : 2011-06-20
>
> Current location configuration protocols are capable of provisioning
> an Internet host with a location URI that refers to the host's
> location. These protocols lack a mechanism for the target host to
> inspect or set the privacy rules that are applied to the URIs they
> distribute. This document extends the current location configuration
> protocols to provide hosts with a reference to the rules that are
> applied to a URI, so that the host can view or set these rules.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-01.txt
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Title : Location Configuration Extensions for Policy Management
Author(s) : Richard Barnes
Martin Thomson
James Winterbottom
Hannes Tschofenig
Filename : draft-ietf-geopriv-policy-uri-01.txt
Pages : 17
Date : 2011-06-20
Current location configuration protocols are capable of provisioning
an Internet host with a location URI that refers to the host's
location. These protocols lack a mechanism for the target host to
inspect or set the privacy rules that are applied to the URIs they
distribute. This document extends the current location configuration
protocols to provide hosts with a reference to the rules that are
applied to a URI, so that the host can view or set these rules.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-01.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-geopriv-policy-uri-01.txt
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
We also reached out to Ted Hardie, who was Applications Area Director and who no longer works at Qualcomm, and confirmed that he also knew nothing about the particular patent. Ted also did not work in the subsidiary that owned the patent, and in any event the patent was developed years before Ted joined Qualcomm.
--Fabian
-----Original Message-----
From: Winterbottom, James [mailto:James.Winterbottom@commscope.com]
Sent: Thursday, June 16, 2011 1:30 PM
To: Gonell, Fabian; John C Klensin; Alan Clark
Cc: Resnick, Pete; geopriv@ietf.org; 'WG Chairs'
Subject: RE: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 4119
Given that Martin Thomson has submitted a great many draft in that time, perhaps you would care to elaborate specifically as to which ones you are referring to?
Regards
James Winterbottom
Global Product Manager
CommScope GeoLENs
IP Location Product Portfolio
Email: james.winterbottom@commscope.com
Phone: +61-2-42-212938
Mobile: +61-447-773-560
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of Gonell, Fabian
> Sent: Friday, 17 June 2011 6:01 AM
> To: John C Klensin; Alan Clark
> Cc: Resnick, Pete; geopriv@ietf.org; 'WG Chairs'
> Subject: Re: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's
> Statement about IPR related to RFC 4119
>
> Pete Resnick brought this mailing list to my attention and I have
> subscribed to it to respond to the recent discussion regarding Qualcomm's
> IPR disclosure related to RFC 4119. I will continue to subscribe through
> the end of June 2011 to respond to any further inquiries on this matter.
> Thereafter, I can be reached at the email address from which I sent this
> message.
>
> The disclosure to RFC 4119 was made in error, and will be withdrawn
> shortly. The particular patent was identified as one that might be
> necessarily infringed by Implementing Technology if one or more drafts
> submitted in 2010 and 2011 by M. Thomson of Andrew Corporation were
> developed into an RFC. RFC 4119 was mistakenly identified as a relevant
> document in our internal disclosure processes and that error was not
> caught before the disclosure was made. We apologize for the confusion.
>
> That said, much of the recent discussion appears to be based on
> misunderstandings of the applicable IETF rules. The applicable IETF rules
> are found in RFC 3979. Disclosure rules are in section 6 of that document.
> Those participating in or following the recent discussion should note the
> following three points.
>
> First, RFC 3979 requires disclosures based on the personal knowledge of
> the participants. See Section 6.1.2:
>
> Any *individual* participating in an IETF discussion who *reasonably
> and
> personally knows* of IPR meeting the conditions of Section 6.6 which
> the individual believes Covers or may ultimately Cover a Contribution
> made by another person, or which such IETF participant reasonably and
> personally knows his or her employer or sponsor may assert against
> Implementing Technologies based on such Contribution, must make a
> disclosure in accordance with this Section 6. (emphasis added)
>
> Second, RFC 3979 specifically and unequivocally states that there is no
> requirement to perform a patent search. See Section 1.l. (stating that
> the term "reasonably and personally known" "should not be interpreted as
> requiring the IETF Contributor or participant (or his or her represented
> organization, if any) to perform a patent search to find applicable IPR").
>
> Third, RFC 3979 specifically contemplates and acknowledges that
> disclosures made after an RFC is published may be timely. See Section
> 6.2.2:
>
> If a participant first learns of IPR that meets the conditions of
> Section 6.6 in a Contribution by another party, for example a new
> patent application or *the discovery of a relevant patent in a patent
> portfolio, after the Contribution was published in an Internet-Draft
> or RFC,* a disclosure must be made as soon as reasonably possible
> after the IPR becomes reasonably and personally known to the
> participant. (emphasis added)
>
> Given the plain text of RFC 3979, the insinuations of wrongdoing in the
> recent discussion are ill founded. I have spoken with Randall Gellens,
> who was one of the WG co-chairs during the relevant time period, and he
> did not know anything about the patent at issue. That is not surprising,
> because the patent was developed by a subsidiary company in which Randall
> did not work at a time when such subsidiary was an independent company not
> yet owned by Qualcomm. Further, Randall's product development
> responsibilities at Qualcomm did not involve position location. We also
> reached out to Ted Hardie, who was Applications Area Director and who no
> longer works at Qualcomm, and confirmed that he also knew nothing about
> the particular patent. Ted also did not work in the subsidiary that owned
> the patent, and in any event the patent was developed years before Ted
> joined Qualcomm.
>
> In light of these facts, the suggestion that this situation was "pretty
> darn close" to one in which the *author* of a draft document is also the
> *named inventor* of a patent disclosed after an RFC was published is
> completely erroneous and, frankly, inappropriate. Nor was this a situation
> in any way analogous to what the FTC alleged with respect to Rambus, a
> matter in which Rambus was alleged to have *refused* to give a RAND
> commitment while Qualcomm's (erroneous) disclosure to RFC 4119 explicitly
> included a RAND commitment to offer licenses. Randall and Ted have given
> years of service to the IETF in general and to this WG in particular.
> They deserve better than to have their good names casually smeared on this
> mailing list.
>
> Fabian Gonell
> QUALCOMM Incorporated
>
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of John C Klensin
> Sent: Wednesday, June 15, 2011 4:59 PM
> To: Alan Clark
> Cc: Resnick, Pete; geopriv@ietf.org; 'WG Chairs'
> Subject: Re: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's
> Statement about IPR related to RFC 4119
>
> Alan,
>
> I'm not defending Qualcomm - I don't know the facts of this
> matter and have no opinion on whether I would defend them if I
> did. However... (inline below)....
>
> --On Wednesday, June 15, 2011 17:07 -0400 Alan Clark
> <alan.d.clark@telchemy.com> wrote:
>
> > Pete
> >
> > Many large companies have substantial patent portfolios and
> > could avoid the disclosure requirements of standards
> > organizations if they could claim that the participants in
> > standards activities were not personally aware of patents that
> > may affect standards under development. IMHO if this were
> > allowed to happen then patent disclosure requirements become
> > completely ineffective.
> >...
>
> Some others have done exactly that before. The rule that you
> prefer is certainly a possible one (but see below). However,
> the IETF's various IPR WGs considered the issue very carefully
> and arrived at the "personal knowledge" requirement, so, in
> commenting about personal knowledge, Pete is merely reflecting
> the way our rules are written.
>
> IANAL, but I understand that there is some case law in which
> judges have taken a dim view of companies organizing themselves
> in ways that seem to have the sole purposes of evading the
> requirements of SDOs or of surfacing submarine patents at times
> that give them unreasonable or unfair advantages.
>
> > In my opinion - any company participating in any standards
> > activity should either:
> >
> > (i) Establish an internal process by which they monitor the
> > standards activities in which they participate and constantly
> > review their patent database for potential applicability
> > (relatively easy given that everything is electronic). If
> > they find a matching patent or application related to an
> > in-process standards activity they should disclose it and
> > state the applicable licensing terms - if the standards
> > activity has already completed then they should waive their
> > right to enforce the patent with reference to the standard.
>
> > (ii) Make a blanket statement to the standards body that they
> > were willing to make licenses available royalty-free with the
> > condition of reciprocity. This avoids the need to track
> > anything and preserves some ability to use patents defensively.
>
> Unfortunately, there is a third possibility, one that companies
> take when they perceive the requirements of a particular SDO or
> consortium are too expensive or otherwise burdensome: they drop
> out and prohibit their employees and others over whom they have
> control from participating. While I think many of us would
> prefer one of the two choices you outline, the possibility of
> the third should continue to make us cautious about too-sweeping
> rules.
>
> john
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Regards
James Winterbottom
Global Product Manager
CommScope GeoLENs
IP Location Product Portfolio
Email: james.winterbottom@commscope.com
Phone: +61-2-42-212938
Mobile: +61-447-773-560
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of Gonell, Fabian
> Sent: Friday, 17 June 2011 6:01 AM
> To: John C Klensin; Alan Clark
> Cc: Resnick, Pete; geopriv@ietf.org; 'WG Chairs'
> Subject: Re: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's
> Statement about IPR related to RFC 4119
>
> Pete Resnick brought this mailing list to my attention and I have
> subscribed to it to respond to the recent discussion regarding Qualcomm's
> IPR disclosure related to RFC 4119. I will continue to subscribe through
> the end of June 2011 to respond to any further inquiries on this matter.
> Thereafter, I can be reached at the email address from which I sent this
> message.
>
> The disclosure to RFC 4119 was made in error, and will be withdrawn
> shortly. The particular patent was identified as one that might be
> necessarily infringed by Implementing Technology if one or more drafts
> submitted in 2010 and 2011 by M. Thomson of Andrew Corporation were
> developed into an RFC. RFC 4119 was mistakenly identified as a relevant
> document in our internal disclosure processes and that error was not
> caught before the disclosure was made. We apologize for the confusion.
>
> That said, much of the recent discussion appears to be based on
> misunderstandings of the applicable IETF rules. The applicable IETF rules
> are found in RFC 3979. Disclosure rules are in section 6 of that document.
> Those participating in or following the recent discussion should note the
> following three points.
>
> First, RFC 3979 requires disclosures based on the personal knowledge of
> the participants. See Section 6.1.2:
>
> Any *individual* participating in an IETF discussion who *reasonably
> and
> personally knows* of IPR meeting the conditions of Section 6.6 which
> the individual believes Covers or may ultimately Cover a Contribution
> made by another person, or which such IETF participant reasonably and
> personally knows his or her employer or sponsor may assert against
> Implementing Technologies based on such Contribution, must make a
> disclosure in accordance with this Section 6. (emphasis added)
>
> Second, RFC 3979 specifically and unequivocally states that there is no
> requirement to perform a patent search. See Section 1.l. (stating that
> the term "reasonably and personally known" "should not be interpreted as
> requiring the IETF Contributor or participant (or his or her represented
> organization, if any) to perform a patent search to find applicable IPR").
>
> Third, RFC 3979 specifically contemplates and acknowledges that
> disclosures made after an RFC is published may be timely. See Section
> 6.2.2:
>
> If a participant first learns of IPR that meets the conditions of
> Section 6.6 in a Contribution by another party, for example a new
> patent application or *the discovery of a relevant patent in a patent
> portfolio, after the Contribution was published in an Internet-Draft
> or RFC,* a disclosure must be made as soon as reasonably possible
> after the IPR becomes reasonably and personally known to the
> participant. (emphasis added)
>
> Given the plain text of RFC 3979, the insinuations of wrongdoing in the
> recent discussion are ill founded. I have spoken with Randall Gellens,
> who was one of the WG co-chairs during the relevant time period, and he
> did not know anything about the patent at issue. That is not surprising,
> because the patent was developed by a subsidiary company in which Randall
> did not work at a time when such subsidiary was an independent company not
> yet owned by Qualcomm. Further, Randall's product development
> responsibilities at Qualcomm did not involve position location. We also
> reached out to Ted Hardie, who was Applications Area Director and who no
> longer works at Qualcomm, and confirmed that he also knew nothing about
> the particular patent. Ted also did not work in the subsidiary that owned
> the patent, and in any event the patent was developed years before Ted
> joined Qualcomm.
>
> In light of these facts, the suggestion that this situation was "pretty
> darn close" to one in which the *author* of a draft document is also the
> *named inventor* of a patent disclosed after an RFC was published is
> completely erroneous and, frankly, inappropriate. Nor was this a situation
> in any way analogous to what the FTC alleged with respect to Rambus, a
> matter in which Rambus was alleged to have *refused* to give a RAND
> commitment while Qualcomm's (erroneous) disclosure to RFC 4119 explicitly
> included a RAND commitment to offer licenses. Randall and Ted have given
> years of service to the IETF in general and to this WG in particular.
> They deserve better than to have their good names casually smeared on this
> mailing list.
>
> Fabian Gonell
> QUALCOMM Incorporated
>
>
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
> Of John C Klensin
> Sent: Wednesday, June 15, 2011 4:59 PM
> To: Alan Clark
> Cc: Resnick, Pete; geopriv@ietf.org; 'WG Chairs'
> Subject: Re: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's
> Statement about IPR related to RFC 4119
>
> Alan,
>
> I'm not defending Qualcomm - I don't know the facts of this
> matter and have no opinion on whether I would defend them if I
> did. However... (inline below)....
>
> --On Wednesday, June 15, 2011 17:07 -0400 Alan Clark
> <alan.d.clark@telchemy.com> wrote:
>
> > Pete
> >
> > Many large companies have substantial patent portfolios and
> > could avoid the disclosure requirements of standards
> > organizations if they could claim that the participants in
> > standards activities were not personally aware of patents that
> > may affect standards under development. IMHO if this were
> > allowed to happen then patent disclosure requirements become
> > completely ineffective.
> >...
>
> Some others have done exactly that before. The rule that you
> prefer is certainly a possible one (but see below). However,
> the IETF's various IPR WGs considered the issue very carefully
> and arrived at the "personal knowledge" requirement, so, in
> commenting about personal knowledge, Pete is merely reflecting
> the way our rules are written.
>
> IANAL, but I understand that there is some case law in which
> judges have taken a dim view of companies organizing themselves
> in ways that seem to have the sole purposes of evading the
> requirements of SDOs or of surfacing submarine patents at times
> that give them unreasonable or unfair advantages.
>
> > In my opinion - any company participating in any standards
> > activity should either:
> >
> > (i) Establish an internal process by which they monitor the
> > standards activities in which they participate and constantly
> > review their patent database for potential applicability
> > (relatively easy given that everything is electronic). If
> > they find a matching patent or application related to an
> > in-process standards activity they should disclose it and
> > state the applicable licensing terms - if the standards
> > activity has already completed then they should waive their
> > right to enforce the patent with reference to the standard.
>
> > (ii) Make a blanket statement to the standards body that they
> > were willing to make licenses available royalty-free with the
> > condition of reciprocity. This avoids the need to track
> > anything and preserves some ability to use patents defensively.
>
> Unfortunately, there is a third possibility, one that companies
> take when they perceive the requirements of a particular SDO or
> consortium are too expensive or otherwise burdensome: they drop
> out and prohibit their employees and others over whom they have
> control from participating. While I think many of us would
> prefer one of the two choices you outline, the possibility of
> the third should continue to make us cautious about too-sweeping
> rules.
>
> john
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Fabian Gonell
QUALCOMM Incorporated
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of John C Klensin
Sent: Wednesday, June 15, 2011 4:59 PM
To: Alan Clark
Cc: Resnick, Pete; geopriv@ietf.org; 'WG Chairs'
Subject: Re: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 4119
Alan,
I'm not defending Qualcomm - I don't know the facts of this
matter and have no opinion on whether I would defend them if I
did. However... (inline below)....
--On Wednesday, June 15, 2011 17:07 -0400 Alan Clark
<alan.d.clark@telchemy.com> wrote:
> Pete
>
> Many large companies have substantial patent portfolios and
> could avoid the disclosure requirements of standards
> organizations if they could claim that the participants in
> standards activities were not personally aware of patents that
> may affect standards under development. IMHO if this were
> allowed to happen then patent disclosure requirements become
> completely ineffective.
>...
Some others have done exactly that before. The rule that you
prefer is certainly a possible one (but see below). However,
the IETF's various IPR WGs considered the issue very carefully
and arrived at the "personal knowledge" requirement, so, in
commenting about personal knowledge, Pete is merely reflecting
the way our rules are written.
IANAL, but I understand that there is some case law in which
judges have taken a dim view of companies organizing themselves
in ways that seem to have the sole purposes of evading the
requirements of SDOs or of surfacing submarine patents at times
that give them unreasonable or unfair advantages.
> In my opinion - any company participating in any standards
> activity should either:
>
> (i) Establish an internal process by which they monitor the
> standards activities in which they participate and constantly
> review their patent database for potential applicability
> (relatively easy given that everything is electronic). If
> they find a matching patent or application related to an
> in-process standards activity they should disclose it and
> state the applicable licensing terms - if the standards
> activity has already completed then they should waive their
> right to enforce the patent with reference to the standard.
> (ii) Make a blanket statement to the standards body that they
> were willing to make licenses available royalty-free with the
> condition of reciprocity. This avoids the need to track
> anything and preserves some ability to use patents defensively.
Unfortunately, there is a third possibility, one that companies
take when they perceive the requirements of a particular SDO or
consortium are too expensive or otherwise burdensome: they drop
out and prohibit their employees and others over whom they have
control from participating. While I think many of us would
prefer one of the two choices you outline, the possibility of
the third should continue to make us cautious about too-sweeping
rules.
john
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I'm not defending Qualcomm - I don't know the facts of this
matter and have no opinion on whether I would defend them if I
did. However... (inline below)....
--On Wednesday, June 15, 2011 17:07 -0400 Alan Clark
<alan.d.clark@telchemy.com> wrote:
> Pete
>
> Many large companies have substantial patent portfolios and
> could avoid the disclosure requirements of standards
> organizations if they could claim that the participants in
> standards activities were not personally aware of patents that
> may affect standards under development. IMHO if this were
> allowed to happen then patent disclosure requirements become
> completely ineffective.
>...
Some others have done exactly that before. The rule that you
prefer is certainly a possible one (but see below). However,
the IETF's various IPR WGs considered the issue very carefully
and arrived at the "personal knowledge" requirement, so, in
commenting about personal knowledge, Pete is merely reflecting
the way our rules are written.
IANAL, but I understand that there is some case law in which
judges have taken a dim view of companies organizing themselves
in ways that seem to have the sole purposes of evading the
requirements of SDOs or of surfacing submarine patents at times
that give them unreasonable or unfair advantages.
> In my opinion - any company participating in any standards
> activity should either:
>
> (i) Establish an internal process by which they monitor the
> standards activities in which they participate and constantly
> review their patent database for potential applicability
> (relatively easy given that everything is electronic). If
> they find a matching patent or application related to an
> in-process standards activity they should disclose it and
> state the applicable licensing terms - if the standards
> activity has already completed then they should waive their
> right to enforce the patent with reference to the standard.
> (ii) Make a blanket statement to the standards body that they
> were willing to make licenses available royalty-free with the
> condition of reciprocity. This avoids the need to track
> anything and preserves some ability to use patents defensively.
Unfortunately, there is a third possibility, one that companies
take when they perceive the requirements of a particular SDO or
consortium are too expensive or otherwise burdensome: they drop
out and prohibit their employees and others over whom they have
control from participating. While I think many of us would
prefer one of the two choices you outline, the possibility of
the third should continue to make us cautious about too-sweeping
rules.
john
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Many large companies have substantial patent portfolios and could avoid the
disclosure requirements of standards organizations if they could claim that
the participants in standards activities were not personally aware of
patents that may affect standards under development. IMHO if this were
allowed to happen then patent disclosure requirements become completely
ineffective.
In my opinion - any company participating in any standards activity should
either:
(i) Establish an internal process by which they monitor the standards
activities in which they participate and constantly review their patent
database for potential applicability (relatively easy given that everything
is electronic). If they find a matching patent or application related to an
in-process standards activity they should disclose it and state the
applicable licensing terms - if the standards activity has already completed
then they should waive their right to enforce the patent with reference to
the standard.
(ii) Make a blanket statement to the standards body that they were willing
to make licenses available royalty-free with the condition of reciprocity.
This avoids the need to track anything and preserves some ability to use
patents defensively.
Alan
On 6/15/11 4:46 PM, "Pete Resnick" <presnick@qualcomm.com> wrote:
> [Resending, Cc'ing chairs]
>
> Folks,
>
> I'm discussing this with people inside of Qualcomm, and I expect we'll
> get an official answer soon. But I did want to let you know at this
> point that as far as I can tell, none of the Qualcomm people who were
> involved in geopriv were aware of the existence this patent before it
> was publicly disclosed to the IETF (nor was I), and I believe the
> disclosure was made as soon as reasonably possible after it was thought
> that the patent might have had anything to do with RFC 4119 (which is
> what anyone with IPR is supposed to do). But again, I'm expecting a more
> official answer soon.
>
> pr
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Folks,
I'm discussing this with people inside of Qualcomm, and I expect we'll
get an official answer soon. But I did want to let you know at this
point that as far as I can tell, none of the Qualcomm people who were
involved in geopriv were aware of the existence this patent before it
was publicly disclosed to the IETF (nor was I), and I believe the
disclosure was made as soon as reasonably possible after it was thought
that the patent might have had anything to do with RFC 4119 (which is
what anyone with IPR is supposed to do). But again, I'm expecting a more
official answer soon.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I'm discussing this with people inside of Qualcomm, and I expect we'll
get an official answer soon. But I did want to let you know at this
point that as far as I can tell, none of the Qualcomm people who were
involved in geopriv were aware of the existence this patent before it
was publicly disclosed to the IETF (nor was I), and I believe the
disclosure was made as soon as reasonably possible after it was thought
that the patent might have had anything to do with RFC 4119 (which is
what anyone with IPR is supposed to do). But again, I'm expecting a more
official answer soon.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
An IPR disclosure that pertains to your Internet-Draft entitled "Using Device-
provided Location-Related Measurements in Location Configuration Protocols"
(draft-ietf-geopriv-held-measurements) was submitted to the IETF Secretariat on
2011-05-27 and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/1563/). The title of the IPR
disclosure is "Qualcomm Incorporated's Statement about IPR related to draft-
ietf-geopriv-held-measurements-03 (2)."");
The IETF Secretariat
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Already seeded with 5 open-source efforts!
--Richard
On Jun 3, 2011, at 3:02 PM, Henning Schulzrinne wrote:
> Does anybody know of DHCP and HELD implementations, particularly in commercial networking equipment? (I'm aware of http://held-location.sourceforge.net/).
>
> Thanks.
>
> Henning
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Thanks.
Henning
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
http://www.pcworld.com/article/109132/rambus_patent_case_could_change_business.html
This particular case and similar ones caused our standards organization (the
OGC) to completely rework our intellectual property policy to insure that
our standards are 1.) unencumbered by any IP and 2.) defensible if anyone
does bring a claim of infringement at a later time. Both OASIS and the W3C
also reworked their IP policies in the same general timeframe.
Carl
----- Original Message -----
From: "Alan Clark" <alan.d.clark@telchemy.com>
To: "James M. Polk" <jmpolk@cisco.com>; "Richard L. Barnes"
<rbarnes@bbn.com>; <geopriv@ietf.org>
Cc: <wgchairs@ietf.org>
Sent: Thursday, June 02, 2011 12:06 PM
Subject: Re: [Geopriv] Fwd: IPR Disclosure: Qualcomm Incorporated's
Statement about IPR related to RFC 4119
>
> Independently from anything the IETF may choose to do (or not), the US
> Federal Trade Commission (www.ftc.gov) sometimes gets involved in matters
> relating to US companies failing to disclose intellectual property related
> to standards activities in which they participate. There have been a
> number
> of cases in which the FTC have penalized the patent holder where it could
> be
> clearly shown the that patent holder participated in the development of a
> standard and failed to disclose the existence of patent rights related to
> the standard.
>
> Alan
>
>
>
> On 6/2/11 1:46 PM, "James M. Polk" <jmpolk@cisco.com> wrote:
>
>> Regardless of the impact, what's this with Qualcomm bringing this IPR
>> declaration 6 years after the document became an RFC *WHILE* being
>> the WG chair of this group at the time of _every_ version of this
>> draft and while the RFC was being published?
>>
>> I believe there were also Qualcomm (employed) contributing members of
>> this WG through the lifecycle of the draft during its creation and
>> editing as well.
>>
>> I believe Qualcomm employed the responsible AD for this WG too at this
>> time.
>>
>> this has me scratching my head wrt the very existence of the NOTE
>> WELL everybody is supposed to live within the IETF.
>>
>> James
>>
>> BTW - I don't know if this is exactly like the ALU case Russ just
>> posted about, but it's pretty darn close, and should seriously be looked
>> at.
>>
>> At 12:34 PM 5/24/2011, Richard L. Barnes wrote:
>>> <hat type="individual"/>
>>>
>>> For your convenience, the referenced patent is titled "Reducing
>>> satellite signal interference in a global positioning system receiver"
>>> <http://www.google.com/patents?id=YqsIAAAAEBAJ>
>>>
>>> As far as I can tell, this has basically no relationship to the data
>>> format defined in RFC 4119. Even if the geolocation fields in a
>>> PIDF-LO document were filled from an infringing GPS receiver, it
>>> would be the receiver that caused the infringement, not the PIDF-LO
>>> encoding.
>>>
>>> --Richard
>>>
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: IETF Secretariat <ietf-ipr@ietf.org>
>>>> Date: May 24, 2011 1:21:11 PM EDT
>>>> To: jon.peterson@neustar.biz
>>>> Cc: gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com,
>>> geopriv@ietf.org, rbarnes@bbn.com, acooper@cdt.org,
>>> ipr-announce@ietf.org, housley@vigilsec.com
>>>> Subject: IPR Disclosure: Qualcomm Incorporated's Statement about
>>> IPR related to RFC 4119
>>>>
>>>> Dear Jon Peterson:
>>>>
>>>> An IPR disclosure that pertains to your RFC entitled "A
>>> Presence-based GEOPRIV
>>>> Location Object Format" (RFC4119) was submitted to the IETF Secretariat
>>>> on
>>>> 2011-05-24 and has been posted on the "IETF Page of Intellectual
>>> Property Rights
>>>> Disclosures" (https://datatracker.ietf.org/ipr/1560/). The title of the
>>>> IPR
>>>> disclosure is "Qualcomm Incorporated's Statement about IPR
>>> related to RFC 4119."
>>>>
>>>> The IETF Secretariat
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Alan
On 6/2/11 1:46 PM, "James M. Polk" <jmpolk@cisco.com> wrote:
> Regardless of the impact, what's this with Qualcomm bringing this IPR
> declaration 6 years after the document became an RFC *WHILE* being
> the WG chair of this group at the time of _every_ version of this
> draft and while the RFC was being published?
>
> I believe there were also Qualcomm (employed) contributing members of
> this WG through the lifecycle of the draft during its creation and
> editing as well.
>
> I believe Qualcomm employed the responsible AD for this WG too at this time.
>
> this has me scratching my head wrt the very existence of the NOTE
> WELL everybody is supposed to live within the IETF.
>
> James
>
> BTW - I don't know if this is exactly like the ALU case Russ just
> posted about, but it's pretty darn close, and should seriously be looked at.
>
> At 12:34 PM 5/24/2011, Richard L. Barnes wrote:
>> <hat type="individual"/>
>>
>> For your convenience, the referenced patent is titled "Reducing
>> satellite signal interference in a global positioning system receiver"
>> <http://www.google.com/patents?id=YqsIAAAAEBAJ>
>>
>> As far as I can tell, this has basically no relationship to the data
>> format defined in RFC 4119. Even if the geolocation fields in a
>> PIDF-LO document were filled from an infringing GPS receiver, it
>> would be the receiver that caused the infringement, not the PIDF-LO encoding.
>>
>> --Richard
>>
>>
>>
>> Begin forwarded message:
>>
>>> From: IETF Secretariat <ietf-ipr@ietf.org>
>>> Date: May 24, 2011 1:21:11 PM EDT
>>> To: jon.peterson@neustar.biz
>>> Cc: gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com,
>> geopriv@ietf.org, rbarnes@bbn.com, acooper@cdt.org,
>> ipr-announce@ietf.org, housley@vigilsec.com
>>> Subject: IPR Disclosure: Qualcomm Incorporated's Statement about
>> IPR related to RFC 4119
>>>
>>> Dear Jon Peterson:
>>>
>>> An IPR disclosure that pertains to your RFC entitled "A
>> Presence-based GEOPRIV
>>> Location Object Format" (RFC4119) was submitted to the IETF Secretariat on
>>> 2011-05-24 and has been posted on the "IETF Page of Intellectual
>> Property Rights
>>> Disclosures" (https://datatracker.ietf.org/ipr/1560/). The title of the IPR
>>> disclosure is "Qualcomm Incorporated's Statement about IPR
>> related to RFC 4119."
>>>
>>> The IETF Secretariat
>>>
>>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
I believe there were also Qualcomm (employed) contributing members of
this WG through the lifecycle of the draft during its creation and
editing as well.
I believe Qualcomm employed the responsible AD for this WG too at this time.
this has me scratching my head wrt the very existence of the NOTE
WELL everybody is supposed to live within the IETF.
James
BTW - I don't know if this is exactly like the ALU case Russ just
posted about, but it's pretty darn close, and should seriously be looked at.
At 12:34 PM 5/24/2011, Richard L. Barnes wrote:
><hat type="individual"/>
>
>For your convenience, the referenced patent is titled "Reducing
>satellite signal interference in a global positioning system receiver"
><http://www.google.com/patents?id=YqsIAAAAEBAJ>
>
>As far as I can tell, this has basically no relationship to the data
>format defined in RFC 4119. Even if the geolocation fields in a
>PIDF-LO document were filled from an infringing GPS receiver, it
>would be the receiver that caused the infringement, not the PIDF-LO encoding.
>
>--Richard
>
>
>
>Begin forwarded message:
>
> > From: IETF Secretariat <ietf-ipr@ietf.org>
> > Date: May 24, 2011 1:21:11 PM EDT
> > To: jon.peterson@neustar.biz
> > Cc: gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com,
> geopriv@ietf.org, rbarnes@bbn.com, acooper@cdt.org,
> ipr-announce@ietf.org, housley@vigilsec.com
> > Subject: IPR Disclosure: Qualcomm Incorporated's Statement about
> IPR related to RFC 4119
> >
> > Dear Jon Peterson:
> >
> > An IPR disclosure that pertains to your RFC entitled "A
> Presence-based GEOPRIV
> > Location Object Format" (RFC4119) was submitted to the IETF Secretariat on
> > 2011-05-24 and has been posted on the "IETF Page of Intellectual
> Property Rights
> > Disclosures" (https://datatracker.ietf.org/ipr/1560/). The title of the IPR
> > disclosure is "Qualcomm Incorporated's Statement about IPR
> related to RFC 4119."
> >
> > The IETF Secretariat
> >
> >
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv