RE: DISCUSS: draft-ietf-radext-fixes

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

David B. Nelson <> allegedly scribbled on Monday, July 02, 2007 10:05
AM:

...

> 
>>>   DISCUSS: RFC2865 Section 2.4 does not suggests any timer
>>>   management scheme or timer limits, and I couldn't find this
>>>   anywhere else in RFC2865, either. Consequently, this document
>>>   needs to specify the desired mechanism. See RFC2988 for an
>>> example of such a mechanism. 
>> 
>>   Proposal:  Delete the last two sentences (For example...)  Then,
>> use text similar to that in Section 9 of draft-pana-pana.  It seems
>> to cover the RADIUS requirements pretty well.  Some RADIUS
>> implementations behave this way already.  Also add an informative
>> reference to RFC 3315, and note in the acknowledgements that the
>> following text is adapted from draft-ietf-pana-pana.
> 
> Adding a RECOMMENDED method for achieving the desired
> jitter/randomization of retry times is probably a good thing.  I
> think we need to be careful to avoid adding normative requirements in
> this area, however.  Out charter is to extend RADIUS, and clarify
> some documentation errors.  We don't have leave to introduce
> non-backwards compatible normative requirements.  While new protocols
> would have a higher barrier to publication, we need to recall that
> RADIUS is a widely deployed, legacy protocol.  Some of the behaviors
> are "grandfathered".  

I've never actually understood this contention.  If these are actually
issues with and fixes for the RADIUS protocol, then it would seem to me
that the last thing you would want is to be backwards compatible with
something that's broken.  If the behavior is broken, then change the
behavior.  
      
...

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