Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

Thomas Huth <THUTH@de.ibm.com> Sat, 10 October 2009 12:48 UTC

Return-Path: <THUTH@de.ibm.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75DDA3A68A6 for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 05:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.927
X-Spam-Level:
X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQj6uLn8NSl8 for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 05:48:08 -0700 (PDT)
Received: from mtagate5.de.ibm.com (mtagate5.de.ibm.com [195.212.17.165]) by core3.amsl.com (Postfix) with ESMTP id 4B32E3A672F for <dhcwg@ietf.org>; Sat, 10 Oct 2009 05:48:07 -0700 (PDT)
Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate5.de.ibm.com (8.13.1/8.13.1) with ESMTP id n9ACnrIi028734 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 12:49:53 GMT
Received: from d12av05.megacenter.de.ibm.com (d12av05.megacenter.de.ibm.com [9.149.165.216]) by d12nrmr1707.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n9ACnrCn2699516 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 14:49:53 +0200
Received: from d12av05.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n9ACnqRd021912 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 14:49:52 +0200
Received: from d12ml072.megacenter.de.ibm.com (d12ml072.megacenter.de.ibm.com [9.149.166.115]) by d12av05.megacenter.de.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n9ACnqUl021909 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 14:49:52 +0200
In-Reply-To: <42BCDBAE-673E-44FA-B44C-42A8149D6838@nominum.com>
References: <994ABFCB-3ABF-484C-9855-1EEACC663CF4@nominum.com> <200910061918.n96JI5Nv005405@cichlid.raleigh.ibm.com> <42BCDBAE-673E-44FA-B44C-42A8149D6838@nominum.com>
X-KeepSent: 9033DA93:0AB61687-C125764B:0044CD57; type=4; name=$KeepSent
To: dhcwg@ietf.org
X-Mailer: Lotus Notes Release 8.5 December 05, 2008
Message-ID: <OF9033DA93.0AB61687-ONC125764B.0044CD57-C125764B.0045CA16@de.ibm.com>
From: Thomas Huth <THUTH@de.ibm.com>
Date: Sat, 10 Oct 2009 14:42:17 +0200
X-MIMETrack: Serialize by Router on D12ML072/12/M/IBM(Release 8.0.1|February 07, 2008) at 10/10/2009 14:49:52
MIME-Version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Subject: Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Oct 2009 12:48:09 -0000

Damien Neil wrote on 06/10/2009 22:03:45:

> I think that ordering of options should not be significant, although
> I'm not convinced that non-significant ordering is sufficient reason
> to use multiple instances of an option.
>
> One of my concerns is the complexity of presenting option data to a
> user--to a server administrator specifying what to send to a client,
> or to a network configuration script executed by a client.
>
> With DHCPv4 single-instance options, you can say "the value of option
> <foo> is <bar>".  For example, in ISC dhcpd:
>
>    option domain-name-servers = 10.0.0.1, 10.0.0.2;
>
> When you introduce multiple-instance options, this becomes more
> complicated.  There are various means of presenting this to the user,
> but I don't find any of them truly satisfactory.

>From a user point of view (I am only a user of dhcp servers, never wrote
one on my own), I would be fine with specifying multiple "option boot-url
= ..." lines in the configuration file. Please excuse my ignorance, but I
can't see a real problem with this, so I'd like to know what are your exact
concerns about this?

> I note that ISC dhcpd doesn't appear to support defining multiple
> instances of an option at this time.  The dhcp-options(5) manpage
> states, "normally [multiply-instanced options] are options which are
> digested by the DHCP protocol software, and not by users or
> applications."  (If I'm wrong about this, and such support does exist
> in ISC dhcpd, my apologies.)
>
> I'm not absolutely opposed to multiply-instanced options, but I do
> think there's more implementation complexity to them than may first
> meet the eye.

Well, according to the RFC 3315:

"Unless otherwise noted, each option may appear only in the options
 area of a DHCP message and may appear only once.  If an option does
 appear multiple times, each instance is considered separate and the
 data areas of the options MUST NOT be concatenated or otherwise
 combined."

For me, that sounds like multiple-instance options are allowed if there is
a reason for using them. So I think your dhcp server should somehow support
that in its configuration file, too...?


Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Erich Baier          
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: +49-7031-16-2183          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294