Re: RADEXT WG Last Call on Status-Server Document

[Stig Venaas <stig.venaas@uninett.no>]

Submitter name: Stig Venaas
Submitter email address: stig.venaas@uninett.no
Date first submitted: November 4, 2008
Document: Status Server
Comment type: E
Priority: S
Section: Various
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).

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.
s/NOTE/NOT/

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/   ^^^^^^^^^

Stig

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>