[dhcwg] draft-despres-intarea-4rd comments

Tomasz Mrugalski <tomasz.mrugalski@gmail.com> Thu, 31 March 2011 14:53 UTC

Return-Path: <tomasz.mrugalski@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 E822E28C126 for <dhcwg@core3.amsl.com>; Thu, 31 Mar 2011 07:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 7qZz40O7PRbE for <dhcwg@core3.amsl.com>; Thu, 31 Mar 2011 07:53:55 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C953A28C102 for <dhcwg@ietf.org>; Thu, 31 Mar 2011 07:53:54 -0700 (PDT)
Received: by wwa36 with SMTP id 36so2045440wwa.13 for <dhcwg@ietf.org>; Thu, 31 Mar 2011 07:55:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=S8geteUhH2p8JfU3kHLoLtguAfTd9sP8n63JJzMSKHw=; b=yBRC8Zjok1A0R577xGwtcfcMi4pSZb7lgxV1JGnLf/SudBHGVWcbIvMDAUzxm44MOT ZcrCJ0dMFtbixUmkOXMjDrVFgxcFS3ooyLlZoWRdiWPBIw+pS8zFlbZS3fgqwq+4ibsU +a0YbaVORYRq5dWp6qz+RTzpzfb45G8Hzs/TE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=B/EKwT0CEx+T91CIfLh0+2HBygeHk1xMH2kx1K7rnpOvgbN7zU7lj7UKEC+pdMDE3N f4+4mtL/wQa2iVTDqa8dD/8Zvh05E3TJ5lToMhPhWJsRE75V6BySoH/eUiXL9LGQyPnb Bo4x/C2ukAf9H6iwiJ6rbeegqrezWILlMhbF4=
Received: by 10.227.181.133 with SMTP id by5mr2987223wbb.9.1301583333944; Thu, 31 Mar 2011 07:55:33 -0700 (PDT)
Received: from dhcp-11aa.meeting.ietf.org (dhcp-11aa.meeting.ietf.org [130.129.17.170]) by mx.google.com with ESMTPS id o23sm701507wbc.10.2011.03.31.07.55.29 (version=SSLv3 cipher=OTHER); Thu, 31 Mar 2011 07:55:30 -0700 (PDT)
Message-ID: <4D9495E0.5030404@gmail.com>
Date: Thu, 31 Mar 2011 16:55:28 +0200
From: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9
MIME-Version: 1.0
To: draft-despres-intarea-4rd@tools.ietf.org, dhcwg@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] draft-despres-intarea-4rd comments
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: Thu, 31 Mar 2011 14:53:56 -0000

I have partially read the draft (mostly the parts related to DHCPv6) and
would like to provide my comments. I may have additional comments as I
finish proper reading throughout the draft.

First, I'm sorry if my comments may seem a bit harsh, but the currently
proposed option format is catastrophic. It is basically several
suboptions stuffed together with suboption-like type and length coded on
nibbles, rather than usual 2 byte fields, with some suboptions being
optional. These parameters should clearly be defined as separate options
(possibly grouped together as suboptions within an option for clarity).
Defined that way, it would be much easier to parse/build such options by
involved entities. I will also be less problematic to support by
implementations that also definition of custom options. Luckily, that
can be fixed quite easily. Hopefully, there are no (or very limited)
implementations, so redoing the option layout should be no problem.

There are no usual DHCPv6 Server or Client Behavior sections. Although
not strictly required, they are very convienient for vendors that are
looking for clean list of requirements that they must meet to claim spec
conformance.

There is no mention of DHCPv6 related problems in Security
Considerations section whatsoever. This should be analysed a bit and
commented in the text (possibly briefly if there are no new issues here,
with just pointers to existing RFCs).

Also, I have a procedural recommendation. I happen to have worked on
DHCPv6 option for another IPv4-IPv6 coexistence architecture. The actual
architecture and the DHCPv6 operation were specified in separate, but
closely related documents. It worked really well, because discussed
problems and review groups are mostly orthogonal. They could also
possibly follow separate adoption paths (or perhaps not, but that is
something that should be possibly considered).

Remi asked for DHC experts to provide help with this. I'm not sure if I
qualify to that distinction, but I'm happily volunteering for work on
this. I will coordinate with Remi and other authors how they would like
to organize the work.

Hope that helps,
Tomek Mrugalski
ISC