[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).

  Fixed, thanks.

> 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

  Fixed, thanks.

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

  Fixed, thanks.

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

  Fixed, thanks.

> 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".

  Fixed, thanks.

> 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"

  Fixed, thanks.

>    In this situation, if all participants impement Status-Server as
> s/impement/implement/                    ^^^^^^^^^^

  Fixed, thanks.

> In 6:
>    The following table provide a guide to which attributes may be found
> s/provide/provides/   ^^^^^^^^^

  Fixed, thanks.

  Alan DeKok.

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