Subject: Re: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis

From: Bernard Aboba <[email-masked]>
Date: Sun, 2 Jan 2011 08:53:19 -0800

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 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). 

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)?   It seems to
me that if both options were sent, the new option would need to be version
1. 

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. 

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.

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Jan 2011 11:24:30 -0600

Bernard

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.

>(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

>"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.
>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.
>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.
>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Jan 2011 10:57:45 -0800

> those wanting to send Option 123 (i.e., version 0).

[BA] A DHCP client could indicate its preference based on option code no? 
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). 

> see a clear separation between v0 and v1 at this point.

[BA] Right.  So each option corresponds to only one version. 
 
> 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. 

> 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.

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). 

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 03 Jan 2011 14:06:07 -0600

Bernard

in-line

>[BA] A DHCP client could indicate its preference based on option code no?

[JMP] yes, but including either Option code or include both

>Option 123) seems like a bad idea (and doesn't solve the backward 

[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.

>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.

>(and leave alone) the version 1 material.

[JMP] agreed

>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

>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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 5 Jan 2011 08:01:13 +0800

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...

> [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.  

> it should be ignored and therefore not cause backwards compatibility

[MT]  That's the way it works.  A lot of DHCP servers provide Options that aren't used.

>     lead to interoperability issues.

[MT] The advice on "don't provide unless explicitly requested" should be sufficient.

> ability for a future version 2, which is probably a good thing, so I

[MT] Sounds reasonable.  The hypothetical Option 500 could set "Ver" to 0, but that's not really going to help.

> >(and leave alone) the version 1 material.

[MT] Works for me.
 
> 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.

> [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.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Jan 2011 22:03:54 -0800

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:[email-masked]] 
Sent: Tuesday, January 04, 2011 4:01 PM
To: James M. Polk; Bernard Aboba; [email-masked]
Cc: [email-masked]
Subject: RE: [Geopriv] Options for Resolution of DISCUSS comments on RFC 3825bis

More inline...

[MT] Works for me.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 5 Jan 2011 13:13:38 -0500

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 5 Jan 2011 13:16:36 -0500

<hat type="individual"/>

I have reviewed the changes in Bernard's draft text, and they look good to me.
--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 6 Jan 2011 06:12:17 +0800

I have also reviewed the proposed changes.  They look good.

Outstanding job Bernard.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Thursday, 6 January 2011 5:17 AM
To: Richard L. Barnes
Cc: [email-masked]
Subject: Re: [Geopriv] Consensus call: DHCP option numbers

<hat type="individual"/>