Subject: [Geopriv] New DHCP Geoelement Shapes ID

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Mar 2009 15:22:16 -0500

Geopriv

[there already have been comments about this ID, but here is a formal 
call for comments by the authors]

We have submitted an initial version of a new ID that communicates a 
Geoshape via DHCP.  Presently, we define how to download a 
point/position, a circle and a polygon in 2D or 3D, in IPv4 and IPv6.

This effort takes the lead from RFC 4776 (civic) for its format of 
extensibility, in which there are a few header fields in this Option 
that are present in all shapes, but the majority of the fields are 
similar to civic Option in that it provides a Geotype, Geolength and 
Geovalue format.  This document includes exactly which Geotypes are 
required, which are optional, and which aren't to be there for each shape.

This document also includes a mapping to the PIDF-LO, for converting 
each field (presently defined in the PIDF-LO) to where it goes in the 
PIDF-LO - articulating the XML elements to be populated.

Comments are welcome

James
Marc
Allan

>From: [email-masked]
>To: [email-masked]
>Subject: I-D Action:draft-polk-geopriv-dhc-geoelement-shape-option-00.txt
>Date: Wed,  4 Mar 2009 11:45:02 -0800 (PST)
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>         Title           : Dynamic Host Configuration Protocol 
> (DHCP) Location Shapes Option for Geopriv for IPv4 and IPv6
>         Author(s)       : J. Polk, et al.
>         Filename        : 
> draft-polk-geopriv-dhc-geoelement-shape-option-00.txt
>         Pages           : 25
>         Date            : 2009-03-04
>
>This document defines the Dynamic Host Configuration Protocol (DHCP)
>Option for downloading a location shape to a client, from a server.
>This is commonly called Location Configuration Information (LCI).
>Servers that provide this information to a client are doing so by
>communicating via a Location Configuration Protocol, or LCP.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhc-geoelement-shape-option-00.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.
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-polk-geopriv-dhc-geoelement-shape-option-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Mar 2009 21:35:35 -0500

Richard asked that I resend a response I gave to him, giving context 
that helped him better understand this ID, specifically wrt to RFC 3825.

Richard said:

>On 3/10/09 1:26 PM, "Richard Barnes" <[email-masked]> wrote:
>
> > Marc, James,
> >
> > At the last few IETFs, we had talked about producing a new draft to
> > update RFC 3825.  Is draft-polk-geopriv-dhc-geoelement-shape-option that
> > draft?  It doesn't say that it updates/obsoletes 3825, but with the
> > "point" geo-element, it seems like it might.
> >
> > --Richard

I responded:

This new ID doesn't replace or update 3825 directly. Since the IEEE 
uses 3825's format, we can't make this radical change without their 
input, and blessing, which we have not tried to get. An update to 
3825 would create a problem with the IEEE. more on this below.

What this doc does is create a new way to send LCI from a server to a 
client (via the LCP of DHCP) in the format adapted from RFC 4776's 
(civic). We use the same 'type/length/value' format as is in 4776 for 
coordinate 3 shapes (that can be expanded if the WG wants, and is 
easily extensible either by adding new shapes (there are 12 values 
left unused in the "shapes" field in the header, or by versioning the Option.

This document brings together all the coordinate based shapes that 
are realistic for DHCP to be the LCP for (an actual location value, 
and not an LbyR) - into a common Option format, with simple rules and 
components. It includes a section (#5) of how to convert this Option 
into a PIDF-LO (i.e., which XML elements are to be used for each 
value in the Option). I covered each new Geoelement except for the 
new centerpoint (of a polygon) value. I have a separate ID completed, 
but not turned in, that creates this new PIDF-LO XML element. I 
wanted to get initial feedback from the WG before introducing that 
doc, which is really simple, given that it mirrors the <gml:pos> 
element by distinguishing itself as the <gml:centerpos> element, with 
no other changes to GML. It's really easy, and it's something we have 
in shipping product now, in XML, but not as a PIDF-LO yet. This comes 
from direct customer requirements, so this is not an "if we create 
it, we're sure someone will use it" situation.

wrt to replacing 3825, as I said on the list to Hannes, we hope this 
more consistent Option format (re: to 4776's) will help it's 
acceptance. We believe also that having all DHCP via shapes in a 
single doc makes the most sense from a complexity point of view 
(i.e., only doing things one way, instead of a different way for each 
coordinate Option), and also the WG agree this is a good way forward. 
That said, we know this Option cannot replace Option 123 (3825's) 
right away. But do believe this will cause anyone doing coordinates 
in DHCP as an LCP to move towards this doc instead of 3825. This 
should result in 3825 becoming used, which will allow the DHC WG to 
reclaim Option 123, which will also allow RFC 3825 to move to 
Historical status (officially). This should make some in our WG happy 
(i.e., that 3825's end is in sight ;-)

The added benefit is that we, as a WG, can stop talking about 3825 
once this new Option format is viewed positively. There's no sense in 
wasting time and energy fixing what doesn't have a future, right? I 
mean, even for a coordinate point, this new Option has seriously 
greater flexibility than that defined by 3825, agreed?

At the same time, we have someone in the IEEE that will be pushing 
them to adopt this new Option format in lieu of 3825's, so that 
should accelerate the movement of 3825 to Historical status.

Does this all appear agreeable?

James

At 03:22 PM 3/10/2009, James M. Polk wrote:
>Geopriv
>
>[there already have been comments about this ID, but here is a 
>formal call for comments by the authors]
>
>each field (presently defined in the PIDF-LO) to where it goes in 
>the PIDF-LO - articulating the XML elements to be populated.
>
>Comments are welcome
>
>James
>Marc
>Allan
>
>
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv