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
- [dhcwg] issues with draft-grochla-80211-dhcp-opti… Alfred Hönes
- Re: [dhcwg] issues with draft-grochla-80211-dhcp-… Ted Lemon
- Re: [dhcwg] issues with draft-grochla-80211-dhcp-… Glen Zorn
- [dhcwg] extending the DHCPv4 option space, VSO us… Alfred Hönes
- Re: [dhcwg] issues with draft-grochla-80211-dhcp-… Ted Lemon
- Re: [dhcwg] extending the DHCPv4 option space, VS… Ted Lemon
- Re: [dhcwg] issues with draft-grochla-80211-dhcp-… Donald Eastlake
- Re: [dhcwg] extending the DHCPv4 option space, VS… Glen Zorn
- Re: [dhcwg] issues with draft-grochla-80211-dhcp-… Ted Lemon
- Re: [dhcwg] extending the DHCPv4 option space, VS… Alfred Hönes
- Re: [dhcwg] extending the DHCPv4 option space, VS… Ted Lemon
- Re: [dhcwg] extending the DHCPv4 option space, VS… Thomas Narten