[radext] [IANA #935820] Protocol Action: 'RADIUS Extensions for IP Port Configuration and Reporting' to Proposed Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)

"Amanda Baber via RT" <drafts-approval@iana.org> Sat, 12 November 2016 14:48 UTC

Return-Path: <iana-shared@icann.org>
X-Original-To: expand-draft-ietf-radext-ip-port-radius-ext.all@virtual.ietf.org
Delivered-To: radext@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 99F9312941E; Sat, 12 Nov 2016 06:48:50 -0800 (PST)
X-Original-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83421129574 for <xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com>; Sat, 12 Nov 2016 06:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.677
X-Spam-Level:
X-Spam-Status: No, score=-4.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, 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 kfin4cE4SgUO for <xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com>; Sat, 12 Nov 2016 06:48:49 -0800 (PST)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1687D12941E for <draft-ietf-radext-ip-port-radius-ext.all@ietf.org>; Sat, 12 Nov 2016 06:48:49 -0800 (PST)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 6124AE0D78 for <draft-ietf-radext-ip-port-radius-ext.all@ietf.org>; Sat, 12 Nov 2016 14:48:48 +0000 (UTC)
Received: by request3.lax.icann.org (Postfix, from userid 48) id 29265C2050C; Sat, 12 Nov 2016 14:48:48 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <drafts-approval@iana.org>
In-Reply-To: <rt-4.2.9-4696-1478876895-1241.935820-7-0@icann.org>
References: <RT-Ticket-935820@icann.org> <147854394645.7294.9903452807987765582.idtracker@ietfa.amsl.com> <rt-4.2.9-11930-1478822686-466.935820-7-0@icann.org> <DC7880973D477648AC15A3BA66253F686F3166CC@dfweml501-mbb> <0087B5CA-328B-4882-AB51-CE5C4355AA8E@deployingradius.com> <rt-4.2.9-4696-1478876895-1241.935820-7-0@icann.org>
Message-ID: <rt-4.2.9-9251-1478962128-159.935820-7-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #935820
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Sat, 12 Nov 2016 14:48:48 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Resent-From: alias-bounces@ietf.org
Resent-To: dean.cheng@huawei.com, jouni.nospam@gmail.com, mohamed.boucadair@orange.com, ssenthil@cisco.com, stefan.winter@restena.lu, lionel.morand@orange.com, bclaise@cisco.com, joelja@bogus.com, Kathleen.Moriarty.ietf@gmail.com, radext@ietf.org
Resent-Message-Id: <20161112144850.99F9312941E@ietfa.amsl.com>
Resent-Date: Sat, 12 Nov 2016 06:48:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xDp6Q8C5jcunGmovjtbDA0kAVas>
Cc: draft-ietf-radext-ip-port-radius-ext.all@ietf.org
Subject: [radext] [IANA #935820] Protocol Action: 'RADIUS Extensions for IP Port Configuration and Reporting' to Proposed Standard (draft-ietf-radext-ip-port-radius-ext-16.txt)
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: drafts-approval@iana.org
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: Sat, 12 Nov 2016 14:48:50 -0000

Hi,

On Fri Nov 11 15:08:15 2016, aland@deployingradius.com wrote:
> On Nov 10, 2016, at 10:04 PM, Dean cheng <dean.cheng@huawei.com>
> wrote:
> >
> > The "type" field is 8-bit long so there are possibly 256
> > values. RFC6929 does not say the value "0" is "Unassigned"
> > or "Reserved". In the Radius registry, the value "0" for
> > attribute 241.1 is "Reserved". For consistency, I'd suggest
> >  to follow the same. The maximum value is 256.
> 
> https://tools.ietf.org/html/rfc6929#section-10
> 
> Allocation of an Attribute Type value "TYPE" using the new "Extended
> Type" format results in allocation of 255 new Attribute Type values
> of format "TYPE.1" through "TYPE.255".
> 
> i.e. zero is not for allocation.
> 
> > Note each TLV in Section 7.3 may have more than one parent
> > Radius attributes (e.g., 241.TBD1.1 and 241.TBD2.1). Therefore
> > I'm not sure if these TLVs should go to Radius registry
> > (Section 7.3 only requests for "allocation" for TLV types).
> >
> > If need to define these TLV types in the registry, it must
> > say that these TLVs are independent and may associate with
> > more than one attributes; but I don’t see any example like
> >   this in current registry.
> >
> > Alan - what is your opinion?
> 
> This is a new thing to RADIUS.
> 
> I suggest creating a new RADIUS TLV registry:
> 
> name: RADIUS IP Port Configuration and Reporting TLVs
> 
> contents: all of the TLVs which have more than one parent.
> 
> Then, each parent TLV can be marked as NOT having child attributes.
> Instead, they should be marked as using the new registry for their
> children.

Is this in addition to the action in Section 7.3, or instead of the action in Section 7.3?

If the latter, please send us a new version of the section. It should tell us to create a registry and provide the following: 

- the name of the registry
-  the registration procedure for the registry (see RFC 5226)
- the initial contents of the registry (including a definition for value 0 and the maximum value)

For a recent example of a document that creates a registry, see https://tools.ietf.org/html/rfc7361#section-7.2 or https://tools.ietf.org/html/rfc7688#section-6.2.1. 

thanks,
Amanda