Subject: [Geopriv] Virtual interim consensus calls

From: Alissa Cooper <[email-masked]>
Date: Thu, 21 May 2009 17:42:09 -0400

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.

---

From: [email-masked]
Date: Thu, 21 May 2009 18:55:37 -0400 (EDT)

Thanks for this list of consensus calls. The mapping between the DHCP
location encoding and GML should be strightforward.

I can help as needed. I can also confirm the correct EPSG codes for WGS 84
(and any other CRS of interest).

Regards

Carl
OGC

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 22 May 2009 01:19:24 -0500

Alissa

Thanks for sending this out.

I recommend with every non-affirmative response to what you have 
below - that message immediately changes the subject field -- just to 
keep track of each item when.

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 22 May 2009 01:30:33 -0500

I need to preface this response with a concession.  My circadian rhythms won this morning, therefore I am not necessarily aware of all factors that led to these conclusions.

(2) through (6), I can live with.  (4) does not contribute to the goal of achieving backward compatibility, but I'll not continue to debate the topic.  However, given this decision, (6) should further include a mapping for both versions, and guidance on mapping both to AND from GML for both versions.

(1) remains problematic for me.

My 3825bis proposal was originally written in response to a refusal to acknowledge the faults in RFC 3825 (succinctly explained in http://xkcd.com/386/).  The process employed was that proposed in (1).  Admittedly, this didn't follow a WG process and so it was both faster and less constrained than an edit cycle performed with full involvement of a working group.  

However, this is an individual submission and the working group process is, at least in theory, able to change every aspect of a work item.  Therefore, I cannot conclude that openness of process is a valid argument for what is proposed in (1).

That leaves the goal of minimal changes between versions, which as a rhetorical device is an appealing concept.  However, it's been trivially demonstrated that aiming to minimize changes is largely futile.  Even a minimal edit has revealed significant changes required just to accomplish the already agreed changes.  Add to this the formatting changes, further editorial changes, and additional text required just to meet current publication standards and this document will look nothing like its predecessor.

I sincerely hope that whomever is selected to edit this document does not slavishly strive to minimize the impact of edits in the interests of maintaining a usable diff with RFC 3825.  There is a lot of text in 3825 that would benefit from alteration.

Given the cost of adopting such a course, the motivations of the proponents of such a method are more than a little confusing.  Of course, there might be unstated goals that are less altruistically motivated.  I can understand if that were the case.

I'd like to propose that the Bond draft be adopted as a WG item as a basis for this work.  At least the editor of that work can be considered impartial on this topic; this process would benefit from this sort of impartiality.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alissa Cooper
> Sent: Friday, 22 May 2009 7:42 AM
> To: GEOPRIV
> Subject: [Geopriv] Virtual interim consensus calls
> 

------------------------------------------------------------------------------------------------
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: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 22 May 2009 11:55:51 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alissa Cooper
> Sent: Thursday, May 21, 2009 10:42 PM
> To: GEOPRIV
> This email is a call to confirm consensus on the items 
> discussed during the GEOPRIV virtual interim meeting held on 
> May 21, 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.
> 
> (4) The bis should provide a way for implementations to 
> signal their use of uncertainty rather than resolution.
> (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.
> 
> 
> 
> 
> 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 May 2009 05:36:40 -0700

> 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.

This doesn't make sense.  -bis documents are supposed to include a section listing the changes from the original document.  That is sufficient.  There is virtually no -bis document in existence today that would satisfy such a requirement (trying doing a diff of RFC 3261 with RFC 2543), and there is no practical way to enforce such a requirement all the way through to RFC Editor publication.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 22 May 2009 14:57:19 +0200

Well it makes sense to me.

More to the point, if we cannot make it make sense, then I will object to makeing consensus with this point and support the alternative of going for an update as for example in draft-polk-geopriv-3825-update.

regards

Keith

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Friday, May 22, 2009 1:37 PM
	To: DRAGE, Keith (Keith); [email-masked]; [email-masked]
	Subject: RE: [Geopriv] Virtual interim consensus calls

---

From: <[email-masked]>
Date: Fri, 22 May 2009 20:57:51 +0200

>[mailto:[email-masked]] On Behalf Of ext DRAGE, 
  >Keith (Keith)
  >Sent: Friday, May 22, 2009 5:57 AM
  >To: Bernard Aboba; [email-masked]; [email-masked]
  >Subject: Re: [Geopriv] Virtual interim consensus calls
  >

It doesn't make sense to me either.

  >More to the point, if we cannot make it make sense, then I 
  >will object to makeing consensus with this point and support 
  >the alternative of going for an update as for example in 
  >draft-polk-geopriv-3825-update.

But this makes even less sense. I thought we already decided on the above based on technical arguments. You have some editorial preferences which nobody on the list said they make sense. Doesn't the ietf have a procedure to exclude editorial objections from consensus call?

- Gabor

  >	> 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.
  >	
  >	This doesn't make sense.  -bis documents are supposed 
  >to include a section listing the changes from the original 
  >document.  That is sufficient.  There is virtually no -bis 
  >document in existence today that would satisfy such a 
  >requirement (trying doing a diff of RFC 3261 with RFC 2543), 
  >and there is no practical way to enforce such a requirement 
  >all the way through to RFC Editor publication. 
  >	
  >	
  >

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 22 May 2009 15:17:14 -0500

At 01:57 PM 5/22/2009, [email-masked] wrote:

>But this makes even less sense. I thought we already decided on the 
>above based on technical arguments. You have some editorial 
>preferences which nobody on the list said they make sense. Doesn't 
>the ietf have a procedure to exclude editorial objections from consensus call?

Gabor - Keith agreed to one item based on the call consensus (which 
is different than WG consensus) on #1.

I believe Keith's position is that if another item gets voted down, 
then he retracts his consensus to #1.

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 23 May 2009 20:01:54 +0300

I do not really understand the desire to have a minimum number of document
changes (with respect to output caused by a DIFF tool) raised by Keith would
be important for a tiny document like this. 
 
I don't think that new implementers care about this aspect given that they
should only read the new document anyway. Someone who wants to update their
implementation will have to read the new document anyway and would probably
appreciate a more implementation focused description.
 
We should listen more to people who either implemented the mechanism or plan
todo so.
 
Ciao
Hannes
 
PS: I agree what Bernard says below as well. 

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
	Sent: 22 May, 2009 15:37
	To: [email-masked]; [email-masked]; [email-masked]
	Subject: Re: [Geopriv] Virtual interim consensus calls

	> 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.
	
	This doesn't make sense.  -bis documents are supposed to include a
section listing the changes from the original document.  That is sufficient.
There is virtually no -bis document in existence today that would satisfy
such a requirement (trying doing a diff of RFC 3261 with RFC 2543), and
there is no practical way to enforce such a requirement all the way through
to RFC Editor publication.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 28 May 2009 14:46:16 -0400

To recap: according to our small number of votes and lack of  
objections, we have WG consensus on items 2-6 below. #1 is still being  
debated.

Alissa

> (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.
>
> (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  
> (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.
>
>
>
>
>
>
>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 28 May 2009 14:46:31 -0400

Let's put aside the idea of retaining diff utility for a moment, since  
the main proponent of that idea has said that he's willing to  
compromise if necessary to achieve rough consensus.

With that idea aside, there are still two mutually exclusive -bis  
options:

1) -bis 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) -bis that makes the substantive changes needed for the fixes,  
includes a sub-section that lists the changes, and makes other textual  
edits that improve the text but do not impact the protocol design

I've seen one person supporting #1 and one person supporting #2. Does  
anyone else have an opinion?

Alissa

---

From: <[email-masked]>
Date: Thu, 28 May 2009 21:11:44 +0200

My count so far was 1 for (1) and 4 for (2).

I am still in favor of (2).

- Gabor

  >[mailto:[email-masked]] On Behalf Of ext Alissa Cooper
  >Sent: Thursday, May 28, 2009 11:47 AM
  >To: Hannes Tschofenig
  >Cc: [email-masked]; [email-masked]
  >Subject: Re: [Geopriv] On the value of a DIFF -- RE: Virtual 
  >interim consensus calls
  >
  >Let's put aside the idea of retaining diff utility for a 
  >moment, since the main proponent of that idea has said that 
  >he's willing to compromise if necessary to achieve rough consensus.
  >
  >1) -bis 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) -bis that makes the substantive changes needed for the 
  >fixes, includes a sub-section that lists the changes, and 
  >makes other textual edits that improve the text but do not 
  >impact the protocol design
  >
  >I've seen one person supporting #1 and one person supporting 
  >#2. Does anyone else have an opinion?
  >
  >Alissa
  >
  >
  >> I do not really understand the desire to have a minimum number of 
  >> document changes (with respect to output caused by a DIFF 
  >tool) raised 
  >> by Keith would be important for a tiny document like this.
  >>
  >> I don't think that new implementers care about this aspect 
  >given that 
  >> they should only read the new document anyway. Someone who 
  >wants to 
  >> update their implementation will have to read the new 
  >document anyway 
  >> and would probably appreciate a more implementation focused 
  >> description.
  >>
  >> We should listen more to people who either implemented the 
  >mechanism 
  >> or plan todo so.
  >>
  >> Ciao
  >> Hannes
  >>
  >[mailto:[email-masked]] On 
  >> Behalf Of Bernard Aboba
  >> 	Sent: 22 May, 2009 15:37
  >selected) is to 
  >> ensure that the IETF tools diff programs generate 
  >meaningful results 
  >> against the published RFC 3825 for any new version.
  >> 	
  >to include a 
  >> There is virtually no -bis document in existence today that would 
  >> satisfy such a requirement (trying doing a diff of RFC 
  >3261 with RFC 
  >> 2543), and there is no practical way to enforce such a 
  >requirement all 
  >> the way through to RFC Editor publication.
  >> 	
  >> 	
  >>
  >>
  >>
  >
  >
  >
  >
  >
  >
  >
  >
  >

---

From: Marc Linsner <[email-masked]>
Date: Thu, 28 May 2009 16:09:36 -0400

+1 for #1

-Marc-

On 5/28/09 2:46 PM, "Alissa Cooper" <[email-masked]> wrote:

>> document
>> satisfy

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Thu, 28 May 2009 13:24:32 -0700

+1 for #1.

allan

-----Original Message-----
interimconsensus calls

Alissa

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 28 May 2009 17:55:05 -0400

+1 for #1

> Sent: Thursday, May 28, 2009 2:47 PM
> To: Hannes Tschofenig
> Subject: Re: [Geopriv] On the value of a DIFF -- RE: Virtual interim
> consensus calls
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 May 2009 19:13:05 -0700

+1 for #2.

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 28 May 2009 21:28:28 -0500

+1 for #2

-----Original Message-----
From: [email-masked] on behalf of Bernard Aboba
Sent: Thu 5/28/2009 9:13 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] On the value of a DIFF -- RE:Virtual	interimconsensus calls

+1 for #2.

---

From: [email-masked]
Date: Fri, 29 May 2009 04:20:53 -0400 (EDT)

+1 for #2

Carl

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 29 May 2009 14:18:03 +0200

#1 please. 

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, May 28, 2009 10:55 PM
> To: 'Alissa Cooper'; 'Hannes Tschofenig'
> Cc: [email-masked]; DRAGE, Keith (Keith)
> Subject: RE: [Geopriv] On the value of a DIFF -- RE: Virtual 
> interim consensus calls
> 
> +1 for #1
> 
> moment, since 
> needs to be 
> > > document changes (with respect to output caused by a DIFF tool) 
> > > raised by Keith would be important for a tiny document like this.
> > >
> > > I don't think that new implementers care about this aspect given 
> > > that they should only read the new document anyway. Someone who 
> > > wants to update their implementation will have to read the new 
> > > document anyway and would probably appreciate a more 
> implementation 
> > > focused description.
> > >
> > > We should listen more to people who either implemented 
> the mechanism 
> > > or plan todo so.
> > >
> > > Ciao
> > > Hannes
> > >
> requirement

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 31 May 2009 18:46:28 -0500

#2.  Please.

> Behalf Of [email-masked]
> Sent: Friday, 29 May 2009 6:21 PM
> To: Alissa Cooper
> Cc: [email-masked]; Hannes Tschofenig; [email-masked]
> >> that they