<div>On the server side, that makes sense. Thanks for confirming! :) I will take this back to Brocade to request that they send the attribute they are requiring for successful authorization.</div><div><br></div><div>As for devices that freak out when they receive optional AVP, if anyone can think of any that would be helpful! I have a large environment with many and varied devices that are so ancient there is no hope of getting some kind of firmware bug corrected. :)</div>
<br><div class="gmail_quote">On Tue, Jan 24, 2012 at 8:23 PM, heasley <span dir="ltr"><<a href="mailto:heas@shrubbery.net">heas@shrubbery.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
handling of optional AVs is coded as 'if the nas didnt send it (as<br>
mandatory or optional), then the daemon does not send it'.<br>
<br>
the ancient ietf draft does not make this necessary. its only assertion<br>
is that both sides must ignore optional AVs if they do not support them:<br>
<br>
The arguments in both a REQUEST and a RESPONSE can be specified as<br>
either mandatory or optional. An optional argument is one that may or<br>
may not be used, modified or even understood by the recipient.<br>
<br>
ISTR someone mentioning on this list that some device of theirs threw a<br>
fit if it received an optional AVP that it didnt understand. Perhaps<br>
daniel?<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Jathan.<br>--<br>