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

From: Richard Barnes <[email-masked]>
Date: Mon, 20 Apr 2009 21:42:48 -0400

All,

Based on the prior thread about the scope of 3825 fixes, it sounds like 
the closest of the three proposed documents 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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 20 Apr 2009 23:30:48 -0700

Yes.

> Date: Mon, 20 Apr 2009 21:42:48 -0400
> From: [email-masked]
> To: [email-masked]
> Subject: [Geopriv] Consensus call: Basis for revisions to RFC 3825
> 
> All,
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 21 Apr 2009 01:36:40 -0500

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Apr 2009 01:44:52 -0500

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: [email-masked] [mailto:[email-masked]] 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
> 

------------------------------------------------------------------------------------------------
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: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Apr 2009 09:53:06 +0300

Yes. 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Bernard Aboba
	Sent: 21 April, 2009 09:31
	To: [email-masked]; [email-masked]
	Subject: Re: [Geopriv] Consensus call: Basis for revisions to
RFC 3825

	Yes.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Apr 2009 09:51:50 +0200

I have some major problems with this question, and therefore the answer has to be no.

The underlying basis for any revision has to be RFC3825. I am not in favour of a carte blanche replacement of RFC 3825. In the absence of consensus, current 3825 requirements prevail.

What we should be attempting to do is fix the problems in RFC 3825. So I would prefer questions asked on: Do we agree on the fix of a specific issues.

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Barnes
> Sent: Tuesday, April 21, 2009 2:43 AM
> To: 'GEOPRIV'
> Based on the prior thread about the scope of 3825 fixes, it 
> sounds like the closest of the three proposed documents to 
> what people want is draft-thomson-geopriv-3825bis-03.  So I

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Apr 2009 10:57:17 +0300

I find the question very precise: 

draft-thomson-geopriv-3825bis-03: YES or NO?

>[mailto:[email-masked]] On Behalf Of ext DRAGE, Keith (Keith)
>Sent: 21 April, 2009 10:52
>The underlying basis for any revision has to be RFC3825. I am 
>not in favour of a carte blanche replacement of RFC 3825. In 
>the absence of consensus, current 3825 requirements prevail.
>
>What we should be attempting to do is fix the problems in RFC 
>3825. So I would prefer questions asked on: Do we agree on the 
>fix of a specific issues.
>
>Keith
>
>> like the closest of the three proposed documents to what people want 
>> is draft-thomson-geopriv-3825bis-03.  So I would like to put the 
>> following question to the group:
>>

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 21 Apr 2009 11:28:03 +0300

And I have to add: As usual, you pick a document as a starting point.
The content of the document is likely to change based on the consensus
of the group ... 

Not a totally unusual work style in the IETF. 

>[mailto:[email-masked]] On Behalf Of ext Tschofenig, 
>Hannes (NSN - FI/Espoo)
>Sent: 21 April, 2009 10:57
>To: ext DRAGE, Keith (Keith); Richard Barnes; GEOPRIV
>>I have some major problems with this question, and therefore 
>the answer 
>>has to be no.
>>
>>The underlying basis for any revision has to be RFC3825. I am not in 
>>favour of a carte blanche replacement of RFC 3825. In the absence of 
>>consensus, current 3825 requirements prevail.
>>
>3825. So 
>>I would prefer questions asked on: Do we agree on the fix of 
>a specific 
>>issues.
>>
>>Keith
>>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Apr 2009 06:20:51 -0400

Keith,

What Hannes said is correct: The question is whether the document in 
question should be used as a starting point for the WG document.  The 
issue of scope is independent of this question (but related, since one 
would like the starting point to be close to the goal), since the 
document will be revised to meet the needs of the WG.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Apr 2009 06:28:15 -0400

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:
> 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.
> 
> compatibility issues - and I challenge anyone to tell me how it is not 
> backwards compatible?
> 
> 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:
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Apr 2009 13:19:03 +0200

I have just created a diff of the RFC against the I-D. Because there has been some radical restructuring, and because there have been attempts to do a complete rewrite, this is not the direction I want to see this work go. Therefore I must still reject the 3825bis draft as a starting point.

In my view the effective changes on the document must be much less radical, i.e. no restructuring of the document, no rewrite of clauses where we are not attempting to address problems, and so on.

regards

Keith 

