Subject: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis

From: Bernard Aboba <[email-masked]>
Date: Sat, 4 Dec 2010 13:12:24 -0800

As noted in the tracker, several IESG members have raised the question of whether it makes sense to revise the original RFC 3825 DHCP option or just to create a new DHCP option with a new code point.  

Here are the potential choices for moving forward:

a. Continue to use a single option code for both versions 0 and 1.  In this approach the document would be left more or less as it is, but additional material would be added to the discussion of backward compatibility in Section 2.2.1 to explain why the WG took this approach.

b. Allocate a new option code for the version 1 format, leave material on the original option in the document.  In this approach, the document would continue to revise RFC 3825, but would also define new DHCPv4 and DHCPv6 options.  While this approach would be consistent with the GEOPRIV WG charter (which describes the goal of the work item as "to obsolete 3825"), it is not clear whether there would be enough clarifications/revisions to RFC 3825 material to justify keeping that material in it.  

c. Allocate new DHCPv4 and DHCPv6 option codes for the new format, but remove material relating to the original RFC 3825 format.  This approach would define new option codes, but would remove discussion of option code 123.  Such a document would probably be quite a bit shorter, since material relating to backward compatibility could be removed.  

One question relating to this approach would be whether the new document would obsolete RFC 3825 or not.  Since the GEOPRIV WG charter lists the work item as "Submit an draft for 
DHCP geodetic location to the IESG for publication as PS to obsolete 
3825"  if the new document did not obsolete RFC 3825 then a charter change would seem to be required.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 6 Dec 2010 13:38:36 +0800

(I sent this privately, thinking the CC-list included the WG, so I'll resend an expanded version.)

All the version change really does is change the interpretation of fields that probably couldn't have been reliably populated in the first place.  The only (rightful) concern is for DHCP clients that might reject the new format due to the apparent unknown datum field.

It turns out that this isn't that serious and code reuse is OK for two reasons:

1) There was sufficient ambiguity in the interpretation of the existing code that it would be difficult to implement reliably.

2) There were no known implementations of the DHCP option*.

As far as publicly available implementations, the one provided by Klaus Darilion [1] uses the "v1" interpretation described in this new document (actually the first revision of my proposal).  I personally am not aware of anything more advanced in deployment than that.

As Marc points out, the _format_ is used by IEEE.  Since they use their own identifier space, they probably have to deal with the backward compatibility problems.  But apparently they already modified the encoding anyhow, so it's really just a format _based on RFC3825_.

LLDP-MED and SUPL also cite the format.  For both, I'm not aware of an actual implementation.  (Both of these specifications are grossly underspecified.)

In all these cases, by revising the RFC, we're only changing the interpretation of the three resolution/uncertainty fields.  Fields that couldn't otherwise be used.

The idea of peaceful coexistence of versions is a nice one.  It's not really necessary in this case.

* Of course, given evidence of more serious deployment of the DHCP option, that changes completely.

--Martin

On 2010-12-05 at 08:12:24, Bernard Aboba wrote:
> As noted in the tracker, several IESG members have raised the question
> of whether it makes sense to revise the original RFC 3825 DHCP option
> or
> just to create a new DHCP option with a new code point.
> 
> a. Continue to use a single option code for both versions 0 and 1.  In
> this approach the document would be left more or less as it is, but
> additional material would be added to the discussion of backward
> compatibility in Section 2.2.1 to explain why the WG took this
> approach.
> 
> b. Allocate a new option code for the version 1 format, leave material
> on the original option in the document.  In this approach, the document
> would continue to revise RFC 3825, but would also define new DHCPv4 and
> DHCPv6 options.  While this approach would be consistent with the
> GEOPRIV WG charter (which describes the goal of the work item as "to
> obsolete 3825"), it is not clear whether there would be enough
> clarifications/revisions to RFC 3825 material to justify keeping that
> material in it.
> 
> c. Allocate new DHCPv4 and DHCPv6 option codes for the new format, but
> remove material relating to the original RFC 3825 format.  This
> approach
> would define new option codes, but would remove discussion of option
> code 123.  Such a document would probably be quite a bit shorter, since
> material relating to backward compatibility could be removed.
> 
> One question relating to this approach would be whether the new
> document
> would obsolete RFC 3825 or not.  Since the GEOPRIV WG charter lists the
> work item as "Submit an draft for DHCP geodetic location to the IESG
> for
> publication as PS to obsolete 3825"  if the new document did not
> obsolete RFC 3825 then a charter change would seem to be required.

---

From: Marc Linsner <[email-masked]>
Date: Tue, 07 Dec 2010 09:18:48 -0500

Martin,

The WG decided to support 3825, hence the backward compatibility.

In your opinion, what is the downside of a new DHCP option for the
additional format?

It would provide the utmost in backward compatibility and DHCP servers
wouldn't have to make the choice as to which option to use, it could
simply send both of them.

Thanks,

-Marc-

-----Original Message-----
From: "Thomson, Martin" <[email-masked]>
Date: Mon, 6 Dec 2010 13:38:36 +0800
To: Bernard Aboba <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC
3825bis

>All the version change really does is change the interpretation of fields
>that probably couldn't have been reliably populated in the first place.
>The only (rightful) concern is for DHCP clients that might reject the new
>format due to the apparent unknown datum field.
>
>1) There was sufficient ambiguity in the interpretation of the existing
>code that it would be difficult to implement reliably.
>
>As far as publicly available implementations, the one provided by Klaus
>Darilion [1] uses the "v1" interpretation described in this new document
>(actually the first revision of my proposal).  I personally am not aware
>of anything more advanced in deployment than that.
>
>As Marc points out, the _format_ is used by IEEE.  Since they use their
>own identifier space, they probably have to deal with the backward
>compatibility problems.  But apparently they already modified the
>encoding anyhow, so it's really just a format _based on RFC3825_.
>
>LLDP-MED and SUPL also cite the format.  For both, I'm not aware of an
>actual implementation.  (Both of these specifications are grossly
>underspecified.)
>
>In all these cases, by revising the RFC, we're only changing the
>interpretation of the three resolution/uncertainty fields.  Fields that
>couldn't otherwise be used.
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv