Re: : Change to "Reply-Message AVP" usage in Diameter EAP

On Sat, Aug 13, 2005 at 10:44:44PM -0700, Bernard Aboba wrote:
> > Back when RFC 3579 was written, sending Reply-Message was a bad idea
> > because the only things the NAS could do with it was discard it (so
> > sending it wasn't necessary) or convert it to an EAP Notification
> > packet (a really bad idea for several reasons).
> >
> > Since then, things have changed.
> 
> The problem described above still exists for EAP over link layers such as
> PPP, IEEE 802.11, IEEE 802.16e, and IKEv2, right?
> 
> > For instance, PANA has the ability
> > to send a displayable message to the client, and Reply-Message would
> > be the most logical attribute for this (and is used for this purpose
> > in draft-ieft-pana-aaa-interworking-00).
> 
> EAP methods are link independent, which means they don't behave
> differently when running over PANA, 802.11, PPP, etc.  As a result, if the
> method needs to send an error message it will do so either using a
> method-specific notification, or using EAP Notification.  Given this, how
> can a Reply-Message attribute end up in a AAA message carrying an EAP
> packet?

The notification mechanism of PANA (using Notification AVP) is
orthogonal to the EAP-based notification mechanisms.  So I'd like to
see Reply-Message AVP(s) carried in a DEA regardless of existence of
EAP-Payload AVP in the same message.

Yoshihiro Ohba


> 
> > So if we prohibit using
> > Reply-Message, we may at some point need to define an identical
> > attribute with a different name/number to get around this "MUST NOT".
> 
> The document as it stands does not mention PANA; there is no
> NAS-Port-Type defined for PANA, or in general any way for the AAA server
> to tell whether PANA is being used.  Therefore I don't see how special
> behavior can be assumed for PANA.
> 
> > My impression from other AAA WG documents suggests that arguing
> > about this issue will have no other effect than stretching the
> > Author's 48 Weeks period even longer.
> 
> Bert has requested that we resolve this issue ASAP.  Based on the
> discussion so far, the WG seems to have rough consensus to go ahead with
> Tom and Glen's proposed changes.
> 
> 
>