Overall, I believe that this document is very close to being ready for submission to the IESG as an Informational RFC.
Section 1.1
This specification is also limited to being a "hop by hop" query.
When RADIUS packets transition one or more RADIUS Proxies, any
information about the status of downstreamservers is unavailable to
the client. In addition, it queries only the status of a RADIUS
server, cannot carry information about specific realms.
These limitations are discussed in more detail below.
[BA] My suggestion is that this material be moved to Section 2, since it doesn't relate to the
reasons why publication is recommended as an Informational RFC.
Section 2
This section includes a statement of the problem and justification for why the Status-Server solution was
chosen. My suggestion is to begin this section with an explanation of what Status-Server does, then move
on from there.
Suggested rewrite:
Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that
server. Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the destination
of a Status-Server packet is set to that of the server which is being tested. As a result, the
client is provided with an indication of the status of that server only, since no RADIUS proxies
are on the path between the RADIUS client and server. Since servers respond to a Status-Server packet
without examining the User-Name attribute, the response to a Status-Server packet cannot be used to
infer any information about the reachability of specific realms.
The "hop by hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine
the status of elements on the path between the client and a server. Since the Status-Server packet
is non-forwardable, lack of a response may only be due to packet loss or the failure of the server in the
destination IP address, not due to faults in downstream links, proxies or servers. It therefore provides an unambiguous indication
of the status of a server.
This information may be useful in situations where the RADIUS client does not receive a response to
an Access-Request. A client may have multiple proxies configured, with one proxy marked
as primary and another marked as secondary. If the client does not
receive a response to a request sent to the primary proxy, it can
"fail over" to the secondary, and send requests to the secondary
instead of to the primary proxy.
However, it is possible that the lack of a response to requests sent
to the primary proxy was due not to a failure within the the
primary, but to alternative causes such as a failed link along the
path to the destination server, or the failure of the destination server.
In such a situation, it may be useful for the client to be able to
distinguish between failure causes so that it does not trigger failover
inappropriately. For example, if the primary proxy is down, then quick
failover to the secondary proxy would be prudent, whereas if a downstream
failure is the cause, then the value of failover to a secondary proxy will
depend on whether packets forwarded by the secondary will utilize independent
links, intermediaries or destination servers.
The Status-Server packet is not a "Keep-Alive" as discussed in
[RFC2865] Section 2.6. "Keep-Alives" are Access-Request packets sent to
determine whether a downstream server is responsive. These packets
are typically sent only when a server is suspected to be down, and are
no longer sent as soon as the server is available again.
|