in-line
At 10:53 AM 1/2/2011, Bernard Aboba wrote:
>Content-Type: multipart/alternative;
> boundary="----=_NextPart_000_0349_01CBAA5A.81061870"
>Content-Language: en-us
>
>Martin --
>
>If a new DHCP Option Code were to be allocated for RFC 3825bis,
>would we still keep the material in the document relating to version 0?
>
>Note that even if version 0 is removed from the document, it might
>still make sense to keep the format as it is (including the version field).
>
>This is because the option may be processed in "upper layers" who
>may not see the option code (or in the case of IEEE 802.11, there
>may not be an option code).
>
>So it would be useful to have the "version" embedded in the option,
>so that the "upper layer" would know how to process it.
>
>However it's not clear to me that there would ever be a reason for a
>server to send a version 0 with a new option code (or for a client
>to support receiving it).
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).
>
>If a new option code were to be allocated, then I'd assume that
>version 1 would be made mandatory to implement with the new option
>code (both on client and server).
I would assume that too.
>
>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.
>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.
>
>If there isn't a situation where a client would ever want to receive
>version 0 with the new option code, and the server wouldn't want to
>send it, then this begs the question of how much material on version
>0 is useful in the document.
Are you suggesting 3825bis as written is completely scrapped? This
would take us back to the individual -00 stage, because nothing
that's going to be written in that new ID will have been accepted by
the WG. That seems like a lot of work and time that's not as
necessary as it needs to be.
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.
James
>
>
>Martin Thompson said:
>
> > Martin - sorry, but I'm not clear on your response. What is the "it"
> > you refer to as "Isn't it only a problem..."?
>
>"it" being the backwards compatibility problem. Do we have to
>assume that deprecating 3825 leads to IEEE (for example) using the
>new RFC? Or do they keep their existing interpretation of the
>fields until they update their specifications.
> > Isn't the interpretation of the resolution/uncertainty field different
> > between versions 0 and 1?
>
>Yes, it's different. However, there is some doubt over whether a v0
>resolution field can be reliably created.
>
> > I have a concern that v0 clients won't be able to request the v0
> > option or report that it is unable to use the v1 [??] option.
>
>Your concern is a valid one. I'm not debating that. I'm simply
>suggesting that maybe it doesn't matter due to there being very few v0 clients.
> > It seems that reusing the option code at least introduces some
> > unnecessary complexity. I recommend using a new option code to avoid
> > that overhead.
>
>A new code is OK with me. It might be a little over cautious, but
>then it probably won't hurt either.
>
>======================================
>As noted in the tracker, several IESG members have raised the
>question of whether it makes sense to revise the original RFC 3825
>DHCP option or just to create a new DHCP option with a new code point.
>
>Here are the potential choices for moving forward:
>
>a. Continue to use a single option code for both versions 0 and
>1. In this approach the document would be left more or less as it
>is, but additional material would be added to the discussion of
>backward compatibility in Section 2.2.1 to explain why the WG took
>this approach.
>
>b. Allocate a new option code for the version 1 format, leave
>material on the original option in the document. In this approach,
>the document would continue to revise RFC 3825, but would also
>define new DHCPv4 and DHCPv6 options. While this approach would be
>consistent with the GEOPRIV WG charter (which describes the goal of
>the work item as "to obsolete 3825"), it is not clear whether there
>would be enough clarifications/revisions to RFC 3825 material to
>justify keeping that material in it.
>
>c. Allocate new DHCPv4 and DHCPv6 option codes for the new format,
>but remove material relating to the original RFC 3825 format. This
>approach would define new option codes, but would remove discussion
>of option code 123. Such a document would probably be quite a bit
>shorter, since material relating to backward compatibility could be removed.
>
>One question relating to this approach would be whether the new
>document would obsolete RFC 3825 or not. Since the GEOPRIV WG
>charter lists the work item as "Submit an draft for DHCP geodetic
>location to the IESG for publication as PS to obsolete 3825" if the
>new document did not obsolete RFC 3825 then a charter change would
>seem to be required.
>_______________________________________________
>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
