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
