Re: [dhcwg] extending the DHCPv4 option space, VSO usage -- was: Re: issues with draft-grochla-80211-dhcp-option-00

Thomas Narten <narten@us.ibm.com> Mon, 04 October 2010 13:41 UTC

Return-Path: <narten@us.ibm.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 4ECDD3A6C91 for <dhcwg@core3.amsl.com>; Mon, 4 Oct 2010 06:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.224
X-Spam-Level:
X-Spam-Status: No, score=-104.224 tagged_above=-999 required=5 tests=[AWL=-1.625, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Yfhriv38+JMq for <dhcwg@core3.amsl.com>; Mon, 4 Oct 2010 06:41:58 -0700 (PDT)
Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 6F6D93A6FAF for <dhcwg@ietf.org>; Mon, 4 Oct 2010 06:41:58 -0700 (PDT)
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o94DeZKk019230 for <dhcwg@ietf.org>; Mon, 4 Oct 2010 07:40:35 -0600
Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o94DgfcL211682 for <dhcwg@ietf.org>; Mon, 4 Oct 2010 07:42:41 -0600
Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o94DkTOg030831 for <dhcwg@ietf.org>; Mon, 4 Oct 2010 07:46:29 -0600
Received: from cichlid.raleigh.ibm.com (sig-9-65-192-108.mts.ibm.com [9.65.192.108]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o94DkSmx030770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Oct 2010 07:46:29 -0600
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id o94DgdxQ022109; Mon, 4 Oct 2010 09:42:39 -0400
Message-Id: <201010041342.o94DgdxQ022109@cichlid.raleigh.ibm.com>
To: Glen Zorn <gwz@net-zen.net>
In-reply-to: <000c01cb5b85$73e3ad70$5bab0850$@net>
References: <201009230757.JAA27187@TR-Sys.de> <954E9F8A-B4F6-4A90-A091-33C4E7545DC5@nominum.com> <000c01cb5b85$73e3ad70$5bab0850$@net>
Comments: In-reply-to "Glen Zorn" <gwz@net-zen.net> message dated "Fri, 24 Sep 2010 08:11:39 +0700."
Date: Mon, 04 Oct 2010 09:42:39 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: dhcwg@ietf.org, 'Alfred HÎnes' <ah@TR-Sys.de>, 'Ted Lemon' <Ted.Lemon@nominum.com>
Subject: Re: [dhcwg] extending the DHCPv4 option space, VSO usage -- was: Re: issues with draft-grochla-80211-dhcp-option-00
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: Mon, 04 Oct 2010 13:41:59 -0000

"Glen Zorn" <gwz@net-zen.net> writes:

> Ted Lemon [mailto://Ted.Lemon@nominum.com] writes:

> ...
> > ...I still think that this sort of option isn't what vendor options are
> for--
> > my understanding of vendor options is that they're for vendors--e.g.,
> > Cisco, not IEEE.

> Maybe.  However, that makes the DHCP usage of the vendor-specific construct
> considerably more limited than other IETF protocols (e.g. RADIUS & Diameter
> (in which even the IETF is considered a "vendor", assigned the vendor-id of
> 0)).

FWIW, I've never been a fan of other SDOs using vendor ids. Yes, its
been done, but that doesn't make it right.  If an SDO needs something
standardized, by definition multiple vendors will implement it, you
need interoperability, etc. That by definition is what a standard is,
and argues for getting the work done properly and reviewed by the
IETF.

Vendor IDs are really intended for a single vendor, where you don't
have multiple vendors needing to interoperate.

Thomas