Re: [Geopriv] Consensus call: Basis for revisions to RFC 3825

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Tue Apr 21 2009 - 06:28:15 EDT

James,

Let me try to clarify three points:

1. This question is not about the precise scope of 3825 fixes. Adopting
this document doesn't mean that we accept all of the content in it, just
that it's close enough to be a starting point. After some document is
adopted, there will be a process of discussion and revision around
things like deprecating floors and signaling versions.

2. For reference the three documents proposed for adoption were:
2.1. draft-polk-geopriv-dhc-geoelement-shape-option
2.2. draft-tschofenig-geopriv-dhcp-circle
2.3. draft-thomson-geopriv-3825bis

3. The thread I was referring to as "the prior thread about the scope of
3825 fixes" has the subject line "[Geopriv] Scope of 3825 fixes".
<http://www.ietf.org/mail-archive/web/geopriv/current/msg07039.html>

--Richard

James M. Polk wrote:
> At 08:42 PM 4/20/2009, Richard Barnes wrote:
>> All,
>>
>> Based on the prior thread about the scope of 3825 fixes, it sounds
>> like the closest of the three proposed documents
>
> Richard
>
> Can you please list the 3 documents you just comments on?
>
> I saw nothing in the "[Geopriv] Signaling versions in 3825bis" thread
> that discussed anything but 3825bis.
>
> Are you talking about this thread "[Geopriv] Scope of 3825 fixes"?
>
> If so, I don't like [1], but can live with it *AS* long as it doesn't do
> [2].
>
> no one yet has given a valid reason why floors need be deprecated. This
> is interesting, because this is saying to the WG that someone has proven
> that there is harm being done using floors in RFC 3825, and I don't
> believe that's the case, so I'd like the chairs to clarify why this is
> even up for discussion?
>
> Please do NOT conflate this issue with how a PIDF-LO carries floors in
> the <cl:FLR> element. THESE ARE TWO SEPARATE ISSUES HANDLED BY TWO
> SEPARATE PROTOCOLS.
>
> [3] wasn't discussed in SF, and used a different representation of X and
> Y, requiring implementers to support more than one way of encoding and
> decoding each coordinate. This does not make sense to me.
>
> I am obviously in favor of [4], but this in no way has any backwards
> compatibility issues - and I challenge anyone to tell me how it is not
> backwards compatible?
>
> They are different, in that [4] also can do a point (but without
> everyone's least favorite function: resolution). I believe [1] and [4]
> are orthogonal; [4] happens to do a lot more (including confidence and
> uncertainty if desired) - and reuses RFC 4776's (civic) TLV format.
>
> James
>
>> to what people want is draft-thomson-geopriv-3825bis-03. So I would
>> like to put the following question to the group:
>>
>> Should the WG document for revisions to RFC 3825 be based on
>> draft-thomson-geopriv-3825bis-03?
>>
>> Please respond to the list by Monday, 27 April 2009.
>>
>> 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
Received on Tue, 21 Apr 2009 06:28:15 -0400

This archive was generated by hypermail 2.1.8 : Tue Apr 21 2009 - 06:29:19 EDT