[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> Tue, 15 November 2016 00:24 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 40187129431; Mon, 14 Nov 2016 16:24:57 -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 190CC129552 for <xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com>; Mon, 14 Nov 2016 16:24:57 -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 ATBDtk7bxmGS for <xfilter-draft-ietf-radext-ip-port-radius-ext.all@ietfa.amsl.com>; Mon, 14 Nov 2016 16:24:55 -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 28817129431 for <draft-ietf-radext-ip-port-radius-ext.all@ietf.org>; Mon, 14 Nov 2016 16:24:55 -0800 (PST)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 57AFEE0E52 for <draft-ietf-radext-ip-port-radius-ext.all@ietf.org>; Tue, 15 Nov 2016 00:24:54 +0000 (UTC)
Received: by request3.lax.icann.org (Postfix, from userid 48) id 1A1B8C2051A; Tue, 15 Nov 2016 00:24:54 +0000 (UTC)
RT-Owner: amanda.baber
From: Amanda Baber via RT <drafts-approval@iana.org>
In-Reply-To: <rt-4.2.9-27489-1479147641-1873.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> <rt-4.2.9-9251-1478962128-159.935820-7-0@icann.org> <DC7880973D477648AC15A3BA66253F686F31EE58@dfweml501-mbb> <rt-4.2.9-27489-1479147641-1873.935820-7-0@icann.org>
Message-ID: <rt-4.2.9-15273-1479169494-1958.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: Tue, 15 Nov 2016 00:24:54 +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: <20161115002457.40187129431@ietfa.amsl.com>
Resent-Date: Mon, 14 Nov 2016 16:24:57 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/_DTIXmWU6t9s9HBNUvJ8aSmMnfo>
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: Tue, 15 Nov 2016 00:24:57 -0000

Hi Dean,

I checked with the RFC Editor, and they said that this is a good time for the authors to upload a new revision. We can complete these actions before this has been uploaded, though. I'll contact you within a few hours to ask you to review the registries and confirm that everything was completed correctly. 

thanks,
Amanda

On Mon Nov 14 18:20:41 2016, dean.cheng@huawei.com wrote:
> Hi Amanda,
> 
> Thanks for the message. We've just made changes in
> Section 7.3 according to the suggestion.
> 
> If the updates OK, should we upload a new revision
> (17.txt) at this time?
> 
> Regards
> Dean
> 
> > -----Original Message-----
> > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Amanda Baber
> > via RT
> > Sent: Saturday, November 12, 2016 6:49 AM
> > 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)
> > 
> > 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
> > 
> > 
> > 
> > _______________________________________________
> > radext mailing list
> > radext@ietf.org
> > https://www.ietf.org/mailman/listinfo/radext