> From: Richard Barnes [mailto:[email-masked]] 
> Sent: Tuesday, April 21, 2009 11:21 AM
> To: DRAGE, Keith (Keith)
> Cc: 'GEOPRIV'
> What Hannes said is correct: The question is whether the 
> document in question should be used as a starting point for 
> the WG document.  The issue of scope is independent of this 
> question (but related, since one would like the starting 
> point to be close to the goal), since the document will be 
> revised to meet the needs of the WG.
> 
> --Richard
> 
> 
> 
> > The underlying basis for any revision has to be RFC3825. I 
> am not in favour of a carte blanche replacement of RFC 3825. 
> In the absence of consensus, current 3825 requirements prevail.
> > 
> > What we should be attempting to do is fix the problems in 
> RFC 3825. So I would prefer questions asked on: Do we agree 
> on the fix of a specific issues.
> > 
> > Keith
> >

---

From: <[email-masked]>
Date: Tue, 21 Apr 2009 17:06:03 +0200

Keith,

IEEE needs a conclusion on this document asap. Do you have a technical argument against 3825bis? The restructuring issues can be handled at a later stage.

My answer to Richard's question: YES.

- gabor

  >Behalf Of ext DRAGE, Keith (Keith)
  >Sent: Tuesday, April 21, 2009 4:19 AM
  >To: Richard Barnes
  >Cc: 'GEOPRIV'
  >I have just created a diff of the RFC against the I-D. Because there has
  >been some radical restructuring, and because there have been attempts to
  >do a complete rewrite, this is not the direction I want to see this work
  >go. Therefore I must still reject the 3825bis draft as a starting point.
  >
  >In my view the effective changes on the document must be much less
  >radical, i.e. no restructuring of the document, no rewrite of clauses
  >where we are not attempting to address problems, and so on.
  >
  >regards
  >
  >Keith
  >

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Apr 2009 17:21:05 +0200

I believe the restructuring issues will be lost if I accept the document now.

Explain to me how we can minimise the restricturing and rewrite changes when the document I am being asked to accept now appears to do pretty much a total rewrite.

I therefore sustain my objection. 

regards

Keith

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, April 21, 2009 4:06 PM
> To: DRAGE, Keith (Keith); [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] Consensus call: Basis for revisions to RFC 3825
> 
> Keith,
> 
> IEEE needs a conclusion on this document asap. Do you have a 
> technical argument against 3825bis? The restructuring issues 
> can be handled at a later stage.
>

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Tue, 21 Apr 2009 08:53:52 -0700

I have a question about backward/forward compatibility between 3825 and
3825bis.  

As 3825bis appears to be redefining the resolution/uncertainty fields
how is a device supposed to know the difference between each version? Is
there a field in the 3825bis payload that identifies that it is a new
interpretation of the fields?

For example, if I have a device that has implemented 3825 (original) and
that device connects to an enterprise network that provides the
information - it understands the fields in one way. Then the device
moves to a hotspot that is providing location based on 3825bis.

How does that device learn that the fields should be interrupted
differently?

Allan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, April 21, 2009 8:06 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Consensus call: Basis for revisions to RFC 3825

Keith,

IEEE needs a conclusion on this document asap. Do you have a technical
argument against 3825bis? The restructuring issues can be handled at a
later stage.

- gabor

  >> >> Based on the prior thread about the scope of 3825 fixes, it
sounds

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 21 Apr 2009 19:56:03 +0300

I suggest to register a new datum. 

