[dhcwg] draft-ietf-dhc-dhcpv4-vendor-message-0

Alfred Hönes <ah@TR-Sys.de> Sun, 15 November 2009 19:24 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
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 41A303A68FF for <dhcwg@core3.amsl.com>; Sun, 15 Nov 2009 11:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.851
X-Spam-Level: ***
X-Spam-Status: No, score=3.851 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
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 40TGS8xQj7x9 for <dhcwg@core3.amsl.com>; Sun, 15 Nov 2009 11:24:50 -0800 (PST)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 6B5A43A68B4 for <dhcwg@ietf.org>; Sun, 15 Nov 2009 11:24:49 -0800 (PST)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA139773034; Sun, 15 Nov 2009 20:23:54 +0100
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA15587; Sun, 15 Nov 2009 20:23:53 +0100 (MEZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <200911151923.UAA15587@TR-Sys.de>
To: volz@cisco.com, dhcwg@ietf.org
Date: Sun, 15 Nov 2009 20:23:53 +0100
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 8bit
Subject: [dhcwg] draft-ietf-dhc-dhcpv4-vendor-message-0
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: Sun, 15 Nov 2009 19:24:51 -0000

I have reviewd draft-ietf-dhc-dhcpv4-vendor-message-01
and have a few suggestions for editorial improvements.


(1)  Abstract

The draft says:

|  This document requests a vendor-specific DHCPv4 message assignment.
   [...]

This sentence will be OBE by the publication of the memo as an RFC
and hence does not make proper sense for a perpetual Abstract then.
I suggest to simply state:

|  This document introduces a vendor-specific DHCPv4 message type.
                 ^^^^^^^^^^                                 ^^^^^

(You might prefer "specifies" over "introduces", or similar.)


(2)  Section 4

(2.1)
The long paragraph below the first diagram and the related field
description says:

   The option-data field MUST be encoded as a sequence of code/length/
|  value fields of identical format to the DHCP options field and is
   identical to the option-data field of Vendor-Identifying Vendor
   Options [RFC3925].  [...]

The comparative form used seems to be a bit unclear/unpleasant.
I have two alternative proposal for improved wording:

a) swap "identical" and "format" in order to make the former word
adjacent to the comparative "to":

   The option-data field MUST be encoded as a sequence of code/length/
|  value fields of format identical to the DHCP options field and is
                   ^^^^^^^^^^^^^^^^
   identical to the option-data field of Vendor-Identifying Vendor
   Options [RFC3925].  [...]

b) using "same" instead of the first occurrence of "identical":

   The option-data field MUST be encoded as a sequence of code/length/
|  value fields of the same format as the DHCP options field and is
                   ^^^^^^^^        ^^
   identical to the option-data field of Vendor-Identifying Vendor
   Options [RFC3925].  [...]


(2.2)
Below the second diagram, the following field explanation is given:

     subopt-len         An unsigned integer giving the length of the
|                       option-data field in this encapsulated option in
                        !!!!!!!!!!!
                        octets.

This is imprecise and confusing; the draft should use the correct
field name, "sub-option-data", from the diagram to avoid confusion:

     subopt-len         An unsigned integer giving the length of the
|                       sub-option-data field in this encapsulated
                        ^^^^
                        option in octets.


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+