[dhcwg] AD review of draft-ietf-dhc-pxelinux-02

Jari Arkko <jari.arkko@piuha.net> Mon, 27 August 2007 09:29 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 1IPau7-0001ZN-PE; Mon, 27 Aug 2007 05:29:03 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPau5-0001ZF-MG for dhcwg@ietf.org; Mon, 27 Aug 2007 05:29:01 -0400
Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IPau5-0007Cl-0Z for dhcwg@ietf.org; Mon, 27 Aug 2007 05:29:01 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7573D19865A; Mon, 27 Aug 2007 12:28:59 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2B5AF198659; Mon, 27 Aug 2007 12:28:59 +0300 (EEST)
Message-ID: <46D2995B.2080200@piuha.net>
Date: Mon, 27 Aug 2007 12:28:59 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: Dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-pxelinux@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc:
Subject: [dhcwg] AD review of draft-ietf-dhc-pxelinux-02
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>
Errors-To: dhcwg-bounces@ietf.org

I have made my AD review on this document.
The document is basically in good shape, but
I noticed a few places where clearer text was
needed. First, I believe it would be useful if
the abstract also stated that the code
values will be assigned for this purpose, and
not only describe what the situation is
before the approval of this document.

Second, Section 3.4 text should be improved
to avoid an apparent inconsistency (... recommend
use ... undesirable to suffer collisions ...)

There were a few other small things.

Given that the changes are small, I have simply
inserted RFC Editor notes to the tracker and
intend to take the draft to the IESG review without
asking for a new revision.

Comments on the suggested edits appreciated,
see below.

Jari

>   Please add normative reference to RFC 854 where NVT-ASCII
>   first appears.

>   Change the last sentence of Section 1 from
>
>    Each option as they are defined below carries a response to RFC3942.
>
>   to
>
>    Each option definition below provides a response to RFC3942.

>
>   Change the last paragraph of Section 3.4 from
>
>    It is not only reasonable to utilize this option code for another
>    purpose, it is recommended, except that it is undesirable for any
>    future consumer of this option code to have to suffer potential
>    collisions in legacy userbases.
>
>   to
>
>    It is reasonable to utilize this option code for another
>    purpose, but it is recommended to do this at a later time,
>    given desire to avoid potential collisions in legacy
>    userbases.

>   Change the sentence in the abstract from
>
>    These codes were historically designated 'Site Local', but
>    are presently being made available for allocation as standard
>    DHCP Options.
>
>   to
>
>    These codes were historically designated 'Site Local', but
>    are presently being made available for allocation as standard
>    DHCP Options. This document marks these codes as assigned.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg