[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RADEXT WG Last Call on Status-Server Document
Submitter name: Stig Venaas
Submitter email address: email@example.com
Date first submitted: November 4, 2008
Document: Status Server
Comment type: E
Rationale/Explanation of issue:
I've read carefully through draft-ietf-radext-status-server-02 and
found several editorial issues.
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.
"it's" should be replaced with "its" throughout (genitive).
TOC formatting is slightly broken (2.3.1/2.3.2).
Section 2.3.2 has no title (missing both in TOC and body).
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
Note that when a server responds to a Status-Server request, it MUST
NOTE send more than one response packet.
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" ^^^^^^^
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 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
In this situation, if all participants impement Status-Server as
The following table provide a guide to which attributes may be found
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.