James Polk said:
> If I understand this correctly, we would have the following scenario:
>
> - version 0 servers would send Option 123
> - version 1 servers would send Option 500 (or whatever new code is assigned)
>
> Under this scenario, Option 500 servers wouldn't *ever* send Option
> 123 (i.e., version 0), but would (normatively) point to RFC 3825 for
> those wanting to send Option 123 (i.e., version 0).
[BA] A DHCP client could indicate its preference based on option code no?
So a client could request Option 123 or Option 500, or both, and a DHCP
server could respond based on that.
Having a server always send Option 500 (even to a client that only supports
Option 123) seems like a bad idea (and doesn't solve the backward compatibility problem).
> >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)?
>
> If there ever was this desire, then both Options 123 and 500 would be
> included in either the DHCP request or reply message - as I believe I
> see a clear separation between v0 and v1 at this point.
[BA] Right. So each option corresponds to only one version.
> >It seems to me that if both options were sent, the new option would
> >need to be version 1.
>
> Specifically, I believe the two Options (123 and 500) would be enough
> of a separation. Pragmatically, for readers, I believe stating that
> Option 500 is version 1 would make more sense to make sure to remove
> another level of confusion that could occur.
[BA] Right. So we could keep the "Ver" field, but state that the field
MUST be 1 for Option 500.
> If we go down this path, knowing if we make the change to remove the
> "implement version 0 this way" from the text - it's headed back to
> the WG regardless, we take the easier route and just modify out the
> existing version 0 text, and instead point normatively to RFC 3825
> for those interested in version 0, and keep as much of the version 1
> text as possible. This should result in a single new rev for WGLC
> confirmation and get this back to the IESG for their consideration.
[BA] Agree that modifying/removing "version 0" material would require
the document to go back to the WG. Also agree that we should keep
(and leave alone) the version 1 material.
As for pointing normatively to RFC 3825, there seems to be some material
in RFC 3825bis that attempts to "clarify" RFC 3825. So it seems like we have
the following choices:
a. Have RFC 3825bis define both Options 123 (IPv4 only) and Option 500 (IPv4 and IPv6).
In this case, RFC 3825bis would "Obsolete: RFC 3825".
b. Have RFC 3825bis define only Option 500 (IPv4 and IPv6).
In this case, RFC 3825bis might "Update: RFC 3825" (or maybe not).
It would appear to me that the GEOPRIV WG charter seems to imply Approach A:
Sep 2009 Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825
