New Technical Issue (on draft-ietf-geopriv-radius-lo-05.txt)

["Nelson, David" <dnelson@enterasys.com>]

Description of issue
Submitter name: David Nelson
Submitter email address: dnelson@enterasys.com
Date first submitted: February 15, 2006
Reference:
Document: RADIUS-GEOPRIV-05
Comment type: 'T'echnical
Priority: '0' Must fix
Section: 5.2
Rationale/Explanation of issue:

Overly complex attribute format.

Requested change:

   This document describes two formats for conveying location
   information: civic and geospatial location information.
   Section 5.2.1 defines the civic location information format.
   Section 5.2.2 defines the geospatial location information format.

Since there are two distinct attribute flied layouts, it would seem that
this attribute should be represented as two distinct attributes, each
with a fixed format.  Variable format attributes are not encompassed
within the standard RADIUS data model.

Section: 9.2, 9.3
Rationale/Explanation of issue:

The attributes described in these sections are quite complex.  It is
highly likely (based on the current draft work) that the RADIUS D3sign
Guidelines BCP will very strongly discourage attributes of this
complexity to be designed using the traditional RFC 2865 attribute
format, but rather use the proposed Extended RADIUS Attribute format (or
similar name) that will be proposed.  This will mean that the
GEORPIV-RADIUS RFC is out of compliance with the RADIUS Design
Guidelines RFC.

Requested change:

The nature of requested change is somewhat dependent upon the relative
schedules of the GEOPRIV-RADIUS draft and the RADIUS Design Guidelines
draft.  The most technically desirable solution would be to use the
Extended RADIUS Attribute format, assuming that draft is sufficiently
well-baked in a timely fashion to allow these attributes to be
re-formatted, prior to WGLC of the GEOPRIV-RADIUS draft.   I understand
that this is a technical issue of major scope.

Section: 9.6
Rationale/Explanation of issue:

Unusual data type.

Requested change:

          Requested-Info (48 bits):
          This text field contains a numerical value that encodes the
          requested information attributes.
          Each value represents a bit position.

Why 48 bits?  This does not correspond with any existing base RADIUS
data types.  Is this a bit-vector?  Does it need to be a bit vector, or
could it be an enumerated type, with multiple instances of the attribute
allow in the appropriate messages?

Section:  Various.
Rationale/Explanation of issue:

Not all data fields within attribute formats have been designated with
an existing base RADIUS data type.

Requested change:

Verify that all fields have a base data type designation.


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>