RE: Proposed Resolution of Fixes Issue 141: State Attribute

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled:

> The text of Issue 141 is enclosed below.  The proposed resolution is
> as 
> follows:
> 
> Insert the following text at the end of Section  2.8:
> 
> "Since a State attribute is always initially provided by the server
> in an Access-Accept, Access-Challenge, CoA-Request or
> Disconnect-Request, a RADIUS client MUST NOT insert a State attribute
> that it has not previously received from the server." 

OK w/me.
  
> 
> ---------------------------------------------------------------------------------------------------------------
> Issue 141: State Attribute
> Submitter name: David Mitton
> Submitter email address: david@mitton.com Date first submitted:
> November 11, 2005 
> Reference: http://ops.ietf.org/lists/radiusext/2005/msg01024.html
> Document: Fixes-01
> Comment type: T
> Priority: S
> Section: Various
> Rationale/Explanation of issue:
> 
> wrt State attribute; there was a case in the past where a vendor
> decided that their client would sent a State attribute with Null data
> to start a certain proprietary sequence. Non-Vendor's clients would
> fail on this server due to this expectation.   
> 
> You should make it clear that a new Access-Request should not contain
> a State attribute. State should always come from a server, and prior
> context.  
> Not manufactured by the client.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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