[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT WG Last Call on Status-Server Document
Stig Venaas wrote:
> In most places (but not all) the draft uses the term "Status-Server
> packet" or just "packet". Wouldn't it be better to replace "packet"
> with "message"? Especially since it's not limited to UDP transport.
Maybe. It's still a RADIUS packet, and the term "packet" is
consistent with RFC 2865.
> "it's" should be replaced with "its" throughout (genitive).
> TOC formatting is slightly broken (2.3.1/2.3.2).
I'll fix that in the next rev.
> Section 2.3.2 has no title (missing both in TOC and body).
> In 2.2:
> A similar solution for the problem of querying server status may be
> for a NAS to send specially formed Accounting-Request packets to a
> RADIUS servers authentication port. The NAS can then look for a
> server's accounting
> In 3:
> Note that when a server responds to a Status-Server request, it MUST
> NOTE send more than one response packet.
> In 4.2:
> The server MAY prioritize the handling Status-Server queries over the
> Insert "of" ^^^^^
> The server MAY decide to not respond to a Status-Server, depending on
> Insert "packet" or "message" ^^^^^^^
> In 4.3:
> unresponsive, this change would enable the NAS to start packets to
> start sending packets to that RADIUS server again. The NAS MAY
> Remove " start packets to".
> In 4.6:
> In the worst case, failures in routing for Realm A may affect users
> Realm B. For example, if Proxy Server P can reach Realm B but not
> Insert "of"
> In this situation, if all participants impement Status-Server as
> s/impement/implement/ ^^^^^^^^^^
> In 6:
> The following table provide a guide to which attributes may be found
> s/provide/provides/ ^^^^^^^^^
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.