[radext] #10: Editorial Issues

["radext issue tracker" <trac@tools.ietf.org>]

#10: Editorial Issues
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:  aland@â                  
     Type:  defect                     |      Status:  new                      
 Priority:  minor                      |   Milestone:  milestone1               
Component:  status-server              |     Version:  1.0                      
 Severity:  Submitted WG Document      |    Keywords:                           
---------------------------------------+------------------------------------
 Date first submitted: March 15, 2010
 Reference: http://ops.ietf.org/lists/radiusext/2010/msg00254.html

 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/10>
radext <http://tools.ietf.org/radext/>


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