DIEGO LOPEZ GARCIA wrote: > Ordering constraints here are applied to related attributes.
RADIUS doesn't work that way. There are hundreds of thousands of deployments which assume that ordering constraints do NOT apply to related attributes. Changing such a fundamental part of the protocol is impossible. > I don't see why this would go beyond the requirements imposed by the current > document on extended attributes, as the recent discussion on it shows. I pointed you to RFC 2865, and explained why that restriction is impossible. Please go read those messages again. > It relies in the usage of an specific attribute that defines the > interpretation of the values of another attribute. Ordering rules probably > could be relaxed, but at the price of more complicated processing rules. It relies on behavior which is mandated as NOT being part of RADIUS. >> I gave comments on your approach. Do you have any comments on my >> proposed alternative? It would seem to (a) solve the same problem, and >> (b) have none of the limitations. > > One of the main goals of the proposal was to be compatible with current > mechanisms for attribute encoding inside the packet (EAP-style, extended > attributes…) and deal only with values spanning more than one packet. Using > your alternative would break this compatibility. Nonsense. It is incompatible with existing methods like EAP-Message. Those *already* have semantics defined. Changing them by adding a "Chunked Attribute" is impossible. The extended format hasn't been deployed, so compatibility with it is impossible. My proposal was to allow *new* attributes to span multiple packets. Changing the rules on attribute ordering is impossible. Don't even try. Changing the meaning of existing attributes to allow more than 253 octets of data is impossible. Don't even try. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
