Re: [dhcwg] dhc wg last call on draft-ietf-dhc-pxelinux-01

"David W. Hankins" <David_Hankins@isc.org> Fri, 06 July 2007 19:28 UTC

Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tTf-0006uO-7h; Fri, 06 Jul 2007 15:28:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6tTd-0006u4-2l for dhcwg@ietf.org; Fri, 06 Jul 2007 15:28:25 -0400
Received: from goliath.isc.org ([2001:4f8:3:bb::72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6tTc-0003vW-D7 for dhcwg@ietf.org; Fri, 06 Jul 2007 15:28:25 -0400
Received: by goliath.isc.org (Postfix, from userid 10200) id 665675A6EC; Fri, 6 Jul 2007 12:28:23 -0700 (PDT)
Date: Fri, 06 Jul 2007 12:28:23 -0700
From: "David W. Hankins" <David_Hankins@isc.org>
To: DHC WG <dhcwg@ietf.org>
Subject: Re: [dhcwg] dhc wg last call on draft-ietf-dhc-pxelinux-01
Message-ID: <20070706192823.GF8503@isc.org>
References: <46823079.5050405@uninett.no> <8E296595B6471A4689555D5D725EBB2104619BF1@xmb-rtp-20a.amer.cisco.com>
Mime-Version: 1.0
In-Reply-To: <8E296595B6471A4689555D5D725EBB2104619BF1@xmb-rtp-20a.amer.cisco.com>
User-Agent: Mutt/1.5.9i
X-Spam-Score: -2.8 (--)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1226723283=="
Errors-To: dhcwg-bounces@ietf.org

On Fri, Jun 29, 2007 at 05:19:28PM -0400, Bernie Volz (volz) wrote:
> I fully support this document moving forward.

Thank you, Bernie.

> Therefore, I think it makes more sense to just allocate 208 to PXELINUX,
> but call it a deprecated option. Then if 10 years from now we're out of
> option codes, we could reclaim it. But, if we never need it, no harm
> done. I also think this is easier than tagging it as "last resort".

I think you're right, and rather wonder why I didn't think of that
first.

The objective is just to 'mark the landmine'.  I've made the changes
in my sources

> 1. Rename section 6 to "Reboot Time Option".

Fixed in my sources.

> 2. Perhaps the title should just be "PXELINUX Options"? As 'Site Local'
> are now redefined (per RFC 3942) and as this just documents the PXELINUX
> usage.

I sort of agree.  Both the old and new titles aren't very informative
if you don't know what 'option' means contextually.

  <title abbrev="PXELINUX Options">Dynamic Host Configuration Protocol
	Options Used by PXELINUX</title>

?


More nits;

Per Stig (some time ago), I simplified the abstract (so as to remove
references).  This does mean that I had to place references in the
introduction.

Some capitalizations in the introduction's summary list of options
being documented.


> I don't think there would be need to respind this document for any of
> these (if adopted) - they can be handled as notes to the RFC-Editor?

I don't know.  If we get too many more nits, I wouldn't object to
respinning it just to simplify the process for the editor.

-- 
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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg