in-line
At 12:57 PM 1/3/2011, Bernard Aboba wrote:
>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?
[JMP] yes, but including either Option code or include both
>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).
[JMP] I believe DHCP clients that receive Options they don't
understand simply ignore them, so if a client receives an Option 500,
it should be ignored and therefore not cause backwards compatibility
issues, right?
That said - this RFC-to-be needs to state somewhere something like:
If a client requests only Option 123 [RFC3825], the server SHOULD NOT
transmit an Option 500 (defined within this document) because it could
lead to interoperability issues.
Because the two Options would look so much alike, we shouldn't chance
sending the new Option to the clients who only support the old
version from 3825. I could be over doing this problem, as the SHOULD
NOT should cover this new doc.
> > >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.
[JMP] I think introducing the VER field in Option 500 creates the
ability for a future version 2, which is probably a good thing, so I
think it ought to stay.
> > 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.
[JMP] agreed
>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).
[JMP] I think you have an option 'b' and 'c' in your above option
'b.'. The difference being whether or not you have 3825bis update
3825 (new option b), or leave it alone (which becomes option c).
IMO - within this context, the new option b is the one to go with,
because of the clarifying text
>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
[JMP] I agree as well, and this is a bit of a sticking point
James
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
