Re: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap

["Alan DeKok" <aland@ox.org>]

"Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez@hp.com> wrote:
> The reason that section 2.2 exists at all is because we have a strong
> desire for the capability to have an acknowledgement from the NAS, in
> particular when it was incapable or unable to apply and attribute (from
> this document).

  I will be releasing a capability problem statement draft soon.  The
draft will address this, and other issues.

  Until then, RADIUS does not have capabilities, and no amount of
tweaks to the protocol will add that functionality.

> While I do agree that we are setting a precedent that moves away from
> the legacy RADIUS behavior, this new behavior would be just applicable
> to the attributes described in this document. Perhaps a discussion item
> for the RADIUS issues and fixes document is to look at the role explicit
> acknowledgement could play for all attributes.

  Please read the capability problem statement presentation from IETF,
and the list archives discussing capabilities.  This is a known issue
which is being addresses.

> "Unless otherwise noted in the individual description of an attribute
> contained herein, a NAS that conforms to this specification and receives
> an Access-Accept message that contains an attribute from this document
> that it does not recognize or cannot apply MUST interpret this though an
> Access-Reject had been sent and MUST terminate the session.

  I believe this covered in Section 1.1 of RFC 2865, page 5:

...
   A NAS that does not implement a given service MUST NOT implement the
   RADIUS attributes for that service.  For example, a NAS that is
   unable to offer ARAP service MUST NOT implement the RADIUS attributes
   for ARAP.  A NAS MUST treat a RADIUS access-accept authorizing an
   unavailable service as an access-reject instead.
...

>  If accounting is enabled on the NAS, it MUST generate an accounting
> event upon session termination."

  This is covered in the first paragraph of Section 2 of RFC 2866.

  I think what you're implying here is that an accounting stop should
be sent when an Access-Reject is received.  Please acknowledge if that
is your intent or not, as that will help clarify the discussion.

  But if so, I do not believe that sending accounting stop in response
to an access-Reject is necessary or useful.  There was NO session to
terminate, so sending a stop is improper.

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