[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft-chiba-11 comments.



> I have some concern.  There are some attributes in the attribute table that
> are not listed, eg. Framed-IP-route, Class etc are they allowed in CoA?

RADIUS attributes included in CoA or Disconnect messages do not have the
same semantic meaning as they do in RFC 2865-2869, and RFC 3162. For
example, in RFC 2865, Framed-IP-Address means "assign this IP address".
However, in draft-chiba it means "apply the command to the session
matching this IP address". This semantic confusion means that unless the
meaning of an attribute is explicitly defined in the draft, then it
SHOULD NOT be used, because it isn't clear what should be done with it.

> We think that all attributes (in 2865, 2866, 2869 etc.) that are allowed in
> an Access Accept message must be listed in the table with explicit role in
> the CoA.

Since these aren't accounting messages, I'm not clear why accounting
attributes are relevant, with the exception of the ones listed in the
draft.

For the other attributes, we'd need an explanation of what they do to
consider including them. Merely citing RFC 2865 isn't enough because in
this protocol attributes could be used for identification instead of their
normal meaning.

> Further, we think that unless there is a good reason to disallow certain
> attributes that they will be allowed for CoA.  If they are not allowed, a
> reason must be given as to why in a Note.  We can then argue as to whether
> the reason to exclude makes sense -- and document the reason to avoid
> further discussion.

Given the semantic confusion, I'd probably lean the other way. Unless we
know what an attribute will do, there's no point in saying that it's ok to
include it. Something as simple as Tunnel Group ID could be confusing --
is this used for identification or is the Tunnel ID supposed to be changed
to the new value?