Subject: RADEXT WG Last Call on Status-Server Document

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Nov 2008 16:10:56 -0800

This is an announcement of RADEXT WG last call on the document"Use of Status-Server Packets in the RADIUS Protocol", prior to sendingthis document on to the IESG for publication as an Informational 
RFC.   The document is available for inspection here:http://tools.ietf.org/html/draft-ietf-radext-status-server-02RADEXT WG last call will complete on November 25, 2008.   Pleasesend review comments to the RADEXT WG mailing list([email-masked]) in the format described on the RADEXTIssues List (http://www.drizzle.com/~aboba/RADEXT ).   If youhave no comments, but believe the document should be progressed,please also send a note to the list to this effect. 

 EMAILING FOR THE GREATER GOODJoin me

---

From: Stig Venaas <[email-masked]>
Date: Tue, 04 Nov 2008 11:49:08 +0100

Submitter name: Stig Venaas
Submitter email address: [email-masked]
Date first submitted: November 4, 2008
Document: Status Server
Comment type: T
Priority: 1
Section: 2.3.2
Rationale/Explanation of issue:

I think clients should allow Access-Accept responses to status-server
messages sent to the accounting port. Even if it's not the expected
message, it shows that the server is alive.

Also, towards the end of section 4.2 the draft says:

   Some server implementations accept both Access-Request and
   Accounting-Request packets on the same port, and do not distinguish
   between "authentication only" ports, and "accounting only" ports.
   Those implementations SHOULD reply to Status-Server packets with an
   Access-Accept packet.

Due to this, I think the text in 2.3.2 is too strict:

   The Status-Server packet MUST contain a Message-Authenticator
   attribute for security.  The response (if any) to a Status-Server
   packet sent to an accounting port MUST be an Accounting-Response
   packet.  The list of attributes that are permitted in the Accounting-
   Response packet is given in the Table of Attributes in Section 6,
   below.

I think the second MUST should be a SHOULD. Or at the very least, in
section 4.1 where it talks about clients being liberal at what they
accept. Add a note that they SHOULD accept this.

Stig

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Stig Venaas <[email-masked]>
Date: Tue, 04 Nov 2008 13:05:07 +0100

Comment type: E
Priority: S
Section: Various

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 04 Nov 2008 13:08:18 +0100

Bernard Aboba wrote:
> This is an announcement of RADEXT WG last call on the document
> "Use of Status-Server Packets in the RADIUS Protocol", prior to sending
> this document on to the IESG for publication as an Informational
> RFC.   The document is available for inspection here:
> http://tools.ietf.org/html/draft-ietf-radext-status-server-02__
> <http://tools.ietf.org/html/draft-ietf-radext-status-server-02>
> 
> RADEXT WG last call will complete on November 25, 2008.   Please
> send review comments to the RADEXT WG mailing list
> ([email-masked]) in the format described on the RADEXT
> Issues List (http://www.drizzle.com/~aboba/RADEXT ).   If you
> have no comments, but believe the document should be progressed,
> please also send a note to the list to this effect.

I've found some issues that I just reported in two separate mails.
Once those are addressed I support progressing the document. FWIW
I've also implemented it based on this draft, and successfully
tested with other implementations.

Stig

---

From: Alan DeKok <[email-masked]>
Date: Tue, 04 Nov 2008 12:00:49 -0500

> tested with other implementations.

  Those issues are minor, and will be addressed in the next revision.
Thanks for your review.

  Alan DeKok.