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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 28 October 2016 21:18 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 0CC0E129616; Fri, 28 Oct 2016 14:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ADG__1OG9QZe; Fri, 28 Oct 2016 14:18:43 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E557E12952E; Fri, 28 Oct 2016 14:18:42 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id y123so65043693vka.3; Fri, 28 Oct 2016 14:18:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=saX3NpoR1oD2rCYme9cBN+LldcTzD/zBZ8ergoHx3Pw=; b=pLPmRypb20hkwlIR0zd1giE5w5IuetF6TKNpWl8e7bTwNab/kmKxkLLGI/eVfpZyd/ yBPGjatzA+vwYh62TYGsO3Gm34KXuNKUZsRVizTv8fz1eiFRL0oHjFObepGueW41p8sn vVHmMgpGJqHiZkIQtIeymiaRcQdYx3WU4g5M/j4tsUE5lRnmna+Loz9jQUfxWrRr3HrN vTbReaJbHubeKILAyHnr0lKXmsxPEnF0Lo1ZcsZTVobad9ogNEIADisJl693T2Jgxesk Xmw3aGxRuIcXUU0Mf1Px0nNNDL9i0LFcdsUQ7aFOQ+mFVaih6jUNamQwH6G5pqamTh1m VLhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=saX3NpoR1oD2rCYme9cBN+LldcTzD/zBZ8ergoHx3Pw=; b=gsLtQcVMdChQ84tuRa6VLiSnJgg5Vq9a8M7oYzuUzttFxK0CyUPrh1SH5SL3/N6tjZ ZGl77+wJS2ZOb+AVmIscUztYVQALPbKLeLRGgvyZH2sNNeuWVzfALGyYEL863Rhh7WhS acWXwCFWctx74A+LzGxm+gqTl3LNkd3/P2DcV5T9d7CGXxPHO70oJmH/4LlUsG6QY40G 8nEeEQlnExACb4yDHi6Ig7X9LO7IhbZxGURrovAXQSuGchwx7PuPvBImUdd4nhsWpZKh /VgkHcdSI+qCAZx3hscEnvKpoHH4PY2a29pPLkImU5+8BNgJF1Mv69RgUIsgw05Zf2cA jOTw==
X-Gm-Message-State: ABUngvcymsW6yrdxujw538qfuWF6pCIrxxxC+aCHCFVI1DokbpoAc6VQS9EUnW3IADIMnxVse3ayAAddbzZYsA==
X-Received: by 10.31.151.78 with SMTP id z75mr14713965vkd.41.1477689521976; Fri, 28 Oct 2016 14:18:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.82.143 with HTTP; Fri, 28 Oct 2016 14:18:41 -0700 (PDT)
In-Reply-To: <C684AC58-076B-4850-A9E9-9086EA2A1EC5@deployingradius.com>
References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> <CAHbuEH7byupgapgoUC_bk2uySxArm4jfgJm55VCq6H=6aEq=8Q@mail.gmail.com> <C684AC58-076B-4850-A9E9-9086EA2A1EC5@deployingradius.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 28 Oct 2016 17:18:41 -0400
Message-ID: <CAHbuEH6a44Myn1ckSjdnE_8En3ZaphJRXqs-J4fVdgRa8MQe=Q@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140e6620bbbe4053ff36708"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/dr6dC9z85JRhqyNEBXOqaJhNroE>
Cc: Stefan Winter <stefan.winter@restena.lu>, draft-ietf-radext-datatypes@ietf.org, radext-chairs@ietf.org, "radext@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: Fri, 28 Oct 2016 21:18:45 -0000

Hello Ben,

Are you okay with Alan's response?

Thank you,
Kathleen

On Tue, Oct 11, 2016 at 4:16 PM, Alan DeKok <aland@deployingradius.com>
wrote:

>
> > 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.
>
>


-- 

Best regards,
Kathleen