[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Capabilities: Moving forward

Sorry for following up to myself, but I made a few typo's that may cause
confusion.

On Wed, Oct 19, 2005 at 10:18:45AM +0200, Emile van Bergen wrote:

>    The rationale for a capabilities advertising capability in this
>    scenario is as follows:
> 
>    - A server needs to know in advance how the NAS will respond to a

insert 'challenge'

>      for the withheld information, because a NAS may not support
>      challenges, causing premature rejection of the user per RFC 2685
>      section 4.4 ([44]), or it may misunderstand the reason for the
>      challenge, causing other unintended behaviour.
> 
>      To expand on this, according to [44], a NAS that supports PAP but
>      that is not willing or able to forward the challenge in the of

replace 'the of' with 'the form of a'

>      Reply-Message to the user, MUST treat the Access-Challenge as an
>      Access-Reject. A NAS that supports classic challenges for PAP
>      requests to implement one time passwords, would effectively forward
>      the challenge to the user, which is not intended here.

[skipping]

> 2. The second problem: some server policies require an Access-Accept

insert 'to be'

>    conditional on the NAS' support for certain session limiting
>    attributes, and on the proxy chain's transparency for them.

Thanks,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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