Subject: Re: Re: [dhcwg] Re: Discussion for hiopt draft

From: Heejin Jang <[email-masked]>
Date: Mon, 16 Jul 2007 02:24:30 +0000 (GMT)

Hi, David.

Thanks for sending my mail again encoded in text.
As I sent a mail previously (as a response to  your first comments), 
we'll start the sub-opt-code from 1 not 0 as you suggested if the 2nd method is finally decided. :)

- Regards, 
Heejin.

------- Original Message -------
Sender : Heejin Jang<[email-masked]> R&D Staff Member/Communication & Networking Lab/Samsung Advanced Institute of Technology
Date   : 2007-07-16 11:12
Title  : Re: [dhcwg] Re: Discussion for hiopt draft

------- Original Message -------
Sender : David W. Hankins<[email-masked]>
Date   : 2007-07-10 02:14
Title  : [dhcwg] Re: Discussion for hiopt draft

This message came through all in HTML, so I&&#35;39;m unsure if other folks were
able to read it - I&&#35;39;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&&#35;39;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&&#35;39;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 &&#35;39;magic value&&#35;39; ancestry in DHCPv4, and the propensity for
both these protocols to be served with common sourcecode.

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

On Sat, Jul 07, 2007 at 08:54:14AM +0000, Heejin Jang wrote:
> Hi, Bernie, David and folks.
> 
> 
> 
> For the sake of clarity, a DHCPv6 &&#35;39;main option&&#35;39; 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.

-- 
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&&#35;39;t do it right the first time,
Software Engineer             you&&#35;39;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