Subject: [Geopriv] Question about draft-polk-geopriv-dhc-geoelement-shape-option

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Mar 2009 13:34:15 -0400

James,

I just skimmed draft-polk-geopriv-dhc-geoelement-shape-option, and had a 
couple of quick, high-level comments:

1. Is there a reason that the draft implements only  a few shapes?  It 
seems like it's not that much work to define additional geo-elements to 
correspond to all the shapes in pdif-lo profile.  That would provide 
full compatibility with the XML format.

2. Speaking of compatibility with XML, it seems like it would be helpful 
to have a well-defined translation between this format and GML.  Would 
it make sense to put something like that in this document?

I'll send more detailed comments soon.

Cheers,
--Richard

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 10 Mar 2009 19:47:24 +0200

My questions: 

* Why do we need this document at all given that we originally wanted to fix
RFC 3825?
So, how does it relate to the (stalled) activity of fixing RFC 3825? 

* Why do we need all these shapes given the DHCP based LCP usage
environments? 

* Why cannot we make things simpler, as proposed with
http://tools.ietf.org/id/draft-tschofenig-geopriv-dhcp-circle-01.txt,
instead of making it more complicated?  

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Richard Barnes
>Sent: 10 March, 2009 19:34
>To: James M. Polk; 'GEOPRIV'
>Subject: [Geopriv] Question 
>aboutdraft-polk-geopriv-dhc-geoelement-shape-option
>
>James,
>
>I just skimmed draft-polk-geopriv-dhc-geoelement-shape-option, 
>and had a couple of quick, high-level comments:
>
>1. Is there a reason that the draft implements only  a few 
>shapes?  It seems like it's not that much work to define 
>additional geo-elements to correspond to all the shapes in 
>pdif-lo profile.  That would provide full compatibility with 
>the XML format.
>
>2. Speaking of compatibility with XML, it seems like it would 
>be helpful to have a well-defined translation between this 
>format and GML.  Would it make sense to put something like 
>that in this document?
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv
>

---

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

Richard

To #1 - DHCP shouldn't do all the shapes possible, such as arcband, 
ellipse and ellipsoid, as DHCP shouldn't be the delivery mechanism of 
the LI to the client in those environments, should it?

Can you give me an example network that DHCP does fit this LCI delivery?

That said, there is a 4 bit field that defines the shape of the 
Option, in which we define the first 3 shapes (point, circle and 
polygon). We state explicitly that more can be defined within this 
document (with WG consensus as to which shapes should be included) or 
an extension to this document down the road.

I generally do not agree that all the shapes in pdif-lo profile 
should be in this document at the moment. Can you give me a 
compelling usage of DHCP in which the LCI of an acr band is viably 
given to a client?  Isn't this more suited for cellular worlds - 
which this document clearly states as a non-goal?  I could be wrong, 
and look forward to your - or others - rational for wanting each shape.

To #2, please look at section 5 of this doc, as this conversion from 
DHCP Shapes into PIDF-LO (i.e., XML) is plainly there for each 
Geotype (i.e., each unique field) in this document - with the 
exception of "centerpoint", because that is currently not defined in 
GML.  I wrote the ID for this (creating the XML element for PIDF-LO 
for a centerpoint), but didn't turn it in.

James

At 12:34 PM 3/10/2009, Richard Barnes wrote:
>James,
>
>I just skimmed draft-polk-geopriv-dhc-geoelement-shape-option, and 
>had a couple of quick, high-level comments:
>
>shapes?  It seems like it's not that much work to define additional 
>geo-elements to correspond to all the shapes in pdif-lo 
>profile.  That would provide full compatibility with the XML format.
>
>2. Speaking of compatibility with XML, it seems like it would be 
>helpful to have a well-defined translation between this format and 
>GML.  Would it make sense to put something like that in this document?
>

---

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

Hannes

You have claimed 3825 is broken. You have written a very incomplete 
DHCP document for circle (64 bit fields for each coordinate? Have you 
done the math to understand how small that is? the 34 bits in 3825 is 
3.11 by 2.62 mm at the equator - do you need to get into picometers, 
really?). There is no ability to provide a polygon (such as a room) 
in coordinates. This ID solves all of this, and does so within a 
single uniform way, instead of having 3 different ways to do each shape.

This document uses RFC 4776's DHCP 'type/length/value' format, for consistency.

