IETF Logo Mail Archive

Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

Ted Lemon <ted.lemon@nominum.com> Wed, 19 March 2014 18:07 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732721A0410 for <dhcwg@ietfa.amsl.com>; Wed, 19 Mar 2014 11:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJBDghF2fTYZ for <dhcwg@ietfa.amsl.com>; Wed, 19 Mar 2014 11:07:00 -0700 (PDT)
Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 83D781A0780 for <dhcwg@ietf.org>; Wed, 19 Mar 2014 11:07:00 -0700 (PDT)
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2A66DF8044 for <dhcwg@ietf.org>; Wed, 19 Mar 2014 11:06:52 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 0C4AA190043; Wed, 19 Mar 2014 11:06:52 -0700 (PDT)
Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Mar 2014 11:06:51 -0700
Content-Type: text/plain; charset="windows-1252"
MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <5329DA1D.2010306@viagenie.ca>
Date: Wed, 19 Mar 2014 14:06:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <937B1860-4428-443B-AC12-53B21E2A9746@nominum.com>
References: <94C682931C08B048B7A8645303FDC9F36F51A2DB17@PUEXCB1B.nanterre.francetelecom.fr> <C7964664-C302-4ABE-9CAC-1AD5D9048699@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AF1C1CA@xmb-rcd-x04.cisco.com> <5329B584.1090404@viagenie.ca> <CBE2A263-A6B8-4B46-9454-6F63731DE0DC@nominum.com> <5329D758.6050404@viagenie.ca> <46BCE74E-D2DA-4E8B-8007-D987FFE04874@nominum.com> <5329DA1D.2010306@viagenie.ca>
To: Simon Perreault <simon.perreault@viagenie.ca>
X-Mailer: Apple Mail (2.1874)
X-Originating-IP: [192.168.1.10]
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/znw8D9qQCn91jIjho1NMgXF9qe8
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 19 Mar 2014 18:07:01 -0000

On Mar 19, 2014, at 1:55 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
> It was just a data point... *sigh*

Of course, sorry if the response seemed harsh.   That wasn't my intention.   I am curious whether the code in fact does work as advertised, though—back when I implemented RFC 3396 in the ISC code base, it definitely didn't, but I didn't do the DHCPv6 implementation, so perhaps that does work as you suggest.

It's perhaps important to point out that 3396 didn't change the status quo from one defined state to another; what it did was to change the status quo from an undefined state to a defined state.   Prior to 3396, we simply hadn't specified how multiple options of the same type would be handled, so it was left up to the implementation. 

The ISC implementation never supported sending multiple options of the same type, nor processing them—there was only one place in the data structure for each option type.  (This is based on a ten-year-old recollection, so it's possible I'm mistaken).

v2.23.0 | Report a Bug | By Email