Jim Schaad wrote: > 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.
Reviews are always welcome. > 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. The simplest way to address that is to artificially lower the RADIUS maximum packet size, as seen by the client. > 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. Yes. > 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. Attribute ordering is explicitly *not* required in RADIUS. > 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. That's an open area for discussion. RADIUS doesn't have capability negotiation, so it's hard to do. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
