Subject: [dhcwg] Re: Discussion for hiopt draft

From: Heejin Jang <[email-masked]>
Date: Sat, 07 Jul 2007 08:54:14 +0000 (GMT)

Hi, Bernie, David and folks.

For the sake of clarity, a DHCPv6 'main option' in my
previously sent mails is the option

whose option-code is assigned from the pool of the
regular 16-bit DHCPv6 option codes

(http://www.iana.org/assignments/dhcpv6-parameters)
instead of starting from sub-opt-code 0.

It does not mean that the main option cannot be used
within another option.

(So, Bernie & David, it is different from the
top-level option if you meant that a top-level option is

the option which cannot be included within another
option).

So if it does not make any big difference between the
following 1) & 2) from the perspective of

dhcpv6 design principle, I prefer to use 2).

(Anyway it will be decided also with the consensus of
MIP6 WG)

For a current 8-bit suboption in relay & HN
information option in hiopt-05,

1) 1st approach (like DHCPv6 IAADDR option)

- assign a 16-bit code/length from the pool of the
regular 16-bit DHCPv6 option codes

instead of starting from sub-opt-code 0

- This options will be delivered always as included in
relay & HN information options.

2) 2nd approach (like DHCPv4 suboption)

- For a current 8-bit suboption in relay & HN
information option in hiopt-05,

just extend a 8-bit code/length to a 16-bit and start
from sub-opt-code 0.

- Regards,

Heejin.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 9 Jul 2007 10:14:03 -0700

This message came through all in HTML, so I'm unsure if other folks were
able to read it - I've included it in entirety below rather than just
the one piece that I wish to respond to.

All I wanted to say is I agree with your election to use the second
method that you've outlined.  I understand the HIOPT options to be
multiple disparate values that are "always sent" when they are
available, and not subject to parameter request.

But I'd like to reiterate a request that you start from sub-option
code 1.  All other sub option spaces so far have done this, and the
top level DHCP codes themselves have avoided the use of zero, I think
due to its 'magic value' ancestry in DHCPv4, and the propensity for
both these protocols to be served with common sourcecode.

I'd have to add another branch to our parsing loop to support codes
beginning with zero, which is doable, but there hasn't been any other
reason to do so yet.

On Sat, Jul 07, 2007 at 08:54:14AM +0000, Heejin Jang wrote:
> For the sake of clarity, a DHCPv6 'main option' in my previously sent mails is
> the option
> 
> whose option-code is assigned from the pool of the regular 16-bit DHCPv6 option
> codes
> 
> (http://www.iana.org/assignments/dhcpv6-parameters) instead of starting from
> sub-opt-code 0.
> 
> It does not mean that the main option cannot be used within another option.
> 
> (So, Bernie & David, it is different from the top-level option if you meant
> that a top-level option is
> 
> the option which cannot be included within another option).
> 
> 
> 
> So if it does not make any big difference between the following 1) & 2) from
> the perspective of
> 
> (Anyway it will be decided also with the consensus of MIP6 WG)
> 
> 
> 
> For a current 8-bit suboption in relay & HN information option in hiopt-05,
> 
> - assign a 16-bit code/length from the pool of the regular 16-bit DHCPv6 option
> codes
> 
> - This options will be delivered always as included in relay & HN information
> options.
> 
> 
> 
> - For a current 8-bit suboption in relay & HN information option in hiopt-05,
> 
> just extend a 8-bit code/length to a 16-bit and start from sub-opt-code 0.
> 
> 
> 
> - Regards,
> 
> Heejin.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg