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

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Tue Apr 21 2009 - 02:44:52 EDT

Hi James,

The question is about adoption. The form of the document might be significantly different by the time we send it to the IESG.

As I have noted, the deprecation of floors in 3825bis is pointless. So, to allay your fears: the new doc wont include any attempt to deprecate floors.

--Martin

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Tuesday, 21 April 2009 4:37 PM
> To: Richard Barnes; 'GEOPRIV'
> Subject: Re: [Geopriv] Consensus call: Basis for revisions to RFC 3825
>
> 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

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 21 Apr 2009 01:44:52 -0500

This archive was generated by hypermail 2.1.8 : Tue Apr 21 2009 - 02:46:43 EDT