Subject: [Geopriv] RFC3825bis

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 22 Apr 2009 23:07:04 +0300

Hi all, 

To provide some constructive input to the ongoing discussion I wanted to
know how RFC3825bis would look like in case it is very much based on the
text from RFC 3825. 

Here is the outcome: 
http://www.tschofenig.priv.at/svn/draft-bond-geopriv-dhcp-geo/draft-bond-geo
priv-dhcp-geo-00.txt

This version obviously does not provide the DHCPv6 encoding. 

As you can see from the diff version there are still a number of changes,
namely: 
http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/rfc/rfc3825.txt&url2
=http://www.tschofenig.priv.at/svn/draft-bond-geopriv-dhcp-geo/draft-bond-ge
opriv-dhcp-geo-00.txt

* The I-D templates changed in the meanwhile. 
* The previous draft was written in Word and this version in XML2RFC and
hence the layout is a bit different. For example, the appendix is in a
different place. 
* The resolution to uncertainty change impacted number of parts in the
document, including the re-written example. 
* The example contains the translation to GML as well. 
* The document does not repeat the datum values from RFC 3825. 
* The ack section will be different and is currently empty. 
* I believe that the RFC editor uses symbolic references these days. 

I would still change a number of things throughout the document. For
example, I wouldn't call "GPS" an exotic mechanism.

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 22 Apr 2009 20:57:26 -0500

Hannes, Mr Bond,

Evidently Mr. Bond has lots of time on his hands.

I could review this document and produce a fairly long list of problems.  Most relate to the text that Mr. Bond didn't change.  Casually reading through, I also see missed changes, like the altitude code of 0 not being defined.

For those folks who would prefer this approach, could you please explain why?  I'm not convinced by vague assertions of personal preference.  If this comes down to the time that it takes to validate Section 1.2 of the proposed draft, then that is a valid concern.  However, when weighed against the cost of re-implementing each of these changes based on the original text, my belief is that we are better served by what is in 3825bis.  

For the most part, the cost of checking Section 1.2 is only incurred by two groups: those reviewing the revised document and those who have existing implementations.  Since the latter group is known to be very small, I might reach an uncharitable and - undoubtedly - unfair conclusion about the motivations behind the proposal to adopt Mr Bond's draft.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Thursday, 23 April 2009 6:07 AM
> To: [email-masked]
> Subject: [Geopriv] RFC3825bis
> 
> Hi all,
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> 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]

---

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

FWIW, Section 1.2 in the current draft is incomplete.  E.g., it doesn't 
mention the addition of a DHCPv6 option format.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 23 Apr 2009 11:07:47 +0300

RFC3825 does not define a DHCPv6 format and hence this document did not
include one either. 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Richard Barnes
>Sent: 23 April, 2009 06:48
>To: Thomson, Martin
>Cc: [email-masked]
>Subject: Re: [Geopriv] RFC3825bis
>
>FWIW, Section 1.2 in the current draft is incomplete.  E.g., 
>it doesn't mention the addition of a DHCPv6 option format.
>
>
>Thomson, Martin wrote:
>> Hannes, Mr Bond,
>> 
>> I could review this document and produce a fairly long list 
>of problems.  Most relate to the text that Mr. Bond didn't 
>change.  Casually reading through, I also see missed changes, 
>like the altitude code of 0 not being defined.
>> 
>> For those folks who would prefer this approach, could you 
>please explain why?  I'm not convinced by vague assertions of 
>personal preference.  If this comes down to the time that it 
>takes to validate Section 1.2 of the proposed draft, then that 
>is a valid concern.  However, when weighed against the cost of 
>re-implementing each of these changes based on the original 
>text, my belief is that we are better served by what is in 3825bis.  
>> 
>> For the most part, the cost of checking Section 1.2 is only 
>incurred by two groups: those reviewing the revised document 
>and those who have existing implementations.  Since the latter 
>group is known to be very small, I might reach an uncharitable 
>and - undoubtedly - unfair conclusion about the motivations 
>behind the proposal to adopt Mr Bond's draft.
>> 
>> --Martin
>> 
>>> To provide some constructive input to the ongoing 
>discussion I wanted
>>> to

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 23 Apr 2009 11:13:48 +0300

Hi Martin, 

>Evidently Mr. Bond has lots of time on his hands.

Indeed strange. He could have contributed code instead...

>
>I could review this document and produce a fairly long list of 
>problems.  Most relate to the text that Mr. Bond didn't 
>change.

It did not change when it is not in RFC 3825 already.

>  Casually reading through, I also see missed changes, 

True. RFC 3825 does not register it with IANA. 

Ciao
Hannes

>> To provide some constructive input to the ongoing discussion 
>I wanted 
>> to know how RFC3825bis would look like in case it is very much based 
>> on the text from RFC 3825.
>> 
>> Here is the outcome:
>http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/rfc/rfc3825.tx
>> t
>> &url2
>> * The previous draft was written in Word and this version in XML2RFC 
>> and hence the layout is a bit different. For example, the 
>appendix is 
>> in a different place.