An editorial comment on Section 2.
Section 2
Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. A Message-Authenticator
attribute MUST be included so as to provide per-packet authentication
and integrity protection. A single Status-Server packet MUST be
included within a UDP datagram. RADIUS proxies MUST NOT forward
Status-Server packets.
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 the IP
address 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.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Message (accounting port). An
Access-Challenge response is NOT RECOMMENDED. An Access-Reject
response MAY be used. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6.
[BA] These three paragraphs are a bit disjoint. Recommend changing it
to the following:
Status-Server packets are sent by a RADIUS client to a RADIUS server
in order to test the status of that server. The destination of
a Status-Server packet is set to the IP address of the server that
is being tested. A single Status-Server packet MUST be included
within a UDP datagram. A Message-Authenticator attribute MUST be
included so as to provide per-packet authentication and integrity
protection.
RADIUS proxies or servers MUST NOT forward Status-Server packets.
A RADIUS server or proxy implementing this specification SHOULD
respond to a Status-Server packet with an Access-Accept
(authentication port) or Accounting-Response (accounting port). An
Access-Challenge response is NOT RECOMMENDED. An Access-Reject
response MAY be used. The list of attributes that are permitted in
Status-Server and Access-Accept packets responding to Status-Server
packets are provided in the Section 6.
Since a Status-Server packet MUST NOT be forwarded
by a RADIUS proxy or server, 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.
> To: ietf-announce@xxxxxxxx
> From: iesg-secretary@xxxxxxxx
> CC: radiusext@xxxxxxxxxxxx
> Subject: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC
> Date: Mon, 15 Mar 2010 12:42:32 -0700
>
> The IESG has received a request from the RADIUS EXTensions WG (radext) to
> consider the following document:
>
> - 'Use of Status-Server Packets in the Remote Authentication Dial In User
> Service (RADIUS) Protocol '
> <draft-ietf-radext-status-server-06.txt> as an Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2010-03-29. Exceptionally,
> comments may be sent to iesg@xxxxxxxx instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-06.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17334&rfc_flag=0
>
>
> --
> to unsubscribe send a message to radiusext-request@xxxxxxxxxxxx with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
|
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf