Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT)

Alan DeKok <aland@deployingradius.com> Tue, 11 October 2016 20:17 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D870129471; Tue, 11 Oct 2016 13:17:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 10Q86Gxxw8vF; Tue, 11 Oct 2016 13:17:00 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDD9129451; Tue, 11 Oct 2016 13:17:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id CE4A21751; Tue, 11 Oct 2016 20:16:59 +0000 (UTC)
Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7P_84MVXDZB; Tue, 11 Oct 2016 20:16:59 +0000 (UTC)
Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 23D5F3A2; Tue, 11 Oct 2016 20:16:59 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAHbuEH7byupgapgoUC_bk2uySxArm4jfgJm55VCq6H=6aEq=8Q@mail.gmail.com>
Date: Tue, 11 Oct 2016 16:16:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <C684AC58-076B-4850-A9E9-9086EA2A1EC5@deployingradius.com>
References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> <CAHbuEH7byupgapgoUC_bk2uySxArm4jfgJm55VCq6H=6aEq=8Q@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/w22iuXXVRQT8WnrVCTGHlaNsbVk>
Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org
Subject: Re: [radext] Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2016 20:17:02 -0000

> On Oct 11, 2016, at 3:59 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> Hi Alan,
> 
> I don't see responses to the No Objection messages on your draft.  Can you take care of that so I can progress the document?

  I didn't get the original message. <mumble smtp issues>

> ---------- Forwarded message ----------
> From: Ben Campbell <ben@nostrum.com>
> Date: Tue, Aug 16, 2016 at 9:59 PM
> Subject: Ben Campbell's No Objection on draft-ietf-radext-datatypes-06: (with COMMENT)
> To: The IESG <iesg@ietf.org>
> Cc: stefan.winter@restena.lu, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, radext@ietf.org
...
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -2.1.2, first paragraph: "The specification may, of course, define a new
> data type and use it in the same document."
> Am I correct to assume that any such definition must (or maybe MUST) be
> registered? (Maybe that's already covered in 6929?)

  Any such new definition MUST be registered.  RFC 6929 just forbids new data types.

  I think I can update the doc in the next rev, as soon as that's required.

> -4.1: I'm curious why new data types need a policy as strong as
> "standards action". Is there a concern that people will get this wrong
> without the full weight of the IETF consensus process? Is there a concern
> that the numbering space will run out? Would it be reasonable to have a
> "specification-required" policy, with some guidance to the designated
> expert(s)? (Or is it because such data types need to be referenceable
> from standards track documents, perhaps related to the guidance against
> vendor-specific types?)

  See RFC 6929 covers this in detail.  There are few good reasons to create new data types.  There is a huge cost to creating new data types, and very little benefit.

  Section 6 has guidelines for creating attributes.  RFC 6158 also contains long guidelines in Appendix A.  Both sections have text explaining why these guidelines are in place.

  In addition, as the draft notes, RADIUS implementations are typically driven by a dictionary containing attribute names, assigned numbers, and data types.  This means that adding new attributes with known data types is trivial: edit the dictionary.  Adding new data types is complex, and requires much code to be written.

  Another reason is practice.  I'm aware of only a few data types which have been vendor-defined in the last twenty years.  One is an "ad hoc" structure to describe firewall rules.  Another is a signed integer (the above RFCs explain why this is wrong).  A few vendors defined a 64-bit integer before the IETF did.  That's really about it.

  So new data types are not needed, and without IETF consensus, are generally wrong.

  FWIW, IPFix has a fixed set of data types, an IANA registry, and requires standards action for update.  There is a strong overlap between the data IPFix tracks, and RADIUS accounting.  So a fixed set of data types works well in both places.

  Alan DeKok.