RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr
Bernard Aboba <bernard_aboba@hotmail.com> Mon, 28 April 2008 17:02 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A45D3A6C84; Mon, 28 Apr 2008 10:02:13 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E10E3A67A2 for <ietf@core3.amsl.com>; Mon, 28 Apr 2008 10:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.418
X-Spam-Level:
X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=1.180, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yplThLKQDh-K for <ietf@core3.amsl.com>; Mon, 28 Apr 2008 10:02:06 -0700 (PDT)
Received: from blu139-omc1-s26.blu139.hotmail.com (blu139-omc1-s26.blu139.hotmail.com [65.55.175.166]) by core3.amsl.com (Postfix) with ESMTP id A26BE3A67C1 for <ietf@ietf.org>; Mon, 28 Apr 2008 10:01:46 -0700 (PDT)
Received: from BLU137-W50 ([65.55.162.182]) by blu139-omc1-s26.blu139.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 10:01:50 -0700
Message-ID: <BLU137-W504C7EE5B7CD7AE55E1B1093DE0@phx.gbl>
X-Originating-IP: [65.197.179.22]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Glen Zorn <gzorn@arubanetworks.com>, ietf@ietf.org
Subject: RE: Last Call: draft-ietf-geopriv-radius-lo (Carrying Location Objects in RADIUS and Diameter) to Pr
Date: Mon, 28 Apr 2008 10:01:50 -0700
Importance: Normal
In-Reply-To: <A3DA4C2546E1614D8ACC896746CDCF2901249CAC@aruba-mx1.arubanetworks.com>
References: <A3DA4C2546E1614D8ACC896746CDCF2901249CAC@aruba-mx1.arubanetworks.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 28 Apr 2008 17:01:50.0057 (UTC) FILETIME=[8CD98590:01C8A951]
Cc: radiusext@ops.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0388308470=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
> Last but not least, this draft fairly universally violates several of > the guidelines given in > http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt, in > particular those regarding the use of tags to associate different > attributes (called "Index" in this document) and the creation of > "complex" attributes. The issue of "complex attributes" was extensively discussed on the RADEXT WG mailing list, and the Design Guidelines are based on the WG consensus that was derived from the review of this document. In particular, Section 2.1.3 of the Design Guidelines document specifically calls out the distinction between complex attributes which are interpreted by RADIUS, as opposed to "opaque data" which is treated as a string by RADIUS, and interpreted out of band: The only other exception to the recommendation against complex types is for types that can be treated as opaque data by the RADIUS server. For example, the EAP-Message attribute, defined in [RFC3579] Section 3.1 contains a complex data type that is an EAP packet. Since these complex types do not need to be parsed by the RADIUS server, the issues arising from policy language limitations do not arise. Similarly, since attributes of these complex types can be configured on the server using a data type of String, dictionary limitations are also not encountered. Section A.1 below includes a series of checklists that may be used to analyze a design for RECOMMENDED and NOT RECOMMENDED behavior in relation to complex types. If the RADIUS Server simply passes the contents of an attribute to some non-RADIUS portion of the network, then the data is opaque, and SHOULD be defined to be of type String. A concrete way of judging this requirement is whether or not the attribute definition in the RADIUS document contains delineated fields for sub-parts of the data. If those fields need to be delineated in RADIUS, then the data is not opaque, and it SHOULD be separated into individual RADIUS attributes. > I realize that the RADIUS design guidelines > document is just an Internet-Draft, but it is a radext WG document & has > been under construction for some period of time. The Design Guidelines document text was specifically crafted based on this particular draft, based on extensive discussion within the RADEXT WG. > More important than > the standardization status of the document is the question of whether > the guidelines make sense; The Design Guidelines document has completed RADEXT WG last call with only minor comments outstanding. If you had any concerns about whether the document "makes sense" you should have raised them long ago -- but you did not. > if so, then it may not be such a good idea to so completely ignore them; Far from ignoring the Design Guidelines, this document has actually been one of the primary motivations for creating them -- and the text in Design Guidelines has been specifically crafted to deal with this particular case. >If not, then maybe radext should rethink this > work item (especially since a co-chair of that WG is also a co-author of > the document under review). Given the extensive discussion on the RADEXT WG list relating to this document and Design Guidelines, I have personally spent quite a bit of time with Hannes, Avi and others working on improving the compatibility of this document with the Design Guidelines. I did not ask to be named as an author -- the other authors suggested this to me. Given that, I have no particular interest in this document, other than ensuring that it does as little violence to the RADIUS protocol as possible. So if you have particular concerns relating to the handling of this document, or can provide specific instances in which this document violates "Design Guidelines" (applying the tests in Appendix A, for example), please put them on the table.
_______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-ietf-geopriv-radius-lo (Carr… Glen Zorn
- RE: Last Call: draft-ietf-geopriv-radius-lo (Carr… Bernard Aboba
- RE: Last Call: draft-ietf-geopriv-radius-lo (Carr… Glen Zorn
- RE: Last Call: draft-ietf-geopriv-radius-lo (Carr… Bernard Aboba
- RE: Last Call: draft-ietf-geopriv-radius-lo (Carr… David B. Nelson
- RE: [Geopriv] Last Call: draft-ietf-geopriv-radiu… Glen Zorn
- RE: [Geopriv] Last Call: draft-ietf-geopriv-radiu… David B. Nelson