Re: Design Guidelines draft

[Alan DeKok <aland@deployingradius.com>]

Hannes Tschofenig wrote:
>>   I agree.  I'll delete the list in A.1.1, and incorporate the text from
>> Section 3.2.1 into Section 2.1.
> 
> OK. 

  After some review, I decided to simplify the text in 3.2.1 rather than
incorporating it into 2.1.  The sections have different purposes.  2.1
describes what the data types are.  3.2.1 describes why the data types
are confusing.

> What I mean is that IPv6 address and IPv6 prefix is considered as a basic data type (even though it was standardized much later with RFC3162) although one can not really speak about widespread deployment given the deployment status of IPv6 in general. 

  I think most widely used RADIUS servers support IPv6 transport, along
with the IPv6 data types.  Many switches and NAS equipment does, too.  I
don't think it's *used* that much, but they are deployed and inter-operable.

> The tagging mechanism, described in Section 3.2.2, falls somewhere between the basic (Section 3.2.1) and complex (Section 3.2.3) data types -- based on the old draft version; version -15. 

  Yes.  It's awkward, but is grandfathered in.

> That's what I meant with "drawing an arbitrary line". 

  It's RADIUS. :(  Nothing is simple.

>>   The existing RFCs are vague on what "services" mean.  This spec isn't
>> the place to define them.
> 
> Hmmm.  

  If you have suggestions...

> But you understand what I mean. For example, with location information I could imagine that one uses a nice map and draw a circle there and then the software would provision that information into the database (in the right format for distribution within RADIUS). Now, assuming that an administrator would enter the data in the cryptic format defined by the RADIUS GEOPRIV RFC wouldn't probably work all that well. 

  Sure.  Many systems support automatic IP address allocation, where the
data sent in a packet is created from an SQL procedure.  But I think the
general text still applies.  At some point, an administrator often has
to enter data.  Leveraging existing data entry methods is preferable to
creating unnecessary new ones.

>>   That investigation is out of scope for this document.
> 
> The problem is that it impacts the content of the document. 
> Out of scope is what the editor and the group consider out of scope. 

  I think a survey of server functionality is an admirable goal.  I
don't think that any survey would make a substantial difference in this
document.

>>   Potentially.  However, most RADIUS implementations should already have
>> the ability to send multiple attributes at once.  That functionality can
>> be leveraged to send "logically" correlated attributes.
> 
> These assumptions are not stated in the document. 

  Stating them is not required, I think.

  Alan DeKok.

--
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/>