I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent.
1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
