[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
- [dhcwg] draft-despres-intarea-4rd comments Tomasz Mrugalski
- Re: [dhcwg] draft-despres-intarea-4rd comments Rémi Després
- Re: [dhcwg] draft-despres-intarea-4rd comments Tomasz Mrugalski