Wednesday, June 30, 2010

[Geopriv] HELD in Firefox

An FYI on implementation:

The first pre-beta version of Firefox 4.0, released today, includes a
minimal version of HELD, as a location provider for the W3C
Geolocation API. The profile of HELD implemented is as follows:
-- Requests have no <locationType>, but they do have a <measurements>
object with a set of WiFi measurements
-- The only responses that are used are ones that contain a
<gs:Circle>, representing a point with an uncertainty radius.
-- Civic addresses and location URIs are not used.

HELD is not enabled by defuault. To use it:
1. Open about:config
2. Set geo.wifi.protocol = 1
3. Set geo.wifi.uri to the URI of a HELD server. For testing, I have
been using <http://geopriv.dreamhosters.com/cgi-bin/lis4.pl>, which
proxies requests through to the Google location server.

Once this is set up, queries to the W3C Geolocation API should
initiate a HELD query to the specified server.

You can download the pre-release builds here:
<http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/>

Finally, of course, this being pre-beta software, there's a minor bug
to fix. Inside the 'components' directory for Firefox, find
NetworkGeolocationProvider.js, and change line 354 from this:
switch (this.protocol) {
to this:
switch (protocol) {
Everything should of course work perfectly :)

--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Monday, June 28, 2010

Re: [Geopriv] Review of draft-thomson-geopriv-held-measurements

Hi Bernard,

On Monday, 28 June 2010 5:33 AM, Bernard Aboba writes:
> Overall, I think this document needs more work.

That's a fair statement. I would hope that there is more review of the sort that you provide here before we request publication.

Your comments are fairly specific - did you have any feedback on sections outside of Section 5?

> […] I assume that the goal is to enable LLDP to be used to determine location in a situation where the devices don't support MED attributes, or where the operator does not want to provision each device with this information, preferring to provision the LIS instead. […]

That's correct. A Device with location from LLDP-MED has little reason to go to a LIS, if all they want is that location. We should elaborate on the use case.

> Since the LLDP-MED MIB enables the sending of traps, there seems to be an assumption that updating the clients to submit the information via HELD would be simpler than updating the LIS to import the same info via SNMP.

Regarding traps, I'd have thought that updating the LIS would be easier than updating the Devices. There's no assumption either way: I wouldn't presume to make that judgement.

Given the security considerations, I'd expect that a LIS would support the traps.

> Also, LLDP is an extensible protocol.  

Extensibility seems to be a general comment you have. So I'll address it generally. Each schema does permit arbitrary extension. There is no extension container specific to each protocol.

We could have provided a generic LLDP extension container, just as we could have for RADIUS or Diameter attributes (or anything else). However, I believe it better to constrain the set of measurements to the ones that have a use case. I personally don't feel that we should provide an open channel for all parameters of these protocols. That should not preclude extension, even extension of the generic sort that I mention, even if I think that more specific measurement sets are more likely to interoperate.

That means that vendor-specific attributes need vendor-specific measurement elements. I don't see that as a major limitation.

> In addition to the information provided in the basic schema, I'm wondering whether it wouldn't also be useful to enable encoding of "Radio Resource Measurement" information from specifications such as IEEE 802.11k.  This could enable encoding of things like the spectral region (relevant for attenuation), rate, etc.

RCPI and RSNI are the only measurements of this type in my copy of 'k. Admittedly, my copy is 2 years old. I'll ask our WiFi positioning guys about this.

> Should I assume that the channel isn't included for the neighbors because they are on the same channel as the "serving WAP"?

Hmm, channel is missing only from the example - it is permitted. I simply forgot to add it to the neighbours when I added it to the example.

> Also, is the RTT measuring the time between a request and a response, or the time between a request and an ACK?

That was a mistake. It should have been the acknowledgement.

Cheers,
Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Fwd: Call for consensus: WG item adoption - HELD Measurement

Are there any public specifications for OMXML that you could point us to?  


On Jun 28, 2010, at 2:02 PM, Carl Reed wrote:

Richard -
 
Yes, I guess that is what I was suggesting. OMXML does allow very lightweight and simple encodings. OMXML allows one to rigorously encode observations and measurements ranging from satellite sensors to simple in building temperature sensors - and everything in between. I am sure that Simon (O&M editor) would be happy to help define any such simple O&M schema or mappings.
 
Cheers

Carl
 
----- Original Message -----
Sent: Monday, June 28, 2010 11:33 AM
Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption - HELD Measurement

Geez, Carl, verbose much?

I agree with your general point that we should keep semantics aligned, but it might make sense to specify a more compact form of the specific measurements needed for positioning.  Sort of how we've now defined GML mappings for the DHCP and GEO URI location formats.

--Richard  


On Jun 28, 2010, at 12:33 PM, Carl Reed wrote:

As the semantics of measurement and observation have been harmonized with OGC/ISO standards, I have no problem with HELD measurement moving forward. That siad, I should add that for future work in which observations and their related properties (such as measure) are to be modeled and encoded, I would encourage the group to consider the OGC Observations and Measurements standards. A revision of the current standard will soon be an ISO standard as an OGC standard. The standard consists of two parts: An abstract model and also the associated encoding schema (OMXML). An example is below.
 
Regards
 
Carl
 
The following could be made simpler but instead includes information about the temperature at the time the observation was produced, information about the processes related to the observation, and so forth.
 
 
 <gml:description>Observation test instance: fruit mass</gml:description>
 <gml:name>Observation test 1</gml:name>
 <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement"/>
 <om:phenomenonTime>
  <gml:TimeInstant
   gml:id="ot1t">
   <gml:timePosition>2005-01-11T16:22:25.00</gml:timePosition>
  </gml:TimeInstant>
 </om:phenomenonTime>
 <om:resultTime xlink:href="#ot1t"/>
 <!-- a notional URL identifying a  procedure ... -->
 <om:procedure
  xlink:href="http://www.example.org/register/process/scales34.xml"/>
 <!-- environmental conditions during measurement -->
 <om:parameter>
  <om:NamedValue>
   <om:name xlink:href="http://sweet.jpl.nasa.gov/ontology/property.owl#Temperature"/>
   <om:value xsi:type="gml:MeasureType" uom="Cel">22.3</om:value>
  </om:NamedValue>
 </om:parameter>
 <!-- a notional URN identifying the observed property -->
 <om:observedProperty
  xlink:href="http://sweet.jpl.nasa.gov/2.0/phys.owl#Mass"/>
 <!-- a notional WFS call identifying the object regarding which the observation was made -->
 <om:featureOfInterest
  xlink:href="http://wfs.example.org?request=getFeature&amp;featureid=fruit37f "/>
 
 <om:result
  xsi:type="gml:MeasureType"
  uom="kg">0.28</om:result>
 <!-- The XML Schema type of the result is indicated using the value of the xsi:type attribute -->
 
</om:OM_Observation>
 
 
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Brian Rosen" <br@brianrosen.net>
Sent: Sunday, June 27, 2010 10:52 PM
Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption

> <hat type="individual"/>
> 
> FWIW, what you're asking w.r.t. -measurements is basically what it  
> already does.  Each measurement type is in its own namespace, as is  
> the measurements container itself.  So in principle, you could re-use  
> these data structure elsewhere.
> 
> Related: I think -measurements is a very high-priority item.  It is  
> needed to bring HELD to feature-parity with some of the most commonly- 
> used location protocols on the Internet (e.g., the Google and Skyhook  
> location protocols).
> 
> 
> 
> On Jun 27, 2010, at 5:07 PM, Brian Rosen wrote:
> 
>> I am in favor of adopting relative location and deref protocol.
>>
>> I am sanguine about -measurements.  I don't think measurements are  
>> tied to a protocol.  So, if I had my druthers, I'd define a protocol  
>> independent mechanism and then define transports of that mechanism  
>> for various protocols.  However, since I don't have cycles available  
>> to do that, and holding up the draft is not reasonable for that  
>> reason, I can't stand in the way of adopting it.
>>
>> Brian
>>
>> On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
>>
>>> We've had very little response to this call for consensus. If you  
>>> have an opinion either way about adopting these three documents as  
>>> working group items, please send it to the list by tomorrow  
>>> (Monday, June 28).
>>>
>>> Thanks,
>>> Alissa
>>>
>>> Begin forwarded message:
>>>
>>>> From: Alissa Cooper <acooper@cdt.org>
>>>> Date: June 22, 2010 12:46:44 PM BST
>>>> To: geopriv@ietf.org
>>>> Subject: [Geopriv] Call for consensus: WG item adoption
>>>>
>>>> Since we've progressed a number of WG items recently, we have  
>>>> space in our queue for some new ones. I'd like to make a call for  
>>>> consensus about adopting the following three documents as GEOPRIV  
>>>> work items:
>>>>
>>>> 1) draft-thomson-geopriv-relative-location-01
>>>> 2) draft-thomson-geopriv-held-measurements-06
>>>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>>>
>>>> These were all among the documents that received expressions of  
>>>> support from the working group at IETF 77 [1]. The top two have  
>>>> been recently revised to address feedback from the meeting, the  
>>>> list, and design team work.
>>>>
>>>> Please send your responses about each document to the list no  
>>>> later than Monday, June 28.
>>>>
>>>> Alissa
>>>>
>>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>



Re: [Geopriv] Fwd: Call for consensus: WG item adoption - HELD Measurement

Richard -
 
Yes, I guess that is what I was suggesting. OMXML does allow very lightweight and simple encodings. OMXML allows one to rigorously encode observations and measurements ranging from satellite sensors to simple in building temperature sensors - and everything in between. I am sure that Simon (O&M editor) would be happy to help define any such simple O&M schema or mappings.
 
Cheers

Carl
 
----- Original Message -----
Sent: Monday, June 28, 2010 11:33 AM
Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption - HELD Measurement

Geez, Carl, verbose much?

I agree with your general point that we should keep semantics aligned, but it might make sense to specify a more compact form of the specific measurements needed for positioning.  Sort of how we've now defined GML mappings for the DHCP and GEO URI location formats.

--Richard  


On Jun 28, 2010, at 12:33 PM, Carl Reed wrote:

As the semantics of measurement and observation have been harmonized with OGC/ISO standards, I have no problem with HELD measurement moving forward. That siad, I should add that for future work in which observations and their related properties (such as measure) are to be modeled and encoded, I would encourage the group to consider the OGC Observations and Measurements standards. A revision of the current standard will soon be an ISO standard as an OGC standard. The standard consists of two parts: An abstract model and also the associated encoding schema (OMXML). An example is below.
 
Regards
 
Carl
 
The following could be made simpler but instead includes information about the temperature at the time the observation was produced, information about the processes related to the observation, and so forth.
 
 
 <gml:description>Observation test instance: fruit mass</gml:description>
 <gml:name>Observation test 1</gml:name>
 <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement"/>
 <om:phenomenonTime>
  <gml:TimeInstant
   gml:id="ot1t">
   <gml:timePosition>2005-01-11T16:22:25.00</gml:timePosition>
  </gml:TimeInstant>
 </om:phenomenonTime>
 <om:resultTime xlink:href="#ot1t"/>
 <!-- a notional URL identifying a  procedure ... -->
 <om:procedure
  xlink:href="http://www.example.org/register/process/scales34.xml"/>
 <!-- environmental conditions during measurement -->
 <om:parameter>
  <om:NamedValue>
   <om:name xlink:href="http://sweet.jpl.nasa.gov/ontology/property.owl#Temperature"/>
   <om:value xsi:type="gml:MeasureType" uom="Cel">22.3</om:value>
  </om:NamedValue>
 </om:parameter>
 <!-- a notional URN identifying the observed property -->
 <om:observedProperty
  xlink:href="http://sweet.jpl.nasa.gov/2.0/phys.owl#Mass"/>
 <!-- a notional WFS call identifying the object regarding which the observation was made -->
 <om:featureOfInterest
  xlink:href="http://wfs.example.org?request=getFeature&amp;featureid=fruit37f "/>
 
 <om:result
  xsi:type="gml:MeasureType"
  uom="kg">0.28</om:result>
 <!-- The XML Schema type of the result is indicated using the value of the xsi:type attribute -->
 
</om:OM_Observation>
 
 
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Brian Rosen" <br@brianrosen.net>
Sent: Sunday, June 27, 2010 10:52 PM
Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption

> <hat type="individual"/>
> 
> FWIW, what you're asking w.r.t. -measurements is basically what it  
> already does.  Each measurement type is in its own namespace, as is  
> the measurements container itself.  So in principle, you could re-use  
> these data structure elsewhere.
> 
> Related: I think -measurements is a very high-priority item.  It is  
> needed to bring HELD to feature-parity with some of the most commonly- 
> used location protocols on the Internet (e.g., the Google and Skyhook  
> location protocols).
> 
> 
> 
> On Jun 27, 2010, at 5:07 PM, Brian Rosen wrote:
> 
>> I am in favor of adopting relative location and deref protocol.
>>
>> I am sanguine about -measurements.  I don't think measurements are  
>> tied to a protocol.  So, if I had my druthers, I'd define a protocol  
>> independent mechanism and then define transports of that mechanism  
>> for various protocols.  However, since I don't have cycles available  
>> to do that, and holding up the draft is not reasonable for that  
>> reason, I can't stand in the way of adopting it.
>>
>> Brian
>>
>> On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
>>
>>> We've had very little response to this call for consensus. If you  
>>> have an opinion either way about adopting these three documents as  
>>> working group items, please send it to the list by tomorrow  
>>> (Monday, June 28).
>>>
>>> Thanks,
>>> Alissa
>>>
>>> Begin forwarded message:
>>>
>>>> From: Alissa Cooper <acooper@cdt.org>
>>>> Date: June 22, 2010 12:46:44 PM BST
>>>> To: geopriv@ietf.org
>>>> Subject: [Geopriv] Call for consensus: WG item adoption
>>>>
>>>> Since we've progressed a number of WG items recently, we have  
>>>> space in our queue for some new ones. I'd like to make a call for  
>>>> consensus about adopting the following three documents as GEOPRIV  
>>>> work items:
>>>>
>>>> 1) draft-thomson-geopriv-relative-location-01
>>>> 2) draft-thomson-geopriv-held-measurements-06
>>>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>>>
>>>> These were all among the documents that received expressions of  
>>>> support from the working group at IETF 77 [1]. The top two have  
>>>> been recently revised to address feedback from the meeting, the  
>>>> list, and design team work.
>>>>
>>>> Please send your responses about each document to the list no  
>>>> later than Monday, June 28.
>>>>
>>>> Alissa
>>>>
>>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

Re: [Geopriv] Fwd: Call for consensus: WG item adoption - HELD Measurement

Geez, Carl, verbose much?

I agree with your general point that we should keep semantics aligned, but it might make sense to specify a more compact form of the specific measurements needed for positioning.  Sort of how we've now defined GML mappings for the DHCP and GEO URI location formats.

--Richard  


On Jun 28, 2010, at 12:33 PM, Carl Reed wrote:

As the semantics of measurement and observation have been harmonized with OGC/ISO standards, I have no problem with HELD measurement moving forward. That siad, I should add that for future work in which observations and their related properties (such as measure) are to be modeled and encoded, I would encourage the group to consider the OGC Observations and Measurements standards. A revision of the current standard will soon be an ISO standard as an OGC standard. The standard consists of two parts: An abstract model and also the associated encoding schema (OMXML). An example is below.
 
Regards
 
Carl
 
The following could be made simpler but instead includes information about the temperature at the time the observation was produced, information about the processes related to the observation, and so forth.
 
 
 <gml:description>Observation test instance: fruit mass</gml:description>
 <gml:name>Observation test 1</gml:name>
 <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement"/>
 <om:phenomenonTime>
  <gml:TimeInstant
   gml:id="ot1t">
   <gml:timePosition>2005-01-11T16:22:25.00</gml:timePosition>
  </gml:TimeInstant>
 </om:phenomenonTime>
 <om:resultTime xlink:href="#ot1t"/>
 <!-- a notional URL identifying a  procedure ... -->
 <om:procedure
  xlink:href="http://www.example.org/register/process/scales34.xml"/>
 <!-- environmental conditions during measurement -->
 <om:parameter>
  <om:NamedValue>
   <om:name xlink:href="http://sweet.jpl.nasa.gov/ontology/property.owl#Temperature"/>
   <om:value xsi:type="gml:MeasureType" uom="Cel">22.3</om:value>
  </om:NamedValue>
 </om:parameter>
 <!-- a notional URN identifying the observed property -->
 <om:observedProperty
  xlink:href="http://sweet.jpl.nasa.gov/2.0/phys.owl#Mass"/>
 <!-- a notional WFS call identifying the object regarding which the observation was made -->
 <om:featureOfInterest
  xlink:href="http://wfs.example.org?request=getFeature&amp;featureid=fruit37f "/>
 
 <om:result
  xsi:type="gml:MeasureType"
  uom="kg">0.28</om:result>
 <!-- The XML Schema type of the result is indicated using the value of the xsi:type attribute -->
 
</om:OM_Observation>
 
 
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Brian Rosen" <br@brianrosen.net>
Sent: Sunday, June 27, 2010 10:52 PM
Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption

> <hat type="individual"/>
> 
> FWIW, what you're asking w.r.t. -measurements is basically what it  
> already does.  Each measurement type is in its own namespace, as is  
> the measurements container itself.  So in principle, you could re-use  
> these data structure elsewhere.
> 
> Related: I think -measurements is a very high-priority item.  It is  
> needed to bring HELD to feature-parity with some of the most commonly- 
> used location protocols on the Internet (e.g., the Google and Skyhook  
> location protocols).
> 
> 
> 
> On Jun 27, 2010, at 5:07 PM, Brian Rosen wrote:
> 
>> I am in favor of adopting relative location and deref protocol.
>>
>> I am sanguine about -measurements.  I don't think measurements are  
>> tied to a protocol.  So, if I had my druthers, I'd define a protocol  
>> independent mechanism and then define transports of that mechanism  
>> for various protocols.  However, since I don't have cycles available  
>> to do that, and holding up the draft is not reasonable for that  
>> reason, I can't stand in the way of adopting it.
>>
>> Brian
>>
>> On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
>>
>>> We've had very little response to this call for consensus. If you  
>>> have an opinion either way about adopting these three documents as  
>>> working group items, please send it to the list by tomorrow  
>>> (Monday, June 28).
>>>
>>> Thanks,
>>> Alissa
>>>
>>> Begin forwarded message:
>>>
>>>> From: Alissa Cooper <acooper@cdt.org>
>>>> Date: June 22, 2010 12:46:44 PM BST
>>>> To: geopriv@ietf.org
>>>> Subject: [Geopriv] Call for consensus: WG item adoption
>>>>
>>>> Since we've progressed a number of WG items recently, we have  
>>>> space in our queue for some new ones. I'd like to make a call for  
>>>> consensus about adopting the following three documents as GEOPRIV  
>>>> work items:
>>>>
>>>> 1) draft-thomson-geopriv-relative-location-01
>>>> 2) draft-thomson-geopriv-held-measurements-06
>>>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>>>
>>>> These were all among the documents that received expressions of  
>>>> support from the working group at IETF 77 [1]. The top two have  
>>>> been recently revised to address feedback from the meeting, the  
>>>> list, and design team work.
>>>>
>>>> Please send your responses about each document to the list no  
>>>> later than Monday, June 28.
>>>>
>>>> Alissa
>>>>
>>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

Re: [Geopriv] Fwd: Call for consensus: WG item adoption - HELD Measurement

As the semantics of measurement and observation have been harmonized with OGC/ISO standards, I have no problem with HELD measurement moving forward. That siad, I should add that for future work in which observations and their related properties (such as measure) are to be modeled and encoded, I would encourage the group to consider the OGC Observations and Measurements standards. A revision of the current standard will soon be an ISO standard as an OGC standard. The standard consists of two parts: An abstract model and also the associated encoding schema (OMXML). An example is below.
 
Regards
 
Carl
 
The following could be made simpler but instead includes information about the temperature at the time the observation was produced, information about the processes related to the observation, and so forth.
 
 
 <gml:description>Observation test instance: fruit mass</gml:description>
 <gml:name>Observation test 1</gml:name>
 <om:type xlink:href="http://www.opengis.net/def/observationType/OGC-OM/2.0/OM_Measurement"/>
 <om:phenomenonTime>
  <gml:TimeInstant
   gml:id="ot1t">
   <gml:timePosition>2005-01-11T16:22:25.00</gml:timePosition>
  </gml:TimeInstant>
 </om:phenomenonTime>
 <om:resultTime xlink:href="#ot1t"/>
 <!-- a notional URL identifying a  procedure ... -->
 <om:procedure
  xlink:href="http://www.example.org/register/process/scales34.xml"/>
 <!-- environmental conditions during measurement -->
 <om:parameter>
  <om:NamedValue>
   <om:name xlink:href="http://sweet.jpl.nasa.gov/ontology/property.owl#Temperature"/>
   <om:value xsi:type="gml:MeasureType" uom="Cel">22.3</om:value>
  </om:NamedValue>
 </om:parameter>
 <!-- a notional URN identifying the observed property -->
 <om:observedProperty
  xlink:href="http://sweet.jpl.nasa.gov/2.0/phys.owl#Mass"/>
 <!-- a notional WFS call identifying the object regarding which the observation was made -->
 <om:featureOfInterest
  xlink:href="http://wfs.example.org?request=getFeature&amp;featureid=fruit37f "/>
 
 <om:result
  xsi:type="gml:MeasureType"
  uom="kg">0.28</om:result>
 <!-- The XML Schema type of the result is indicated using the value of the xsi:type attribute -->
 
</om:OM_Observation>
 
 
----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: "Brian Rosen" <br@brianrosen.net>
Sent: Sunday, June 27, 2010 10:52 PM
Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption

> <hat type="individual"/>
>
> FWIW, what you're asking w.r.t. -measurements is basically what it 
> already does.  Each measurement type is in its own namespace, as is 
> the measurements container itself.  So in principle, you could re-use 
> these data structure elsewhere.
>
> Related: I think -measurements is a very high-priority item.  It is 
> needed to bring HELD to feature-parity with some of the most commonly-
> used location protocols on the Internet (e.g., the Google and Skyhook 
> location protocols).
>
>
>
> On Jun 27, 2010, at 5:07 PM, Brian Rosen wrote:
>
>> I am in favor of adopting relative location and deref protocol.
>>
>> I am sanguine about -measurements.  I don't think measurements are 
>> tied to a protocol.  So, if I had my druthers, I'd define a protocol 
>> independent mechanism and then define transports of that mechanism 
>> for various protocols.  However, since I don't have cycles available 
>> to do that, and holding up the draft is not reasonable for that 
>> reason, I can't stand in the way of adopting it.
>>
>> Brian
>>
>> On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
>>
>>> We've had very little response to this call for consensus. If you 
>>> have an opinion either way about adopting these three documents as 
>>> working group items, please send it to the list by tomorrow 
>>> (Monday, June 28).
>>>
>>> Thanks,
>>> Alissa
>>>
>>> Begin forwarded message:
>>>
>>>> From: Alissa Cooper <acooper@cdt.org>
>>>> Date: June 22, 2010 12:46:44 PM BST
>>>> To: geopriv@ietf.org
>>>> Subject: [Geopriv] Call for consensus: WG item adoption
>>>>
>>>> Since we've progressed a number of WG items recently, we have 
>>>> space in our queue for some new ones. I'd like to make a call for 
>>>> consensus about adopting the following three documents as GEOPRIV 
>>>> work items:
>>>>
>>>> 1) draft-thomson-geopriv-relative-location-01
>>>> 2) draft-thomson-geopriv-held-measurements-06
>>>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>>>
>>>> These were all among the documents that received expressions of 
>>>> support from the working group at IETF 77 [1]. The top two have 
>>>> been recently revised to address feedback from the meeting, the 
>>>> list, and design team work.
>>>>
>>>> Please send your responses about each document to the list no 
>>>> later than Monday, June 28.
>>>>
>>>> Alissa
>>>>
>>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

Alissa,

I'd like to express a vote for adoption of
draft-thomson-geopriv-held-measurements-06 as a WG item.

Thanks

John

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Alissa Cooper
Sent: 27 June 2010 19:31
To: geopriv@ietf.org
Subject: [Geopriv] Fwd: Call for consensus: WG item adoption

We've had very little response to this call for consensus. If you have
an opinion either way about adopting these three documents as working
group items, please send it to the list by tomorrow (Monday, June 28).

Thanks,
Alissa

Begin forwarded message:

