[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-17.txt

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 : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information
Author(s) : J. Polk, et al.
Filename : draft-ietf-geopriv-rfc3825bis-17.txt
Pages : 35
Date : 2011-02-26

This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
Latitude, Longitude, and Altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values. This document obsoletes RFC 3825.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-17.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] [geopriv] #47: IETF Last Call Comments from Mykyta Yevstifeyev (evnikita2@gmail.com)

#47: IETF Last Call Comments from Mykyta Yevstifeyev (evnikita2@gmail.com)

Changes (by bernard_aboba@…):

* status: new => closed
* resolution: => fixed

Comment:

RFC 5226 has been added as a normative reference, as has [RFC2939]. The
IANA Considerations section now reads as follows:

4. IANA Considerations

4.1. DHCP Options

This document defines the DHCPv6 GeoLoc option (see Section 2.1)
which requires assignment of DHCPv6 option code TBD2 [RFC3315]:

Value Description Reference
---- ------------------ ----------
TBD2 OPTION_GEOLOCATION RFC xxxx
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]

This document defines the DHCPv4 GeoConf option (see Section 2.2.1)
which has been assigned a DHCPv4 option code of 123 from the DHCP
Option space.

This document also defines the DHCPv4 GeoLoc option (see Section
2.2.2) which requires assignment of DHCPv4 option code TBD1
[RFC2132][RFC2939]:

Data
Tag Name Length Meaning Reference
---- ---- ------ ------- ---------
TBD1 GeoLoc 16 Geospatial Location RFC xxxx
with Uncertainty
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]

4.2. Altitude Type Registry

IANA is asked to create and maintain the Altitude Type registry
following the guidelines below.

The registry consists of three values: Altitude Type, Description
and Reference. These are described below.

Altitude Type: an integer, refers to the value used in the DHCPv4
GeoConf and the DHCPv4 and DHCPv6 GeoLoc Options described in this
document. Values from 0 to 15 are assigned.

Description: the description of the altitude described by this code.

Reference: the reference to the document that describes the altitude
code. This reference MUST define the way that the 30 bit altitude
values and the associated 6 bit uncertainty are interpreted.

Initial values are given below; new assignments are to be made
following the "Standards Action" policies [RFC5226].

+------+---------------------+--------------+
| # | Description | Reference |
+------+---------------------+--------------+
| 0 | No known altitude | RFC xxxx |
| 1 | Altitude in meters | RFC xxxx |
| 2 | Altitude in floors | RFC xxxx |
| 3-15 | Unassigned | RFC xxxx |
+------+---------------------+--------------+
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]

4.3. Datum Registry

IANA is asked to create and maintain the Datum registry following the
guidelines below.

The registry consists of three values: Datum, Description and
Reference. These are described below.

Datum: an integer, refers to the value used in the DHCPv4 GeoConf and
the DHCPv4 and DHCPv6 GeoLoc Options described in this document.
Values from 1 to 7 are assigned.

Description: the description of the altitude described by this code.

Reference: the reference to the document that describes the Datum
code. This reference MUST include specification of both the
horizontal and vertical datum, and MUST define the way that the 34
bit values and the respective 6 bit uncertainties are interpreted.

Initial values are given below; new assignments are to be made
following the "Standards Action" policies [RFC5226].

+------+---------------------------------------+--------------+
| # | Description | Reference |
+------+---------------------------------------+--------------+
| 0 | Reserved | RFC xxxx |
+------+---------------------------------------+--------------+
| 1 | Vertical datum WGS 84 defined by EPSG | RFC xxxx |
| | CRS Code 4327 | |
+------+---------------------------------------+--------------+
| 2 | Vertical datum NAD83 defined by EPSG | RFC xxxx |
| | CRS Code 4269 with North American | |
| | Vertical Datum of 1988 (NAVD88) | |
+------+---------------------------------------+--------------+
| 3 | Vertical datum NAD83, defined by EPSG | RFC xxxx |
| | CRS Code 4269 withMean Lower Low Water| |
| | (MLLW) as associated vertical datum | |
+------+---------------------------------------+--------------+
| 4-7 | Unassigned | RFC xxxx |
+------+---------------------------------------+--------------+
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]

4.4. GeoLoc Option Version Registry

IANA is asked to create and maintain the GeoLoc Version registry
following the guidelines below.

The registry consists of three values: GeoLoc Version, Description
and Reference. These are described below.

GeoLoc Version: an integer, refers to the version used in the DHCPv4
and DHCPv6 GeoLoc Options described in this document. Values from 1
to 3 are assigned.

Description: the description of the version described by this code.

Reference: the reference to the document that describes the Version
code.

Initial values are given below; new assignments are to be made
following the "Standards Action" policies [RFC5226].

+------+---------------------------------------+--------------+
| # | Description | Reference |
+------+---------------------------------------+--------------+
| 0 | Reserved | RFC xxxx |
+------+---------------------------------------+--------------+
| 1 | Implementatinos utilizing uncertainty | RFC xxxx |
| | parameters for both DHCPv4 and DHCPv6 | |
| | GeoLoc options | |
+------+---------------------------------------+--------------+
| 2-3 | Unassigned | RFC xxxx |
+------+---------------------------------------+--------------+
[RFC Editor: Please replace xxxx with the RFC number
assigned to this document.]

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: closed
Priority: minor | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Resolution: fixed
Keywords: |
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/47#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

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

Re: [Geopriv] Consensus call: Civic extensions

Thanks all, looks like we have consensus on these items.

Alissa

On Jan 31, 2011, at 3:02 PM, Richard L. Barnes wrote:

> Hey all,
>
> The chairs would like to get a sense of the working group for a plan
> for a group of civic-address-related issues.
>
> -- Request a milestone for civic address extensibility
> Dec 2012 - Submit recommendations for civic address extensions as PS
>
> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for
> this milestone
>
> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-
> post-00 into the milestone draft.
>
> Please send comments on this proposal to the list by Monday, 7 Feb
> 2011.
>
> Thanks,
> --Richard
> _______________________________________________
> 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] I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-11.txt

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 : Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
Author(s) : J. Polk
Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-11.txt
Pages : 13
Date : 2011-02-11

This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends
this URI to.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-11.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt

At 03:43 PM 2/11/2011, Richard L. Barnes wrote:
>"The LuriValue of LuriType=2 is always represented as an integer."
>
>This is insufficiently specified.

fair point

>How long is this integer? Signed or unsigned? Suggested text:
>
>"The LuriValue of LuriType=2 is always represented as a four-byte
>unsigned integer."

ok

look for a ver -11 in the next hour. I'll submit it within a few minutes

james

>(We should not use an indefinite-length integer; that's
>unnecessarily hard. If somebody wants a location URI that's good
>for more than 136 years, they can renew their DHCP lease. Two
>octets is probably too short, since it's less than a day; three
>octets is weird. Hence four. Unsigned because negative seconds are
>useless in this case.)
>
>--Richard
>
>
>On Feb 11, 2011, at 1:15 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 : Dynamic Host Configuration Protocol
> (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
> > Author(s) : J. Polk
> > Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt
> > Pages : 13
> > Date : 2011-02-11
> >
> > This document creates a Dynamic Host Configuration Protocol (DHCP)
> > Option for transmitting a client's geolocation Uniform Resource
> > Identifier (URI) of a client, which can be dereferenced in a
> > separate transaction by the client or an entity the client sends
> > this URI to.
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > <Mail Attachment>_______________________________________________
> > 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] I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt

"The LuriValue of LuriType=2 is always represented as an integer."

This is insufficiently specified. How long is this integer? Signed or unsigned? Suggested text:

"The LuriValue of LuriType=2 is always represented as a four-byte unsigned integer."

(We should not use an indefinite-length integer; that's unnecessarily hard. If somebody wants a location URI that's good for more than 136 years, they can renew their DHCP lease. Two octets is probably too short, since it's less than a day; three octets is weird. Hence four. Unsigned because negative seconds are useless in this case.)

--Richard

On Feb 11, 2011, at 1:15 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 : Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
> Author(s) : J. Polk
> Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt
> Pages : 13
> Date : 2011-02-11
>
> This document creates a Dynamic Host Configuration Protocol (DHCP)
> Option for transmitting a client's geolocation Uniform Resource
> Identifier (URI) of a client, which can be dereferenced in a
> separate transaction by the client or an entity the client sends
> this URI to.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Mail Attachment>_______________________________________________
> 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] I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt

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 : Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)
Author(s) : J. Polk
Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt
Pages : 13
Date : 2011-02-11

This document creates a Dynamic Host Configuration Protocol (DHCP)
Option for transmitting a client's geolocation Uniform Resource
Identifier (URI) of a client, which can be dereferenced in a
separate transaction by the client or an entity the client sends
this URI to.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

