RE: [Geopriv] draft-thomson-geopriv-3825bis-01.txt

From: James M. Polk ^lt;jmpolk@cisco.com>
Date: Mon Nov 26 2007 - 19:35:14 EST

At 06:05 PM 11/26/2007, Thomson, Martin wrote:
>Content-class: urn:content-classes:message
>Content-Type: text/plain;
> charset="UTF-8"
>
>I think that this discussion is in danger of
>devolving into bickering (again), despite
>Hannes' best efforts to keep things civil. Focus on the goal.
>
>We can all agree on one point: RFC 3825 has a problem.

no everyone agrees with this

>We even seem to agree that the problem needs a document to clarify it.

that's not how the binary doc came into being. A
few said, said again, said again and then
screamed they didn't understand 3825. The chairs
asked a co-author of 3825 if it would be a
problem if a new doc were written to have a
common reference for the discussion. That doc was
written. That doc wasn't written because everyone
thought there was a problem with 3825, it was
written because a small few didn't like the
resolution fields, and wanted cellular
uncertainty and confidence values instead.

>I also think that we have consensus that a normative update is required.

no no no no

see above

the WG agreed the additional doc couldn't hurt to
have, and was expedited to become a WG item after its first presentation.

>My opinion is that we don't get the luxury of a
>do-over. People are already using the format,
>either oblivious to its limitations or content
>to leave us to fix its problems. The progress
>we've demonstrated so far must be dreadfully reassuring.
>
>If a do-over were possible, it would be with a
>DHCP option code other than 123 and, yes, it
>would be better. That wouldn’t help those
>that have already published standards based on RFC 3825.
>
>So we are stuck with what is there.
>
>My proposal, as I documented in
>draft-thomson-geopriv-3825bis, is that the
>meaning of the "resolution" fields is
>changed. The change is the minimum necessary to
>ensure that they are usable, while maintaining a
>veneer of compatibility with any existing
>implementations -- the size of the region of
>uncertainty is the same, but moved slightly.
>
>At risk of attracting an inimical response, my
>opinion is that draft-ietf-binary-lci is poorly
>written and inadequate. It equivocates over
>terminology that should be clear and
>precise. The focus on C code is unnecessary and
>doesn't serve to clarify; it only demonstrates
>an inability to convey the message. I wouldn't
>have written the -bis proposal if I thought that it could be fixed.
>
>Cheers,
>Martin
>
>p.s. All THIS came from a comment about the
>example? After seeing that comment, I was
>thinking "if that's all that comes out of this,
>then I don't have much to worry about..."
>
>p.p.s. To answer Hannes' original question on
>why the Sydney Opera House was chosen... I
>needed a public location and polygons are much
>easier to convert to the 3825 form. A circle
>needs to be converted to ECEF before you can
>work out a bounding box; I wanted to avoid that complexity.
>------------------------------------------------------------------------------------------------
>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]
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 26 Nov 2007 18:35:14 -0600

This archive was generated by hypermail 2.1.8 : Mon Nov 26 2007 - 19:36:04 EST