Outstanding job Bernard.
Cheers,
Martin
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Richard L. Barnes
Sent: Thursday, 6 January 2011 5:17 AM
To: Richard L. Barnes
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Consensus call: DHCP option numbers
<hat type="individual"/>
I have reviewed the changes in Bernard's draft text, and they look good to me.
--Richard
On Jan 5, 2011, at 1:13 PM, Richard L. Barnes wrote:
> Dear working group,
>
> In order to get some sort of gauge of consensus, please take a look at Bernard's draft document and indicate whether these changes are OK with you.
>
> A diff can be found here:
> <http://goo.gl/EN1em>
>
> Please send responses to the list no later than Wednesday, 12 Jan 2011.
>
> Thanks,
> --Richard
>
>
>
>
> On Jan 5, 2011, at 1:03 AM, Bernard Aboba wrote:
>
>> I've gone through the document and made changes to define a new DHCPv4 option.
>>
>> A strawman is available here:
>> http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-15.txt
>>
>>
>> -----Original Message-----
>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
>> Sent: Tuesday, January 04, 2011 4:01 PM
>> To: James M. Polk; Bernard Aboba; geopriv@ietf.org
>> Cc: rdroms@cisco.com
>> Subject: RE: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis
>>
>> It looks like we should take another pass at this in the working group.
>>
>> 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
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