> From: Alissa Cooper <acooper@cdt.org>
> Date: June 22, 2010 12:46:44 PM BST
> To: geopriv@ietf.org
> Subject: [Geopriv] Call for consensus: WG item adoption
>
> Since we've progressed a number of WG items recently, we have space in

> our queue for some new ones. I'd like to make a call for consensus
> about adopting the following three documents as GEOPRIV work items:
>
> 1) draft-thomson-geopriv-relative-location-01
> 2) draft-thomson-geopriv-held-measurements-06
> 3) draft-winterbottom-geopriv-deref-protocol-03
>
> These were all among the documents that received expressions of
> support from the working group at IETF 77 [1]. The top two have been
> recently revised to address feedback from the meeting, the list, and
> design team work.
>
> Please send your responses about each document to the list no later
> than Monday, June 28.
>
> Alissa
>
> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>
>
>
> _______________________________________________
> 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

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

On 27 Jun 2010, at 19:30, Alissa Cooper wrote:

> We've had very little response to this call for consensus. If you have an opinion either way about adopting these three documents as working group items, please send it to the list by tomorrow (Monday, June 28).

I support the adoption of all three.

Ray

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Sunday, June 27, 2010

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

I support the adoption of the first two, I don't care about the third one.

- gabor

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of ext Alissa Cooper
Sent: Sunday, June 27, 2010 11:31 AM
To: geopriv@ietf.org
Subject: [Geopriv] Fwd: Call for consensus: WG item adoption

We've had very little response to this call for consensus. If you have
an opinion either way about adopting these three documents as working
group items, please send it to the list by tomorrow (Monday, June 28).

Thanks,
Alissa

Begin forwarded message:

> From: Alissa Cooper <acooper@cdt.org>
> Date: June 22, 2010 12:46:44 PM BST
> To: geopriv@ietf.org
> Subject: [Geopriv] Call for consensus: WG item adoption
>
> Since we've progressed a number of WG items recently, we have space
> in our queue for some new ones. I'd like to make a call for
> consensus about adopting the following three documents as GEOPRIV
> work items:
>
> 1) draft-thomson-geopriv-relative-location-01
> 2) draft-thomson-geopriv-held-measurements-06
> 3) draft-winterbottom-geopriv-deref-protocol-03
>
> These were all among the documents that received expressions of
> support from the working group at IETF 77 [1]. The top two have been
> recently revised to address feedback from the meeting, the list, and
> design team work.
>
> Please send your responses about each document to the list no later
> than Monday, June 28.
>
> Alissa
>
> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>
>
>
> _______________________________________________
> 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

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

As evident the author list on the drafts, I'm strongly in support of all. I'll happily acknowledge that more work is needed, but that's certainly no barrier to adoption.


In response to Brian's reservations on -measurements: Looks like Richard beat me to it :)

If you ignore the draft name, -measurements is purposely written in a protocol-ambivalent fashion, with the only assumption being that there is some form of request-response semantics. There are examples for HELD, that's the only protocol-specific part.

It's been like that for a while. Marc Linsner requested that we avoid protocol-specific ages back.

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Richard L. Barnes
> Sent: Monday, 28 June 2010 2:53 PM
> To: Brian Rosen
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] Fwd: Call for consensus: WG item adoption
>
> <hat type="individual"/>
>
> FWIW, what you're asking w.r.t. -measurements is basically what it
> already does. Each measurement type is in its own namespace, as is
> the measurements container itself. So in principle, you could re-use
> these data structure elsewhere.
>
> Related: I think -measurements is a very high-priority item. It is
> needed to bring HELD to feature-parity with some of the most commonly-
> used location protocols on the Internet (e.g., the Google and Skyhook
> location protocols).
>
>
>
> On Jun 27, 2010, at 5:07 PM, Brian Rosen wrote:
>
> > I am in favor of adopting relative location and deref protocol.
> >
> > I am sanguine about -measurements. I don't think measurements are
> > tied to a protocol. So, if I had my druthers, I'd define a protocol
> > independent mechanism and then define transports of that mechanism
> > for various protocols. However, since I don't have cycles available
> > to do that, and holding up the draft is not reasonable for that
> > reason, I can't stand in the way of adopting it.
> >
> > Brian
> >
> > On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
> >
> >> We've had very little response to this call for consensus. If you
> >> have an opinion either way about adopting these three documents as
> >> working group items, please send it to the list by tomorrow
> >> (Monday, June 28).
> >>
> >> Thanks,
> >> Alissa
> >>
> >> Begin forwarded message:
> >>
> >>> From: Alissa Cooper <acooper@cdt.org>
> >>> Date: June 22, 2010 12:46:44 PM BST
> >>> To: geopriv@ietf.org
> >>> Subject: [Geopriv] Call for consensus: WG item adoption
> >>>
> >>> Since we've progressed a number of WG items recently, we have
> >>> space in our queue for some new ones. I'd like to make a call for
> >>> consensus about adopting the following three documents as GEOPRIV
> >>> work items:
> >>>
> >>> 1) draft-thomson-geopriv-relative-location-01
> >>> 2) draft-thomson-geopriv-held-measurements-06
> >>> 3) draft-winterbottom-geopriv-deref-protocol-03
> >>>
> >>> These were all among the documents that received expressions of
> >>> support from the working group at IETF 77 [1]. The top two have
> >>> been recently revised to address feedback from the meeting, the
> >>> list, and design team work.
> >>>
> >>> Please send your responses about each document to the list no
> >>> later than Monday, June 28.
> >>>
> >>> Alissa
> >>>
> >>> [1] http://www.ietf.org/mail-
> archive/web/geopriv/current/msg08428.html
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> 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

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

<hat type="individual"/>

FWIW, what you're asking w.r.t. -measurements is basically what it
already does. Each measurement type is in its own namespace, as is
the measurements container itself. So in principle, you could re-use
these data structure elsewhere.

Related: I think -measurements is a very high-priority item. It is
needed to bring HELD to feature-parity with some of the most commonly-
used location protocols on the Internet (e.g., the Google and Skyhook
location protocols).

On Jun 27, 2010, at 5:07 PM, Brian Rosen wrote:

> I am in favor of adopting relative location and deref protocol.
>
> I am sanguine about -measurements. I don't think measurements are
> tied to a protocol. So, if I had my druthers, I'd define a protocol
> independent mechanism and then define transports of that mechanism
> for various protocols. However, since I don't have cycles available
> to do that, and holding up the draft is not reasonable for that
> reason, I can't stand in the way of adopting it.
>
> Brian
>
> On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
>
>> We've had very little response to this call for consensus. If you
>> have an opinion either way about adopting these three documents as
>> working group items, please send it to the list by tomorrow
>> (Monday, June 28).
>>
>> Thanks,
>> Alissa
>>
>> Begin forwarded message:
>>
>>> From: Alissa Cooper <acooper@cdt.org>
>>> Date: June 22, 2010 12:46:44 PM BST
>>> To: geopriv@ietf.org
>>> Subject: [Geopriv] Call for consensus: WG item adoption
>>>
>>> Since we've progressed a number of WG items recently, we have
>>> space in our queue for some new ones. I'd like to make a call for
>>> consensus about adopting the following three documents as GEOPRIV
>>> work items:
>>>
>>> 1) draft-thomson-geopriv-relative-location-01
>>> 2) draft-thomson-geopriv-held-measurements-06
>>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>>
>>> These were all among the documents that received expressions of
>>> support from the working group at IETF 77 [1]. The top two have
>>> been recently revised to address feedback from the meeting, the
>>> list, and design team work.
>>>
>>> Please send your responses about each document to the list no
>>> later than Monday, June 28.
>>>
>>> Alissa
>>>
>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

Hi Alissa,

I think all of these should become WG items.

Regards,
Martin Dawson

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Alissa Cooper
Sent: Monday, 28 June 2010 4:31 AM
To: geopriv@ietf.org
Subject: [Geopriv] Fwd: Call for consensus: WG item adoption

We've had very little response to this call for consensus. If you have
an opinion either way about adopting these three documents as working
group items, please send it to the list by tomorrow (Monday, June 28).

Thanks,
Alissa

Begin forwarded message:

> From: Alissa Cooper <acooper@cdt.org>
> Date: June 22, 2010 12:46:44 PM BST
> To: geopriv@ietf.org
> Subject: [Geopriv] Call for consensus: WG item adoption
>
> Since we've progressed a number of WG items recently, we have space
> in our queue for some new ones. I'd like to make a call for
> consensus about adopting the following three documents as GEOPRIV
> work items:
>
> 1) draft-thomson-geopriv-relative-location-01
> 2) draft-thomson-geopriv-held-measurements-06
> 3) draft-winterbottom-geopriv-deref-protocol-03
>
> These were all among the documents that received expressions of
> support from the working group at IETF 77 [1]. The top two have been
> recently revised to address feedback from the meeting, the list, and
> design team work.
>
> Please send your responses about each document to the list no later
> than Monday, June 28.
>
> Alissa
>
> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>
>
>
> _______________________________________________
> 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

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

I agree with adopting relative location.

allan

On 6/27/10 2:07 PM, "Brian Rosen" <br@brianrosen.net> wrote:

> I am in favor of adopting relative location and deref protocol.
>
> I am sanguine about -measurements. I don't think measurements are tied to a
> protocol. So, if I had my druthers, I'd define a protocol independent
> mechanism and then define transports of that mechanism for various protocols.
> However, since I don't have cycles available to do that, and holding up the
> draft is not reasonable for that reason, I can't stand in the way of adopting
> it.
>
> Brian
>
> On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:
>
>> We've had very little response to this call for consensus. If you have an
>> opinion either way about adopting these three documents as working group
>> items, please send it to the list by tomorrow (Monday, June 28).
>>
>> Thanks,
>> Alissa
>>
>> Begin forwarded message:
>>
>>> From: Alissa Cooper <acooper@cdt.org>
>>> Date: June 22, 2010 12:46:44 PM BST
>>> To: geopriv@ietf.org
>>> Subject: [Geopriv] Call for consensus: WG item adoption
>>>
>>> Since we've progressed a number of WG items recently, we have space in our
>>> queue for some new ones. I'd like to make a call for consensus about
>>> adopting the following three documents as GEOPRIV work items:
>>>
>>> 1) draft-thomson-geopriv-relative-location-01
>>> 2) draft-thomson-geopriv-held-measurements-06
>>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>>
>>> These were all among the documents that received expressions of support from
>>> the working group at IETF 77 [1]. The top two have been recently revised to
>>> address feedback from the meeting, the list, and design team work.
>>>
>>> Please send your responses about each document to the list no later than
>>> Monday, June 28.
>>>
>>> Alissa
>>>
>>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

I am in favor of adopting relative location and deref protocol.

I am sanguine about -measurements. I don't think measurements are tied to a protocol. So, if I had my druthers, I'd define a protocol independent mechanism and then define transports of that mechanism for various protocols. However, since I don't have cycles available to do that, and holding up the draft is not reasonable for that reason, I can't stand in the way of adopting it.

Brian

On Jun 27, 2010, at 2:30 PM, Alissa Cooper wrote:

> We've had very little response to this call for consensus. If you have an opinion either way about adopting these three documents as working group items, please send it to the list by tomorrow (Monday, June 28).
>
> Thanks,
> Alissa
>
> Begin forwarded message:
>
>> From: Alissa Cooper <acooper@cdt.org>
>> Date: June 22, 2010 12:46:44 PM BST
>> To: geopriv@ietf.org
>> Subject: [Geopriv] Call for consensus: WG item adoption
>>
>> Since we've progressed a number of WG items recently, we have space in our queue for some new ones. I'd like to make a call for consensus about adopting the following three documents as GEOPRIV work items:
>>
>> 1) draft-thomson-geopriv-relative-location-01
>> 2) draft-thomson-geopriv-held-measurements-06
>> 3) draft-winterbottom-geopriv-deref-protocol-03
>>
>> These were all among the documents that received expressions of support from the working group at IETF 77 [1]. The top two have been recently revised to address feedback from the meeting, the list, and design team work.
>>
>> Please send your responses about each document to the list no later than Monday, June 28.
>>
>> Alissa
>>
>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>>
>>
>>
>> _______________________________________________
>> 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

[Geopriv] Review of draft-thomson-geopriv-held-measurements

Overall, I think this document needs more work.

Section 5.1

