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

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

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