Martin --
If a new DHCP Option Code were to be allocated for RFC 3825bis, would we still keep the material in the document relating to version 0?
Note that even if version 0 is removed from the document, it might still make sense to keep the format as it is (including the version field).
This is because the option may be processed in "upper layers" who may not see the option code (or in the case of IEEE 802.11, there may not be an option code).
So it would be useful to have the "version" embedded in the option, so that the "upper layer" would know how to process it.
However it's not clear to me that there would ever be a reason for a server to send a version 0 with a new option code (or for a client to support receiving it).
If a new option code were to be allocated, then I'd assume that version 1 would be made mandatory to implement with the new option code (both on client and server).
Would there ever be a situation where you'd send both the old option (version 0) as well as the new option (also with version 0)? It seems to me that if both options were sent, the new option would need to be version 1.
If there isn't a situation where a client would ever want to receive version 0 with the new option code, and the server wouldn't want to send it, then this begs the question of how much material on version 0 is useful in the document.
Martin Thompson said:
> Martin - sorry, but I'm not clear on your response. What is the "it"
> you refer to as "Isn't it only a problem..."?
"it" being the backwards compatibility problem. Do we have to assume that deprecating 3825 leads to IEEE (for example) using the new RFC? Or do they keep their existing interpretation of the fields until they update their specifications.
> Isn't the interpretation of the resolution/uncertainty field different
> between versions 0 and 1?
Yes, it's different. However, there is some doubt over whether a v0 resolution field can be reliably created.
> I have a concern that v0 clients won't be able to request the v0
> option or report that it is unable to use the v1 [??] option.
Your concern is a valid one. I'm not debating that. I'm simply suggesting that maybe it doesn't matter due to there being very few v0 clients.
> It seems that reusing the option code at least introduces some
> unnecessary complexity. I recommend using a new option code to avoid
> that overhead.
A new code is OK with me. It might be a little over cautious, but then it probably won't hurt either.
======================================
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.
