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

"Ben Campbell" <ben@nostrum.com> Fri, 28 October 2016 21:28 UTC

Return-Path: <ben@nostrum.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 65E971294FB; Fri, 28 Oct 2016 14:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.33
X-Spam-Level:
X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.431] autolearn=unavailable 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 Rt8BLd7SSs3W; Fri, 28 Oct 2016 14:28:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 11CF412941A; Fri, 28 Oct 2016 14:28:36 -0700 (PDT)
Received: from [10.0.1.21] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u9SLSSZ8059173 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 28 Oct 2016 16:28:29 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.21]
From: "Ben Campbell" <ben@nostrum.com>
To: "Kathleen Moriarty" <kathleen.moriarty.ietf@gmail.com>
Date: Fri, 28 Oct 2016 16:28:28 -0500
Message-ID: <C5355F1B-7D51-4914-9145-DF6AFC661826@nostrum.com>
In-Reply-To: <CAHbuEH6a44Myn1ckSjdnE_8En3ZaphJRXqs-J4fVdgRa8MQe=Q@mail.gmail.com>
References: <147139916045.19867.9306321909504917249.idtracker@ietfa.amsl.com> <CAHbuEH7byupgapgoUC_bk2uySxArm4jfgJm55VCq6H=6aEq=8Q@mail.gmail.com> <C684AC58-076B-4850-A9E9-9086EA2A1EC5@deployingradius.com> <CAHbuEH6a44Myn1ckSjdnE_8En3ZaphJRXqs-J4fVdgRa8MQe=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_690F5F00-519E-4C31-8761-83D099A5A64C_="
Embedded-HTML: [{"HTML":[616, 4748], "plain":[110, 3492], "uuid":"670AA438-6E6F-47E3-8761-6BCF8AC0F03B"}]
X-Mailer: MailMate (1.9.5r5263)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/TiRB3YD2x2sE-ALwF-KV7lVtp8A>
Cc: "radext@ietf.org" <radext@ietf.org>, draft-ietf-radext-datatypes@ietf.org, Stefan Winter <stefan.winter@restena.lu>, Alan DeKok <aland@deployingradius.com>, "iesg@ietf.org" <iesg@ietf.org>, radext-chairs@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:28:37 -0000

Yes, it all looks perfectly reasonable.

Thanks!

Ben.

On 28 Oct 2016, at 16:18, Kathleen Moriarty wrote:

> 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