Re: [Geopriv] Virtual interim consensus calls

["DRAGE, Keith (Keith)" <drage at alcatel-lucent.com>]

I support all these.

Two comments:

On 1)	The key guidance to the draft editor (when selected) is to ensure that the IETF tools diff programs generate meaningful results against the published RFC 3825 for any new version.

On 5)	I have no problem with the proposal to document this, but I think there is also a slighlty different and useful slant on this in that it should give guidance to the sender of the information about the way existing RFC 3825 receiving implementations will treat new information in the bis format.

regards

Keith

> -----Original Message-----
> From: geopriv-bounces at ietf.org 
> [mailto:geopriv-bounces at ietf.org] On Behalf Of Alissa Cooper
> Sent: Thursday, May 21, 2009 10:42 PM
> To: GEOPRIV
> Subject: [Geopriv] Virtual interim consensus calls
> 
> This email is a call to confirm consensus on the items 
> discussed during the GEOPRIV virtual interim meeting held on 
> May 21, 2009.  
> Please reply no later than Wednesday, May 27, 2009.
> 
> Note: We already have working group consensus to do 
> backwards- compatible fixes to RFC 3825 and not to include 
> deprecation of the floors attribute as part of those fixes.
> 
> Confirmations:
> 
> (1) The draft that contains the backwards-compatible fixes to 
> RFC 3825 should be in a -bis format, using the original RFC 
> text and only changing what needs to be changed for the 
> fixes, with the inclusion of a sub-section that lists the changes.
> 
> (2) The bis should correct the EPSG code for WGS84.
> 
> (3) The bis should contain a DHCPv6 location option format.
> 
> (4) The bis should provide a way for implementations to 
> signal their use of uncertainty rather than resolution.
> (4a) The bis should signal uncertainty using datum bits.
> (4b) The bis should use the datum bits to signal uncertainty 
> in such a way that the datum field is compatible with the 
> existing 802.11 reservation of datum bits.
> 
> (5) The bis should provide guidance about what clients should 
> do when they receive a datum they do not understand. For 
> example, the document could recommend ignoring the bits that 
> are not understood.
> 
> (6) The bis should contain a mapping between the DHCP 
> location format and GML.
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>