Subject: RE: [Geopriv] RADIUS-Geopriv: Request for review

From: "Nelson, David" <[email-masked]>
Date: Fri, 17 Feb 2006 10:47:26 -0500

Cross posting RADEXT Issues to the GEOPRIV mailing list.

Description of issue
Submitter name: David Nelson
Submitter email address: [email-masked]
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.

Description of issue
Submitter name: David Nelson
Submitter email address: [email-masked]
Date first submitted: February 15, 2006
Reference:
Document: RADIUS-GEOPRIV-05
Comment type: 'E'ditorial
Priority: '1' Should fix
Section: 3.2
Rationale/Explanation of issue:

   Improper use of terminology.

Requested change:

   Upon receiving the Authorize-Only message from the access network,
   the RADIUS server MUST respond with either an Access-Accept or an
   Access-Reject message.

s/Authorize-Only message from the access network/Access-Request message
containing the Service-Type hint attribute with a value of
Authorize-Only from the NAS/

Section: 5
Rationale/Explanation of issue:

   Improper use of terminology.

Requested change:

   Furthermore, the Basic-Policy-Rules and the Extended-
   Policy-Rules attributes are attached to the Location-Information
   attribute turning location information into a Location Object as
   defined in [12].

The term "attached" apparently has a well understood meaning in terms of
GEOPRIV data objects, but its use in connection with RADIUS attributes
is potentially confusing, and my lead the implementer to believe that
RADIUS application-layer reassembly (i.e. concatenation of two
attributes) is being performed.  If this is the intended outcome
(concatenation within the RADIUS client) then this wording may be OK.
Otherwise, if the RADIUS client is supposed to deliver the individual
attributes to GEOPRIV subsequent processing, rewording to that effect
may be required.

Section:  15.2
Rationale/Explanation of issue:

Cut and paste error.  Redundant words.

Requested change:

   Following the policies outline in [10] new Operator-Namespaces will
   be assigned after Expert Review by the RADEXT working group or its
   designated successor.  Updates can be provided based on expert
   approval only.  A designated expert will be appointed by the O&M Area
   Directors.  No mechanism to mark entries entries as "deprecated is
   envisioned.  Based on expert approval it is possible to delete
   entries from the registry.

s/Operator-Namespace/Requested-Info/

s/entries entries/entries/

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv