Let's not change too much in the process in the interests of getting this done quickly.
More inline...
On 2011-01-04 at 07:06:07, James M. Polk wrote:
> >[BA] A DHCP client could indicate its preference based on option code
> no?
>
> [JMP] yes, but including either Option code or include both
[MT] Option 55 (and equivalent DHCPv6) would be the way this is done, the client can list its preferred option number. A note on how this works for versioning purposes would be nice.
[MT] Keep in mind that advice in RFC 4776 suggests that a server should never send this information unsolicited. If we maintain that advice, then there should be no 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?
[MT] That's the way it works. A lot of DHCP servers provide Options that aren't used.
> 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.
[MT] The advice on "don't provide unless explicitly requested" should be sufficient.
> > > >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.
[MT] Sounds reasonable. The hypothetical Option 500 could set "Ver" to 0, but that's not really going to help.
> >[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
[MT] Works for me.
> >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
[MT] I'd prefer that too. No point in discarding all that work that we've done in clarifying everything.
> >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
[MT] I can't see this being a major obstacle if we decide that this is the right way to proceed.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