[Geopriv] [geopriv] rfc3825bis #47 (new): IETF Last Call Comments from Mykyta Yevstifeyev (evnikita2@gmail.com)

#47: IETF Last Call Comments from Mykyta Yevstifeyev (evnikita2@gmail.com)

I might want to comment the Section 4 of this document.

Firstly, none of the three registries are properly specified, per RFC
5226. Among other, there is no clear format of the registries.
Therefore I propose the following changes.

> 4. IANA Considerations
>
> 4.1. 'Altitude Types' Registry
>
> IANA is asked to create and maintain the registry called 'Altitude
> Types' following the guidelines below.
>
> The registry consists of 3 values: Altitude Type, Description and
> Reference. They are described below.
>
> Altitude Type - an integer; refers to the value used in DHCP options
> described in this document. Values from 0 to 15 are assigned.
>
> Description - the description of the altitude described by this code.
>
> Reference - the reference to the document that describes the
> altitude code. Such MUST define the way that the 30 bit altitude
> values and the associated 6 bit uncertainty are interpreted.
>
> Initial values are given below; new assignments are to be made
> following the 'Standards Action' policies [RFC5226]
>
> # Description Reference
> +-------+---------------------------+------------+
> | 0 | No known altitude | RFC xxxx |
> | 1 | Altitude in meters | RFC xxxx |
> | 2 | Altitude in floors | RFC xxxx |
> | 3-14 | Unassigned | RFC xxxx |
> | 15 | Reserved | RFC xxxx |
> +-------+---------------------------+------------+
> [RFC Editor: Please replace xxxx with RFC number assigned to this
> document.

and etc. for each registry and the request to assign the DHCP code number.

Moreover, IMO RFC 5226 should be referenced normatively as it describes
procedures for assignment of new values to the registry. Informative is
not appropriate here. I'd also like to ask whether the following
reference is acceptable for normative:

> [EPSG] European Petroleum Survey Group, http://www.epsg.org/ and
> http://www.epsg-registry.org/

Normative references are allowed to documents only, but not websites.

Thank you in advance for considering my comments in the next version of
the draft.

Mykyta Yevstifeyev

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: new
Priority: minor | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Keywords:
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/47>
geopriv <http://tools.ietf.org/geopriv/>

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

[Geopriv] Invitation to view draft meeting agenda and to study the AR meeting position papers

Greetings!

The community of advocates for open and interoperable AR services, content and tools is meeting in a few weeks, immediately following Mobile World Congress in Barcelona.

We would like to encourage participation of professionals in the IETF GeoPriv WG with interest in AR applications and who wish to work with representatives of the SDOs and experts in related fields.
 
You will find the draft agenda for our upcoming meeting February 17-19, 2011 on this page:

http://www.perey.com/ARStandards/february-meeting-agenda/

In addition, I recommend that you visit the page on which the position papers can be consulted.

http://www.perey.com/ARStandards/position-papers-for-feb-2011/

Comments and feedback welcome.

I also encourage you to share these pages with all others who may be interested via your social media channels and relevant mailing lists.

Warm regards,

--
Christine

Spime Wrangler

cperey@perey.com
mobile +41 79 436 6869
VoIP +1 (617) 848-8159
Skype Christine_Perey

Re: [Geopriv] Last Call: (Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information) to Proposed Standard

Hello,

I might want to comment the Section 4 of this document.

Firstly, none of the three registries are properly specified, per RFC
5226. Among other, there is no clear format of the registries.
Therefore I propose the following changes.

> 4. IANA Considerations
>
> 4.1. 'Altitude Types' Registry
>
> IANA is asked to create and maintain the registry called 'Altitude
> Types' following the guidelines below.
>
> The registry consists of 3 values: Altitude Type, Description and
> Reference. They are described below.
>
> Altitude Type - an integer; refers to the value used in DHCP options
> described in this document. Values from 0 to 15 are assigned.
>
> Description - the description of the altitude described by this code.
>
> Reference - the reference to the document that describes the
> altitude code. Such MUST define the way that the 30 bit altitude
> values and the associated 6 bit uncertainty are interpreted.
>
> Initial values are given below; new assignments are to be made
> following the 'Standards Action' policies [RFC5226]
>
> # Description Reference
> +-------+---------------------------+------------+
> | 0 | No known altitude | RFC xxxx |
> | 1 | Altitude in meters | RFC xxxx |
> | 2 | Altitude in floors | RFC xxxx |
> | 3-14 | Unassigned | RFC xxxx |
> | 15 | Reserved | RFC xxxx |
> +-------+---------------------------+------------+
> [RFC Editor: Please replace xxxx with RFC number assigned to this
> document.

and etc. for each registry and the request to assign the DHCP code number.

Moreover, IMO RFC 5226 should be referenced normatively as it describes
procedures for assignment of new values to the registry. Informative is
not appropriate here. I'd also like to ask whether the following
reference is acceptable for normative:

> [EPSG] European Petroleum Survey Group, http://www.epsg.org/ and
> http://www.epsg-registry.org/

Normative references are allowed to documents only, but not websites.

Thank you in advance for considering my comments in the next version of
the draft.

Mykyta Yevstifeyev

05.02.2011 0:19, The IESG wrote:
> The IESG has received a request from the Geographic Location/Privacy WG
> (geopriv) to consider the following document:
> - 'Dynamic Host Configuration Protocol Options for Coordinate-based
> Location Configuration Information'
> <draft-ietf-geopriv-rfc3825bis-16.txt> as a Proposed Standard
>
> This is the 2nd IETF LC for this document focusing on changes resulting from IESG review.
> The first last call was on version -12 of the document.
> IESG review resulted in these substantial changes:
> - The document will obsolete RFC3825
> - Option code 123 is defined in this document
> - The document defines a new option code instead of extending the behavior of code 123
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-02-18. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
> This document specifies Dynamic Host Configuration Protocol Options
> (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
> of the client. The Location Configuration Information (LCI) includes
> Latitude, Longitude, and Altitude, with resolution or uncertainty
> indicators for each. Separate parameters indicate the reference
> datum for each of these values. This document obsoletes RFC 3825.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> 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

[Geopriv] Incorrect statements in RFC 3825bis IETF Last Call Announcement

This IETF Last Call statement makes incorrect statements with respect to the RFC 3825bis changes.   As a result, I believe that it should be corrected and reissued.

1. The original document obsoleted RFC 3825 from the very beginning.  So this does not represent a change.  See http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis-00.txt
2. The original document also utilized Option Code 123.  This also did not change.

> From: iesg-secretary@ietf.org
> To: ietf-announce@ietf.org
> Date: Fri, 4 Feb 2011 14:19:20 -0800
> CC: geopriv@ietf.org
> Subject: [Geopriv] Last Call: <draft-ietf-geopriv-rfc3825bis-16.txt> (Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information) to Proposed Standard
>
>
> The IESG has received a request from the Geographic Location/Privacy WG
> (geopriv) to consider the following document:
> - 'Dynamic Host Configuration Protocol Options for Coordinate-based
> Location Configuration Information'
> <draft-ietf-geopriv-rfc3825bis-16.txt> as a Proposed Standard
>
> This is the 2nd IETF LC for this document focusing on changes resulting from IESG review.
> The first last call was on version -12 of the document.
> IESG review resulted in these substantial changes:
> - The document will obsolete RFC3825
> - Option code 123 is defined in this document
> - The document defines a new option code instead of extending the behavior of code 123
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-02-18. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
> This document specifies Dynamic Host Configuration Protocol Options
> (both DHCPv4 and DHCPv6) for the coordinate-based geographic location
> of the client. The Location Configuration Information (LCI) includes
> Latitude, Longitude, and Altitude, with resolution or uncertainty
> indicators for each. Separate parameters indicate the reference
> datum for each of these values. This document obsoletes RFC 3825.
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Last Call: (Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information) to Proposed Standard

The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Dynamic Host Configuration Protocol Options for Coordinate-based
Location Configuration Information'
<draft-ietf-geopriv-rfc3825bis-16.txt> as a Proposed Standard

This is the 2nd IETF LC for this document focusing on changes resulting from IESG review.
The first last call was on version -12 of the document.
IESG review resulted in these substantial changes:
- The document will obsolete RFC3825
- Option code 123 is defined in this document
- The document defines a new option code instead of extending the behavior of code 123

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
Latitude, Longitude, and Altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values. This document obsoletes RFC 3825.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-rfc3825bis/

No IPR declarations have been submitted directly on this I-D.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Finishing rfc3825bis

All -

As you know, rfc3825bis substantially changed as a result of IESG review. To dot the i's,
Im going to request a 2nd IETF last call on these changes. Watch for its announcement soon.

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

[Geopriv] FW: New Non-WG Mailing List: paws -- Protocol to Access White Space database (PAWS)

FYI

This new work is likely to make use of some of the technologies defined by these wgs.

-gabor

>-----Original Message-----
>From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-
>bounces@ietf.org] On Behalf Of ext IETF Secretariat
>Sent: 03 February, 2011 21:54
>To: IETF Announcement list
>Subject: New Non-WG Mailing List: paws -- Protocol to Access White
>Space database (PAWS)
>
>A new IETF non-working group email list has been created.
>
>List address: paws@ietf.org
>Archive: http://www.ietf.org/mail-archive/web/paws/
>To subscribe: https://www.ietf.org/mailman/listinfo/paws
>
>Description:
>As nations struggle to provide spectrum in a finite swath of useful
>spectrum, especially spectrum for use with wireless Internet bandwidth,
>there are problems with incumbents in a given band. The incumbents may
>use the spectrum inefficiently, especially geographically - there may
>be large swaths of country where a particular band is not used at all,
>and others where use is only in a portion of the band.
>
>Recently, techniques have been developed that attempt to share spectrum
>between incumbents and new users. The generic term for this is "white
>space". For example, in over the air TV bands, spectrum is divided into
>channels, and in any one area, usually not all channels have TV
>transmitters in range. There is a desire among many regulators to make
>this prime spectrum available for Internet access and other uses, as
>long as the new use does not interfere with the existing TV band use.
>
>Multiple database(s) are expected to exist which contains the
>information about available channels for use at a given location. A
>device is required to query the database for available channels and
>associated information. There are several scenarios that the US
>regulation permits which include a simple tower/client arrangement
>where the tower queries the database on behalf of itself and its client
>TVBDs as well as ad hoc mobile networks where at least one TVBD in the
>ad hoc net has another path to the Internet and can query the database
>with it.
>
>This BoF will explore the various aspects of specifying a messaging
>interface betwen the devices and the database.
>
>For additional information, please contact the list administrators.
>
>_______________________________________________
>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

[Geopriv] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 5985

Dear Mary Barnes, James Winterbottom, Martin Thomson, Barbara Stark:

An IPR disclosure that pertains to your RFC entitled "HTTP-Enabled Location
Delivery (HELD)" (RFC5985) was submitted to the IETF Secretariat on 2011-02-02
and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/1481/). The title of the IPR
disclosure is "Qualcomm Incorporated's Statement about IPR related to RFC 5985."

The IETF Secretariat

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

[Geopriv] IPR Disclosure: Qualcomm Incorporated's Statement about IPR related to RFC 5985

Dear Mary Barnes, James Winterbottom, Martin Thomson, Barbara Stark:

An IPR disclosure that pertains to your RFC entitled "HTTP-Enabled Location
Delivery (HELD)" (RFC5985) was submitted to the IETF Secretariat on 2011-02-02
and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/1482/). The title of the IPR
disclosure is "Qualcomm Incorporated's Statement about IPR related to RFC 5985."

