On 5 Jan 2012, at 17:05 , Alan DeKok wrote: >> * Chunked-Attribute must appear before the attribute it refers to in the >> packet > > RADIUS doesn't impose ordering on attributes of different type. > That's a strong reason to integrate chunking inside of the attribute format.
Ordering constraints here are applied to related attributes. 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. >> * If an attribute occurs multiple times in a request/response (we cannot >> speak here of "a packet") chunks for only one of the occurrences, associated >> to the corresponding Chunked-Attribute, are allowed in a given packet > > Why? RADIUS allows for multiple attributes of the same type, with > different value. > >> * Non-fragmented values for this attribute can appear in any packet, but >> always before the Chunked-Attribute that refers to it > > See comment about attribute ordering. On these issues, I agree with the latest proposal from Alejandro, that rather simplifies ordering constraints. >> * As many Chunked-Attribute (and referred attributes) may appear in a given >> packet as necessary. > > I think this document is intended to solve one *very* limited > use-case. It doesn't address any more general case. The use case is that of an AuthN/AuthZ infrastructure that requires the exchange of data longer that the one that fits in a RADIUS packet, and intended to rely on a single trust infrastructure. I do think it is general enough. > It relies on fixed attribute ordering, which is explicitly not required. 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. > 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. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
