Subject: Re: (radius) Tagged attribute question

From: Barney Wolff <[email-masked]>
Date: Fri, 9 Apr 1999 15:51 EDT

The special case I was objecting to is specifically the single endpoint
case, with the following language in the draft:

  5.  Attributes

  Multiple instances of each of the attributes defined below may be
  included in a single RADIUS packet.  In this case, the attributes to be
  applied to any given tunnel SHOULD all contain the same value in their
  respective Tag fields;  otherwise, the Tag field SHOULD NOT be used.

The server is of course *allowed* not to use a tag, when there is only
a single tunnel to be specified.  But by saying SHOULD NOT, a server
that always uses 1 for the first tunnel is being admonished, and I
claim that there is no reason it should be.  The notion that a server
that uses tags can interoperate with a NAS that does not understand
tags, in the degenerate case of a single tunnel, is not interesting
to me.  Oh well, it's a minor point, I suppose.

Barney Wolff

> Date: Fri, 09 Apr 1999 19:21:56 +0200
> Reply-To: Marc De Vries <[email-masked]>
> 
> The special case is not just for user profiles that contain only one
> tunnel attribute set. It also accomodates servers that are not tag-aware
> and send plain integers and strings (and that ommit the
> Tunnel-Password).
> 
> This special case may complicate the code for new implementations (IMO
> not really that big a deal), but at least it does not require everybody
> to upgrade their radius servers, only the dictionaries.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 13 Apr 1999 18:27:37 -0700

Barney Wolff <[email-masked]> writes:

> claim that there is no reason it should be.

Actually, I tend to agree with you.  lacking any storm of protest, I'll
change the next (hopefully final) rev to say:
   5.  Attributes

   respective Tag fields.

> The notion that a server
> to me.

Hmm.  Actually, that was one of the reasons why the tag field has

> Oh well, it's a minor point, I suppose.

True

-