The IETF Secretariat

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

[Geopriv] FYI: ISO 19106: Addressing (draft)

http://www.isotc211.org/address/iso19160.htm

 

Address standards
A collection of information on address standards

 

Thought this might be of interest.

 

Carl Reed, PhD
CTO and Executive Director Specification Program
Open Geospatial Consortium
www.opengeospatial.org

 

The OGC: Making Location Count!

 

---------------------

 

This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.

 

"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller

Re: [Geopriv] Consensus call: Civic extensions

+1

Carl

 

----- Original Message -----

From: Robins George

To: Brian Rosen

Cc: geopriv@ietf.org

Sent: Monday, January 31, 2011 9:05 PM

Subject: Re: [Geopriv] Consensus call: Civic extensions

+1

-Robins

On 01-Feb-2011 3:44 AM, "Brian Rosen" <br@brianrosen.net> wrote:
> I support this plan
>
> Brian
>
> On Jan 31, 2011, at 10:02 AM, Richard L. Barnes wrote:
>
>> Hey all,
>>
>> The chairs would like to get a sense of the working group for a plan for a group of civic-address-related issues.
>>
>> -- Request a milestone for civic address extensibility
>> Dec 2012 - Submit recommendations for civic address extensions as PS
>>
>> -- Adopt draft-winterbottom-geopriv-local-civic-04 as the basis for this milestone
>>
>> -- Merge draft-ietf-geopriv-prefix-00 and draft-george-geopriv-lamp-post-00 into the milestone draft.
>>
>> Please send comments on this proposal to the list by Monday, 7 Feb 2011.
>>
>> Thanks,
>> --Richard
>> _______________________________________________
>> 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