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:16 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 A69613A6912 for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 13:16:35 -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 dqfB9Qj7Uen8 for <dhcwg@core3.amsl.com>; Sat, 10 Oct 2009 13:16:34 -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 829753A6819 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 13:16:34 -0700 (PDT)
Received: by ywh27 with SMTP id 27so1148835ywh.31 for <dhcwg@ietf.org>; Sat, 10 Oct 2009 13:18:17 -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=h518HYgIi8nf/K9F4f7IjJ/eCBHV67bzqicfsRlZCnLWDuqSYNPgxgrFVCgTVR1DYI 5m3MhctJCi6WvgbIX4rDbkU+VgTyx7dKR/8lH/0N3fE5pk6N3Ea67KlUDbUi4k+2+JJq nb1ldN19nLoG7EEi64LiD3ZDIr9gr5Z5zZhpQ=
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=mMA9nYFC1fpXog8PV1knyVRL3kSHRxn2QWWr8911iysBYAsah105VN956Q4o6HlyGW D0AYDeab2akPPBWobyGawTxXzL/JfofY8ZgXhTGz1Ok2eBM3EWicVvvGKryfmxd4CAU0 0t4DSEvpYHKkO0rIhfTC7ijRfkv3Uyls8EAbk=
MIME-Version: 1.0
Sender: jarrod.b.johnson@gmail.com
Received: by 10.150.44.27 with SMTP id r27mr7212990ybr.263.1255205897831; Sat, 10 Oct 2009 13:18:17 -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:18:17 -0400
X-Google-Sender-Auth: 97cda113cb57c745
Message-ID: <fab4e42a0910101318s74786f77i69b576c1b9aafe0@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:16:35 -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
>