This document is extensible, the circle draft is not.

This document provides one Option that can do all 3 shapes, and 
leaves room for 12 more to be defined in this document or extensions 
of this document.

Why do we need all 3 shapes? Are you serious?

If so, then
- a point is where something is with no regard for confidence or uncertainty;
- a circle either is
         - a point with confidence or uncertainty built in, or
         - it represents an AP coverage area (which is 100m according to IEEE)
- a polygon represents areas such as rooms or manufacturing floors

What part of these shapes are in question that we need to cover?

That makes this document more flexible and consistent that any other 
coordinate document. Since when is that a bad thing?

Question - if someone wants an acr band, does that mean there needs 
to be a new format to satisfy this unique shape?  That's not the case 
with our new document. The Option number would stay the same. The 
format would stay the same. All that is needed is a new definition 
IANA registered shape, and the mandatory Geotype fields that are 
needed to represent the shape, then the conversion to PIDF-LO section 
-- and you're done.

wrt the relationship with RFC 3825, it does not replace it - but it 
allows 3825 to fade into oblivion if the IEEE decide to adopt this 
new format instead of 3825's.  In the future, we believe 3825 can 
move to historical and the DHC WG can reclaim Option 123.  But that 
is not expected to be the day this new document becomes an RFC (if it 
does), but when the DHC WG polls the industry to determine that no 
one is using 3825 any more.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 10 Mar 2009 14:49:00 -0500

We could also look at Martin's 3825 bis document that does not change the structure of 3825, allows reasonable representation of areas without trying to represent uncertainty with significant digits.

Cheers
James

-----Original Message-----
From: [email-masked] on behalf of James M. Polk
Sent: Tue 3/10/2009 2:07 PM
To: Hannes Tschofenig; 'Richard Barnes'; 'GEOPRIV'
Subject: Re: [Geopriv] Question aboutdraft-polk-geopriv-dhc-geoelement-shape-option
 
Hannes

If so, then

James

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

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

James W

If we look at the format introduced in RFC 3825, then the 
modification in Martin's 3825bis, then wholly different one in 
Hannes's and your circle draft, then figure out that some want a 
polygon -- we are looking at 3 or 4 formats for a coordinate Options 
- all with different Option numbers.  This doesn't make sense to me - 
and propose that we consolidate each of the objectives into a single doc.

The Shapes Option is a concrete proposal to do just that.

RFC 4776 uses a 'type/length/value' element format, which if memory 
serves - was completely uncontroversial at the time, and remains 
uncontroversial.

Doesn't it make sense to adopt 4776's 'type/length/value' element 
format for coordinate locations and have a single doc provide how to 
do any WG agreed upon shapes, plus allow extensibility to have more 
shapes be defined as extensions to this doc as updates to the shapes doc?

I'm trying to converge all the desires of the WG into a single doc 
for coordinates, and at the same time (over a period of time) move 
3825 into Historical status (which should please many WG members, 
including you, Martin and Hannes).

This should, if agreeable, focus our energies on a single doc that 
can handle each coordinate choice, thus reducing wasted energy, while 
making what this WG produces more efficient and less complex when 
compared to having implementors do 3 or 4 Options (with 3 or 4 
formats). This proposal uses the same Option format for the one 
Option we already have little problems with, the one defined in RFC 4776.

James P.

At 02:49 PM 3/10/2009, Winterbottom, James wrote:
>We could also look at Martin's 3825 bis document that does not 
>change the structure of 3825, allows reasonable representation of 
>areas without trying to represent uncertainty with significant digits.
>
>Cheers
>James
>
>
>Subject: Re: [Geopriv] Question

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 10 Mar 2009 21:40:12 -0500

James,

Let's leave the debate about the merits and flaws of this draft aside for the moment.

By submitting this document, you are effectively re-opening the higher order issue that I thought was resolved.  That is, the question as to whether 3825 is "fixed" or replaced.

I was under the strong impression that fixing was the consensus of the group.  This draft is a proposal for a replacement.

I know that you weren't involved in the previous "fix" proposal, so this isn't a personal indictment, but let's get the main issue resolved first.

Cheers,
Martin

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Wednesday, 11 March 2009 7:20 AM
> To: Winterbottom, James; Hannes Tschofenig; Richard Barnes; GEOPRIV