>[mailto:[email-masked]] On Behalf Of Allan Thomson (althomso)
>Sent: 21 April, 2009 18:54
>To: [email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]
>I have a question about backward/forward compatibility between 
>3825 and 3825bis.  
>
>As 3825bis appears to be redefining the resolution/uncertainty 
>fields how is a device supposed to know the difference between 
>each version? Is there a field in the 3825bis payload that 
>identifies that it is a new interpretation of the fields?
>
>For example, if I have a device that has implemented 3825 
>(original) and that device connects to an enterprise network 
>that provides the information - it understands the fields in 
>one way. Then the device moves to a hotspot that is providing 
>location based on 3825bis.
>
>How does that device learn that the fields should be 
>interrupted differently?
>
>Allan
>
>[mailto:[email-masked]] On Behalf Of [email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 21 Apr 2009 11:31:03 -0400

I share Keith's concern.  Fixing the document to meet the problem identified
should be a small change.  I'm okay with the technical approach to the fix
in 3825bis, but I'd prefer to just change the text that is affected and
leave the rest of 3825 alone.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Tuesday, April 21, 2009 11:21 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Consensus call: Basis for revisions to RFC 3825

I believe the restructuring issues will be lost if I accept the document
now.

Explain to me how we can minimise the restricturing and rewrite changes when
the document I am being asked to accept now appears to do pretty much a
total rewrite.

regards

Keith

---

From: Richard Barnes <[email-masked]>
Date: Tue, 21 Apr 2009 14:17:18 -0400

I had also proposed repurposing some of the 'datum' bits as 'version' bits

<http://www.ietf.org/mail-archive/web/geopriv/current/msg07085.html>

This has the same effect as registering three new datums (data?) -- one 
for each existing datum in the new interpretation.

--Richard

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 21 Apr 2009 22:01:32 +0300

Good. 

That's what we should do. 

>Sent: 21 April, 2009 21:17
>To: Hannes Tschofenig
>Cc: 'Allan Thomson (althomso)'; [email-masked]; 
>[email-masked]; [email-masked]
>This has the same effect as registering three new datums 
>(data?) -- one for each existing datum in the new interpretation.
>
>--Richard
>
>
>
>
>Hannes Tschofenig wrote:
>>> how is a device supposed to know the difference between 
>each version? 
>>> Is there a field in the 3825bis payload that identifies 
>that it is a 
>>> new interpretation of the fields?
>>>
>>> (original) and that device connects to an enterprise network that 
>>> provides the information - it understands the fields in one 
>way. Then 
>>> the device moves to a hotspot that is providing location based on 
>>> 3825bis.
>>>
>>> technical argument against 3825bis? The restructuring issues can be 
>>> handled at a later stage.
>>>
>>>  >been some radical restructuring, and because there have been 
>>> attempts to  >do a complete rewrite, this is not the 
>direction I want 
>>> to see this work  >go. Therefore I must still reject the 3825bis 
>>> draft as a starting point.
>>>  >
>>> >radical, i.e. no restructuring of the document, no rewrite of 
>>> clauses  >where we are not attempting to address problems, 
>and so on.
>>>  >
>>>  >regards
>>>  >
>>>  >Keith
>>>  >
>>>  >> From: Richard Barnes [mailto:[email-masked]]  >> Sent: 
>Tuesday, 
>>> April 21, 2009 11:21 AM  >> To: DRAGE, Keith (Keith)  >> Cc: 
>>> 'GEOPRIV'
>>>  >> Subject: Re: [Geopriv] Consensus call: Basis for 
>revisions to RFC
>>> 3825
>>>  >>
>>>  >> Keith,
>>>  >>
>>>  >> What Hannes said is correct: The question is whether the  >> 
>>> document in question should be used as a starting point for  >> the 
>>> WG document.  The issue of scope is independent of this  >> 
>question 
>>> (but related, since one would like the starting  >> point 
>to be close 
>>> to the goal), since the document will be  >> revised to meet the 
>>> needs of the WG.
>>>  >>
>>>  >> --Richard
>>>  >>
>>>  >>
>>>  >>
>>>  >> > I have some major problems with this question, and  >> 
>>> therefore the answer has to be no.
>>>  >> >
>>>  >> > The underlying basis for any revision has to be 
>RFC3825. I  >> 
>>>  >> > What we should be attempting to do is fix the problems in  >> 
>>> RFC 3825. So I would prefer questions asked on: Do we agree  >> on 
>>> the fix of a specific issues.
>>>  >> >
>>>  >> > Keith
>>>  >> >
>>>  >> >> From: [email-masked]  >> >> 
>>> [mailto:[email-masked]] On Behalf Of Richard 
>Barnes  >> >> 
>>> Sent: Tuesday, April 21, 2009 2:43 AM  >> >> To: 'GEOPRIV'
>>> sounds  >> >> like the closest of the three proposed documents to 
>>> what  >> people want  >> >> is 
>draft-thomson-geopriv-3825bis-03.  So 
>>> I would like to put the  >> >> following question to the group:
>>>  >> >>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 21 Apr 2009 22:09:01 +0300

... discussions about editorial details. Nice!

Any interest in making progress in this group? 
 
Ciao
Hannes

PS: New sections for
http://tools.ietf.org/html/draft-tschofenig-rai-reducing-delays-00 are
created here as we speak. 

>[mailto:[email-masked]] On Behalf Of Brian Rosen
>Sent: 21 April, 2009 18:31
>To: 'DRAGE, Keith (Keith)'; [email-masked]; [email-masked]
>Cc: [email-masked]
>I share Keith's concern.  Fixing the document to meet the 
>problem identified should be a small change.  I'm okay with 
>the technical approach to the fix in 3825bis, but I'd prefer 
>to just change the text that is affected and leave the rest of 
>3825 alone.
>
>Brian
>
>[mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
>Explain to me how we can minimise the restricturing and 
>rewrite changes when the document I am being asked to accept 
>now appears to do pretty much a total rewrite.
>
>technical 
>> attempts to
>>   >do a complete rewrite, this is not the direction I want 
>to see this 
>> work
>> clauses
>>   >> >> Subject: [Geopriv] Consensus call: Basis for 
>revisions to RFC 
>> 3825
>>   >> >>
>>   >> >> All,
>>   >> >>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 21 Apr 2009 16:00:50 -0400

It would take about 2 hours to modify 3825 to have the right technical
content if one had the .xml source.  I would do that, if the source was
available.  If the source is a word file, I could do that also.

But then again, maybe 5 or 6 of us could do that.

Is that what you want?  I'll find a couple of hours if someone gives me the
source file.

It is hard to see, with the current draft, what changed.  There is no good
reason for that.  It should be obvious what changed.

We want a fix, not a rewrite.

Brian

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Tuesday, April 21, 2009 3:09 PM
To: 'Brian Rosen'; 'DRAGE, Keith (Keith)'; [email-masked];
[email-masked]
Cc: [email-masked]

 
Ciao
Hannes

PS: New sections for

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 21 Apr 2009 15:20:51 -0500

Brain

This wasn't written in xml2rfc originally.

James

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 21 Apr 2009 16:35:07 -0400

Was it one of your MS Word creations?

Brian

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Tuesday, April 21, 2009 4:21 PM
To: Brian Rosen; 'Hannes Tschofenig'; 'DRAGE, Keith (Keith)';
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Consensus call: Basis for revisions to RFC 3825

Brain

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Apr 2009 17:37:57 -0500

What then is Section 1.2 if it is not an obvious description of what changed?

> Behalf Of Brian Rosen
> Sent: Wednesday, 22 April 2009 6:01 AM
> To: 'Hannes Tschofenig'; 'DRAGE, Keith (Keith)'; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Barnes

---

From: Richard Barnes <[email-masked]>
Date: Wed, 22 Apr 2009 23:32:12 -0400

Keith,

Could you clarify the extent to which your objections are related to the 
technical content of the draft, versus the format of it?  In other 
words, would you be satisfied if the current draft were rewritten with 
the same technical guidelines (2119 language, etc), but in a format that 
more closely resembles 3825?

Thanks,
--Richard

DRAGE, Keith (Keith) wrote:
>> revisions to RFC 3825
>> revisions to RFC 3825

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 23 Apr 2009 08:36:39 +0200

My understanding was that you have already done the consensus call on what improvements to do, which was accepted.

You then asked for adoption of a draft to reflect this and that is where the problems arise. (and yes Hannes the whole decision in that light is essentially an editorial one - the editorial nature was not initiated by me).

What I want to be able to see is the original document, which had IETF consensus, reflected in the revised document, with the exception of the technical revisions GEOPRIV had now agreed to which will change, i.e. start from RFC 3825 and make the minimal changes necessary to document the technical change. I believe this is what Brian proposed to do as well. 

So no restructuring and don't change change those bits that are not subject to the technical change we have agreed.

Still include a changes subclause from RFC 3825.

Ideally the diff tools should still work between the two documents, and I will not see virtually delete all and replace.

I would then add that if additional changes are required over and above the technical consensus call after the meeting, they require a separate consensus call, rather than trying to railroad through a complete replacement document.

regards

Keith

> Sent: Thursday, April 23, 2009 4:32 AM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]
> Could you clarify the extent to which your objections are 
> related to the technical content of the draft, versus the 
> format of it?  In other words, would you be satisfied if the 
> current draft were rewritten with the same technical 
> guidelines (2119 language, etc), but in a format that more 
> closely resembles 3825?
> 
> Thanks,
> --Richard
> 
> 
> 
> >>   >go. Therefore I must still reject the 3825bis draft as 
> a starting 
> >> point.
> >>   >
> >>   >> >> is draft-thomson-geopriv-3825bis-03.  So I would 
> like to put 
> >> the