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

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
..
> [BA] Can you provide a section reference for the Tw timer?

  Done.

...
> [BA] I think a bit more explanation would be helpful here.  Traditional "failover" algorithms have
> depended on use of Access-Request packets.  Unfortunately, these techniques can lead a client to failover
> in circumstances where there is nothing wrong with the primary proxy.  So in reading the first paragraph,
> I'm unclear what is being advocated, precisely.  For example, is it being advocated that a Status-Server 
> packet be sent to the primary proxy after a number of Access-Requests do not receive a response?  That
> would help determine whether the primary proxy was the issue in the first place.  If it is not the issue
> (e.g. primary proxy responds), then sending Status-Server packets to the primary proxy would seem
> pointless.  

  OK.  I've added some text to the document that will hopefully clarify
this.

> Section 4.4
> 
> The point that Status-Server packets are non-forwardable is quite central to the document, so it would
> be a good idea to make the point earlier. 

  That is addressed in the updates from the previous message.

> Section 4.5
> 
> 4.5.  Realm Routing
...
> 
> [BA] What mechanism?  Since Status-Server packets are non-forwardable, there no concept of a destination
> realm,  right? 

  Yes.  I've clarified the wording in the first paragraph.

> Overall, I think this section might be retitled "Limitations of Status-Server" because that is really the
> main focus. 

  OK.

> On reading this section, the thought did occur to me that in the cause where Status-Server indicated
> a downstream failure that "per-realm" failover might make sense.  For example, if the primary could
> reach realm A but not B, there is no point in failing over all Requests to the secondary, just those
> for realm B.  Of course, it is also possible that a fault in a downstream node that prevented 
> reaching realm A (e.g. a failure in a server for realm A) might subsequently be corrected, so that
> realm A might become reachable again. 

  It's a good idea.  I'm not sure if any client or server supports that
behavior, however.

> Section 5
> 
> Recommend including a row for User-Name, which presumably would have all 0s in it (e.g. User-Name is not used
> in Status-Server packets, right?). 

  The first paragraph says:

   Attributes other than
   the ones listed below SHOULD NOT be found in a Status-Server packet.

  I think that covers it.

> What is the purpose of VSAs in Status-Server packets or Access-Responses? 

  To permit future vendor extensions, as with normal RADIUS.

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