IETF Logo Mail Archive

Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Ted Lemon <Ted.Lemon@nominum.com> Fri, 05 April 2013 16:18 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7EA21F9838; Fri, 5 Apr 2013 09:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H3ieUuu4kCm; Fri, 5 Apr 2013 09:18:04 -0700 (PDT)
Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4621F9835; Fri, 5 Apr 2013 09:18:04 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUV75PIz5P8RUE7qATDSMUtovzRsvzAei@postini.com; Fri, 05 Apr 2013 09:18:04 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 463F81081C0; Fri, 5 Apr 2013 09:18:04 -0700 (PDT)
Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3A9C319005D; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 09:18:04 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Peter Deacon <peterd@iea-software.com>
Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
Thread-Index: Ac4xZGO6VSG79PrhReiNj3Ln9NlMtAAApjaQADr6/IAAADrcAA==
Date: Fri, 05 Apr 2013 16:18:03 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com>
References: <B51C71CC-654D-43F3-A50A-321C171CD562@gmail.com> <alpine.WNT.2.00.1304041005110.3988@SMURF> <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> <alpine.WNT.2.00.1304050824570.3988@SMURF>
In-Reply-To: <alpine.WNT.2.00.1304050824570.3988@SMURF>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <05F797F04784824AB252DF5AB6BD323A@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<radext@ietf.org>" <radext@ietf.org>, dhcwg <dhcwg@ietf.org>
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 05 Apr 2013 16:18:06 -0000

On Apr 5, 2013, at 12:11 PM, Peter Deacon <peterd@iea-software.com> wrote:
> Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 servers in number and vendors involved.  It might be difficult to ever add new attributes in production as you would have to touch all relays to allow a new attribute to pass.  My guess VSAs would likely end up filling any gaps anyway.

What's a VSA?   Should the document specify that the list of attributes to forward be customizable by the administrator?

I think the main purpose that the list of options not to forward serves is to have a default setting, and to exclude on a protocol specification level the use of options that we don't specifically intend be used; if an administrator configures some option that's not on the list, I think that's harmless.

v2.23.0 | Report a Bug | By Email