This section needs some additional text explaining the usage scenarios.

In a situation where an LLDP node includes location information (e.g. MED TLVs), it would seem odd to disregard that location information and instead request the LIS to determine location based on "measurement info".  Given this, I assume that the goal is to enable LLDP to be used to determine location in a situation where the devices don't support MED attributes, or where the operator does not want to provision each device with this information, preferring to provision the LIS instead.  Since the LLDP-MED MIB enables the sending of traps, there seems to be an assumption that updating the clients to submit the information via HELD would be simpler than updating the LIS to import the same info via SNMP. 

Also, LLDP is an extensible protocol.   On reading this section, I was unclear whether the schema was capable of including arbitrary LLDP TLVs, including vendor-specific ones.

Section 5.3

In addition to the information provided in the basic schema, I'm wondering whether it wouldn't also be useful to enable encoding of "Radio Resource Measurement" information from specifications such as IEEE 802.11k.  This could enable encoding of things like the spectral region (relevant for attenuation), rate, etc.

Should I assume that the channel isn't included for the neighbors because they are on the same channel as the "serving WAP"?

Also, is the RTT measuring the time between a request and a response, or the time between a request and an ACK?

Section 5.6.1

L2TP is an extensible protocol. In some cases, relevant measurement info is provided in vendor-specific attributes.  On reading this section, I was unclear whether the schema was capable of including arbitrary L2TP attributes.

Section 5.6.2

RADIUS is also an extensible protocol.  In some cases, relevant measurement info is provided in vendor-specific attributes.  On reading this section, I was unclear whether the schema was capable of including arbitrary RADIUS attributes.

Re: [Geopriv] Fwd: Call for consensus: WG item adoption

IMHO, draft-winterbottom-geopriv-deref-protocol addresses an important need -- for a specification to define how HELD is used to de-reference a location URI. 

[Geopriv] Fwd: Call for consensus: WG item adoption

We've had very little response to this call for consensus. If you have
an opinion either way about adopting these three documents as working
group items, please send it to the list by tomorrow (Monday, June 28).

Thanks,
Alissa

Begin forwarded message:

> From: Alissa Cooper <acooper@cdt.org>
> Date: June 22, 2010 12:46:44 PM BST
> To: geopriv@ietf.org
> Subject: [Geopriv] Call for consensus: WG item adoption
>
> Since we've progressed a number of WG items recently, we have space
> in our queue for some new ones. I'd like to make a call for
> consensus about adopting the following three documents as GEOPRIV
> work items:
>
> 1) draft-thomson-geopriv-relative-location-01
> 2) draft-thomson-geopriv-held-measurements-06
> 3) draft-winterbottom-geopriv-deref-protocol-03
>
> These were all among the documents that received expressions of
> support from the working group at IETF 77 [1]. The top two have been
> recently revised to address feedback from the meeting, the list, and
> design team work.
>
> Please send your responses about each document to the list no later
> than Monday, June 28.
>
> Alissa
>
> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html
>
>
>
> _______________________________________________
> 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

Thursday, June 24, 2010

[Geopriv] Fwd: Nomcom 2010-2011: Call for Volunteers

FYI, Nomcom is looking for volunteers.

>> From: NomCom Chair <nomcom-chair@ietf.org>
>> Date: June 21, 2010 5:49:08 PM EDT
>> To: IETF Announcement list <ietf-announce@ietf.org>
>> Subject: Nomcom 2010-2011: Second Call for Volunteers
>>
>> Hi all,
>>
>> This is the Second call for Volunteers for the 2010-11 nomcom. We
>> are
>> just about halfway through the volunteer period so if you are
>> considering
>> volunteering please do so very soon.
>>
>> I am pleased to report that we have 29 volunteers thus far whose
>> qualifications have been confirmed by the secretariat. I have
>> notified
>> each of these volunteers by email.
>>
>> If you volunteered before 08:00 PDT (15:00 UTC) 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!
>>
>> However, we need many more volunteers. You have until 17:00 PDT
>> (24:00
>> UTC) on July 8, 2010 to volunteer for nomcom but it is much better
>> if you
>> volunteer as early as possible. The more volunteers, the better
>> chance we
>> have of choosing a random yet representative cross section of the
>> IETF
>> pouplation.
>>
>> As a reminder, volunteers must have attended 3 of the past 5 IETF
>> meetings - per RFC 3777, which means 3 of the following meetings:
>> IETF-73,
>> IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are
>> willing to
>> forgo appointment to any of the positions for which the nominating
>> committee is responsible, please volunteer.
>>
>> The 10 nominating committee members are selected randomly from a
>> pool of
>> volunteers. The details of the operation of nomcom may be found in
>> RFC
>> 3777. The process on how to volunteer for nomcom is in the initial
>> announcement: https://datatracker.ietf.org/ann/nomcom/2330/
>>
>> The lists of open positions and people whose terms end in March 2011
>> and
>> thus the positions for which the nominating committee is responsible
>> are
>> summarized in the initial announcement:
>> https://datatracker.ietf.org/ann/nomcom/2330/
>>
>> The 29 volunteers who have thus far been qualified by the secretariat
>> are:
>>
>> Fred Baker, Cisco Systems
>>
>> Stephan Wenger, Vidyo, Inc.
>>
>> Marc Blanchet, Viagenie
>>
>> Lixia Zhang, UCLA
>>
>> John Drake, Juniper Networks
>>
>> Ole Troan, Cisco
>>
>> Jiankang Yao, CNNIC
>>
>> Wassim Haddad, Ericsson
>>
>> Yi Zhao, Huawei USA
>>
>> Teemu Savolainen, Nokia
>>
>> Jouni Korhonen, Nokia Siemens Networks
>>
>> Mehmet Ersue, Nokia Siemens Networks
>>
>> Christian Schmidt, Nokia Siemens Networks
>>
>> Stephen Hanna, Juniper Networks
>>
>> Suresh Krishnan, Ericsson
>>
>> Eric Gray, Ericsson
>>
>> David Sinicrope, Ericsson
>>
>> Jan Melen, Ericsson
>>
>> Richard Barnes, BBN Technologies
>>
>> Hugo Salgado Hernandez, NIC Chile
>>
>> Ning Zong, Huawei Technologies
>>
>> Qin Wu, Huawei Technologies
>>
>> Karen Seo, BBN Technologies
>>
>> Haibin Song, Huawei Technologies
>>
>> Susan Hares, Huawei Technologies
>>
>> Tony Hansen. AT&T Labs
>>
>> Fuqing Huang, Huawei Technologies Co., Ltd.
>>
>> Huub van Helvoort, Huawei Technologies
>>
>> Miya Kohno, Juniper Networks
>>
>> The primary activity for this nomcom will begin just prior to
>> IETF-78 in
>> Maastricht and should be completed in early January 2011. The
>> nomcom will
>> be collecting requirements from the community, as well as talking to
>> candidates and to community members about candidates. There will be
>> weekly
>> conference calls to ensure progress. Thus, being a nomcom member does
>> require some time commitment.
>>
>> While, there is no requirement in RFC 3777 that a participant attend
>> IETF
>> meetings while serving on nomcom, please consider that during the
>> IETF
>> meetings, people that do not attend would be expected to remotely
>> participate during the day in the time zones of the meeting
>> locations -
>> Maastricht at the end of July and Beijing in November.
>>
>> 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.
>>
>> Please volunteer by sending an email before:
>> 17:00 PDT (24:00 UTC) July 8, 2010 as follows:
>>
>> To: nomcom-chair@ietf.org
>> Subject: Nomcom 2010-11 Volunteer
>>
>> Please include the following information in the body:
>>
>> <Your 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
>>
>> [<all email addresses used to Register for the past 5 IETF meetings>]
>> <Preferred email address> //
>>
>> <Telephone number> // For confirmation if selected
>>
>> Please expect an email response from me within 3 days stating
>> whether or
>> not you are qualified. If you don't receive a response, please re-
>> send
>> your email with the tag "Duplicate:" added to the subject line.
>>
>> Thank you and I hope to hear from you,
>>
>> Thomas Walsh
>> Chair, Nomcom 2010-11
>> Email: nomcom-chair@ietf.org
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>
>
>
>


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, June 22, 2010

[Geopriv] Fwd: Nomcom 2010-2011: Second Call for Volunteers

In case people haven't heard the call for NOMCOM volunteers...

Begin forwarded message:

From: NomCom Chair <nomcom-chair@ietf.org>
Date: June 21, 2010 5:49:08 PM EDT
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: Nomcom 2010-2011: Second Call for Volunteers 

Hi all,

This is the Second call for Volunteers for the 2010-11 nomcom.  We are
just about halfway through the volunteer period so if you are considering
volunteering please do so very soon.

I am pleased to report that we have 29 volunteers thus far whose
qualifications have been confirmed by the secretariat. I have notified
each of these volunteers by email.  

If you volunteered before 08:00 PDT (15:00 UTC) 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!

However, we need many more volunteers.  You have until 17:00 PDT (24:00
UTC) on July 8, 2010 to volunteer for nomcom but it is much better if you
volunteer as early as possible.  The more volunteers, the better chance we
have of choosing a random yet representative cross section of the IETF
pouplation.   

As a reminder, volunteers must have attended 3 of the past 5 IETF
meetings - per RFC 3777, which means 3 of the following meetings: IETF-73,
IETF-74, IETF-75, IETF-76 and IETF-77.  If you qualify, and are willing to
forgo appointment to any of the positions for which the nominating
committee is responsible, please volunteer.  

The 10 nominating committee members are selected randomly from a pool of
volunteers.  The details of the operation of nomcom may be found in RFC
3777.  The process on how to volunteer for nomcom is in the initial
announcement:  https://datatracker.ietf.org/ann/nomcom/2330/

The lists of open positions and people whose terms end in March 2011 and
thus the positions for which the nominating committee is responsible are
summarized in the initial announcement:
https://datatracker.ietf.org/ann/nomcom/2330/

The 29 volunteers who have thus far been qualified by the secretariat
are:

Fred Baker, Cisco Systems

Stephan Wenger, Vidyo, Inc.

Marc Blanchet, Viagenie

Lixia Zhang, UCLA

John Drake, Juniper Networks

Ole Troan, Cisco

Jiankang Yao, CNNIC

Wassim Haddad, Ericsson

Yi Zhao, Huawei USA

Teemu Savolainen, Nokia

Jouni Korhonen, Nokia Siemens Networks

Mehmet Ersue, Nokia Siemens Networks

Christian Schmidt, Nokia Siemens Networks

Stephen Hanna, Juniper Networks

Suresh Krishnan, Ericsson

Eric Gray, Ericsson

David Sinicrope, Ericsson

Jan Melen, Ericsson

Richard Barnes, BBN Technologies

Hugo Salgado Hernandez, NIC Chile

Ning Zong, Huawei Technologies

Qin Wu, Huawei Technologies

Karen Seo, BBN Technologies

Haibin Song, Huawei Technologies

Susan Hares, Huawei Technologies

Tony Hansen. AT&T Labs

Fuqing Huang, Huawei Technologies Co., Ltd.

Huub van Helvoort, Huawei Technologies

Miya Kohno, Juniper Networks

The primary activity for this nomcom will begin just prior to IETF-78 in
Maastricht and should be completed in early January 2011.  The nomcom will
be collecting requirements from the community, as well as talking to
candidates and to community members about candidates. There will be weekly
conference calls to ensure progress. Thus, being a nomcom member does
require some time commitment.  

While, there is no requirement in RFC 3777 that a participant attend IETF
meetings while serving on nomcom, please consider that during the IETF
meetings, people that do not attend would be expected to remotely
participate during the day in the time zones of the meeting locations -
Maastricht at the end of July and Beijing in November.

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.

Please volunteer by sending an email before:
17:00 PDT (24:00 UTC) July 8, 2010 as follows:

To: nomcom-chair@ietf.org
Subject: Nomcom 2010-11 Volunteer

Please include the following information in the body:

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

[<all email addresses used to Register for the past 5 IETF meetings>]
<Preferred email address>  //

<Telephone number>         // For confirmation if selected

Please expect an email response from me within 3 days stating whether or
not you are qualified.  If you don't receive a response, please re-send
your email with the tag "Duplicate:" added to the subject line.

Thank you and I hope to hear from you,

Thomas Walsh
Chair, Nomcom 2010-11
Email: nomcom-chair@ietf.org


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce