Subject: [eap] rfc2284bis-08: turn-around description

From: [email-masked] (James Carlson)
Date: Thu, 2 Jan 2003 07:27:56 -0500

The turn-around description is not correct given current PPP practice,
nor does it seem practical.  (If you're to turn the link around, then
one of the two equal peers must go first.  Which one?)

Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue: 

This problem seems to have been introduced with the resolution to
issue #48.  The description, though, is at odds with the original EAP
design and usage in PPP.  Despite the text, there is no requirement of
synchronization between the independent authentication sessions in
each direction.  The words "after" and "complete" are misleading.

Requested change: 

from:

[7]  Since EAP is a Peer-to-Peer protocol, after authentication in one
     direction is complete, the direction of authentication MAY reverse,
     with the endpoint previously serving as the Authenticator assuming
     the Peer role, and the former Peer now taking on the Authenticator
     role. As with the original conversation, the reversal is signalled
     by the (new) Authenticator sending a Request. Support for bi-
     directional authentication requires that each endpoint implement
     both the Peer and Authenticator roles.

to:

[7]  Since EAP is a Peer-to-Peer protocol, an independent and
     simultaneous authentication may take place in the reverse
     direction.  Both peers may act as authenticators and
     authenticatees at the same time.

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677