Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-05 - how to proceed?

Jarrod Johnson <jarrod.b.johnson+dhcwg@gmail.com> Sat, 10 October 2009 20:17 UTC

Return-Path: <jarrod.b.johnson@gmail.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 D5EEB3A68DA for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 13:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9w8bwC35Froh for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 13:17:43 -0700 (PDT)
Received: from mail-yw0-f189.google.com (mail-yw0-f189.google.com [209.85.211.189]) by core3.amsl.com (Postfix) with ESMTP id 92DBF3A6819 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 13:17:43 -0700 (PDT)
Received: by ywh27 with SMTP id 27so1149305ywh.31 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 13:19:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=trhPD1wPGLVVWGtbbY+PW7fASFt1/bctxx82l+eQruk=; b=r71lnb0Kth0k1LwlPrR1COTi75UAoaO2QZjmB5J8BQjYKLqB9wMBtEO2bqBDCIq30E 0xin357lfZnbNDrkjj+rZW2pem2BhrEAmT6KFNidLT6ANIvCtYdyRYFNa5y1+l6+kCZB HMz8aGaa5x/1x53x4cNYwniBxHqL/KgMm/TJs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WKKd15YU1uO0cqxv+5Rxnb++69VHPX9r/g6LBrgCiIkzxEkVPNpd1kKRVeC7Ij6TGz Byic1LKxvI+jZv5l3yQDe4weDSGtw2dRIODe6U1nCxMR691d2+69yT62qwukRW7y1S9S 19oCTPc5O0Pv4PHU4Z044mUSbEonEmv7GIgY0=
MIME-Version: 1.0
Sender: jarrod.b.johnson@gmail.com
Received: by 10.150.43.17 with SMTP id q17mr7227357ybq.197.1255205968400; Sat, 10 Oct 2009 13:19:28 -0700 (PDT)
In-Reply-To: <FBD14811-7C9A-4FCB-8707-071A7CA12B96@nominum.com>
References: <200910062234.AAA07005@TR-Sys.de> <AD61797F-DB2D-4889-8888-5339521ADE8F@nominum.com> <OF029AB4A7.6EEA954A-ONC125764B.004E95CE-C125764B.00536F30@de.ibm.com> <FBD14811-7C9A-4FCB-8707-071A7CA12B96@nominum.com>
Date: Sat, 10 Oct 2009 16:19:28 -0400
X-Google-Sender-Auth: 50c1d2fe827aee9b
Message-ID: <fab4e42a0910101319y6d223872s6958cad0450aa60b@mail.gmail.com>
From: Jarrod Johnson <jarrod.b.johnson+dhcwg@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>, Thomas Huth <THUTH@de.ibm.com>
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-05 - how to proceed?
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 20:17:43 -0000

I know that gPXE and pxelinux also support distinct sets of extended
options (sometimes mixing and matching using a 'plain' option and
using an option encapsulating other options).  Even with that all in
place, they almost all additionally reference a configuration file
(which they usually do via excessive requests based on their identity,
though I usually drive a more specific behavior through a dhcp
option).  For second-stage loaders with rich scripting behaviors,
cramming that into a DHCP option would probably not be nice for many
administrators.

With all that said, it seems exceedingly common that at least two
things are commonly referenced in a potentially common way in a
typical netboot fashion:
-The second stage loader executable code
-Optionally, a configuration file or script for that second stage
loader, that typically points to other requisite files that vary from
OS to os (i.e. multiboot images, or a linux kernel/initrd, and various
things in a Windows BCD file, though the Windows search for BCD file
is less flexible today than I would like)

As a potential slight tangent, this discussion has been focused on
netboot scenarios focused on downloading an executable and running it,
but what about registering network based SAN strategies (i.e. iSCSI
per RFC 4173)?  One aspect I didn't like of that standard was to imply
it was used for configuring a boot volume only with the expectation
that it would be the boot device of that boot, as I have a scenario
where the two actions on the client network device are separate (i.e.
it will configure itself and connect to the iSCSI target, and
configure firmware tables, but then still allow me to boot via
'filename' so that the PXE booted OS would be aware of the iSCSI
target configuration).  I mention that in fear that it is suggested to
simply re-use boot-uri, which would preclude the potential of
DHCP-driven SAN configuration at the same time a netboot is desired.


On Sat, Oct 10, 2009 at 1:32 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote:
> Wow, a lot to think about.   I guess we should have had this discussion a
> year ago - I'm sorry for not doing more to make it happen earlier.
>
> I like the idea of getting rid of the priority entirely, and that makes
> sense if the bootfiles are all the same.   And since there's no way to
> differentiate between them, it makes sense that they are the same.
> However, mentioning PXE and yaboot does point out a problem with this
> approach: it failed last time.   We wound up with yaboot options that were
> allocated without a draft or contact with the IANA, and PXE was a bit of a
> mess too.
>
> So let me ask you this: suppose we took out the priority option, and only
> allowed a single boot parameters option.   Would that draft be something
> that people here would actually use as it was?   Or would they find
> themselves adding extensions?
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>