Hi Alan,
thanks for the clarifications and hints. We will think about them and
their implications, and try to modify the proposal to make it address
all the requirements.
Regards,
Alejandro
El 09/01/12 10:58, Alan DeKok escribió:
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
