Re: REMINDER: RADEXT WG Last Call on Status Server document (part 1)

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Here is my review.
> 
> Abstract
...
> How about something more along the lines of the RFC 5176 abstract?  

  Looks good to me.

> Not sure the history is necessarily correct (e.g. I believe that the RADIUS Working Group was formed earlier).
> In any case, it is probably best to focus on the purpose of this document.  How about this? 

  OK.  I've added it with some minor edits.

> I am not sure that the use of the term "Home Server" here adds clarity.  The definition of proxy from
> RFC 2607 might be more applicable:

  Added.  I've updated the document to use "RADIUS Proxy" and "RADIUS
Server" throughout.

> I think this document needs an applicability section, to explain potential differences between
> this specification and existing implementations, as well as why it is being published as Informational,
> as opposed to Experimental or Standards Track.  Suggest the following:

  I agree.

> RFC 2865 Section 2.6 strongly discourages the use of keep-alives.  
> From reading this section, I am unclear whether the intent is to refute the
> arguments made there, or to articulate how the uses of Status-Server
> defined here go beyond those of the "test RADIUS request" described 
> in RFC 2865. 

  The idea is to state that the Status-Server does not conflict with the
RFC2865 mandate against Keep-Alives.  I'll re-word the text.

> Overall, I wonder whether some of the introductory material in Section 4.3
> might be removed from that section and instead be revised and presented 
> in this section.  For example:

  Very likely, yes.

> Sections 2.1-2.2
> 
> I find these sections puzzling, because they suggest alternatives to the Status-Server packet
> that do not serve the same function.

  They explain why Status-Server was chosen.  I can update the titles &&
re-word the text slightly to make this more clear.

> Section 2.3
...
> While the Status-Server packet format was not defined in RFC 2865, it was implemented by Ascend and
> other vendors.  As far as I know, a number of deployments did use NAS and RADIUS servers from different
> vendors so that "implementation-specific definitions" would indeed have resulted in interoperability 
> problems.  
> 
> In any case, as I understand it, the goal of this work item is to document existing implementations of 
> the Status-Server extension, correct?  

  Yes.

> Section 2.3.1
...
> Given that the Status-Server packet is not forwardable, this section is a bit
> confusing.  Also, I'm not clear how useful the diagram is. 
> I'd suggest focusing on the basics of the exchange:

  Ok.  Looks good to me.  I've added text on Accounting-Message, and
re-worded things a bit.

> BTW, I'm curious as to whether a Status-Server packet can be sent to the address
> and port (3799) of a DAS, and if so, what the appropriate response is.  

  That was discussed and rejected earlier.  This document talks about
currently implemented uses of Status-Server.

> Section 2.3.2
> 
>    The Status-Server packet MUST contain a Message-Authenticator
>    attribute for security.  
> 
> Given that implementations exist that did not support Message-Authenticator, my suggestion is that this
> become a SHOULD. 

  I'm wary of this one.   I would say that new implementations MUST use
Message-Authenticator.  Making it a "SHOULD" means that a lot of people
will ignore it.

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